From 68a934313f8d04f6dabb8475f71b3a0773ea433f Mon Sep 17 00:00:00 2001 From: Tunzeki Date: Sat, 29 Apr 2023 21:03:25 +0100 Subject: [PATCH 01/83] Fix typo: change 'then' to 'the' (#5978) The sentence reads: In this solution, two separate conditions are used to insert a space between then name and the importance label. It should read: In this solution, two separate conditions are used to insert a space between the name and the importance label. --- src/content/learn/conditional-rendering.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/learn/conditional-rendering.md b/src/content/learn/conditional-rendering.md index cbae68cec..cfd52320a 100644 --- a/src/content/learn/conditional-rendering.md +++ b/src/content/learn/conditional-rendering.md @@ -626,7 +626,7 @@ export default function PackingList() { Note that you must write `importance > 0 && ...` rather than `importance && ...` so that if the `importance` is `0`, `0` isn't rendered as the result! -In this solution, two separate conditions are used to insert a space between then name and the importance label. Alternatively, you could use a fragment with a leading space: `importance > 0 && <> ...` or add a space immediately inside the ``: `importance > 0 && ...`. +In this solution, two separate conditions are used to insert a space between the name and the importance label. Alternatively, you could use a fragment with a leading space: `importance > 0 && <> ...` or add a space immediately inside the ``: `importance > 0 && ...`. From 37a12a658b87a4ed4e2299c8675fcc05c06557fe Mon Sep 17 00:00:00 2001 From: Andrew Clark Date: Wed, 3 May 2023 15:40:44 -0400 Subject: [PATCH 02/83] Next Channel -> Canary Channel (#5992) See https://github.com/facebook/react/pull/26761 for more context. --- src/content/community/versioning-policy.md | 36 +++++++++++----------- 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/src/content/community/versioning-policy.md b/src/content/community/versioning-policy.md index b6ffc96de..df3a730c7 100644 --- a/src/content/community/versioning-policy.md +++ b/src/content/community/versioning-policy.md @@ -80,12 +80,12 @@ This section will be most relevant to developers who work on frameworks, librari Each of React's release channels is designed for a distinct use case: - [**Latest**](#latest-channel) is for stable, semver React releases. It's what you get when you install React from npm. This is the channel you're already using today. **Use this for all user-facing React applications.** -- [**Next**](#next-channel) tracks the main branch of the React source code repository. Think of these as release candidates for the next minor semver release. Use this for integration testing between React and third party projects. +- [**Canary**](#canary-channel) tracks the main branch of the React source code repository. Think of these as release candidates for the next minor semver release. Use this for integration testing between React and third party projects. - [**Experimental**](#experimental-channel) includes experimental APIs and features that aren't available in the stable releases. These also track the main branch, but with additional feature flags turned on. Use this to try out upcoming features before they are released. -All releases are published to npm, but only Latest uses semantic versioning. Prereleases (those in the Next and Experimental channels) have versions generated from a hash of their contents and the commit date, e.g. `0.0.0-68053d940-20210623` for Next and `0.0.0-experimental-68053d940-20210623` for Experimental. +All releases are published to npm, but only Latest uses semantic versioning. Prereleases (those in the Canary and Experimental channels) have versions generated from a hash of their contents and the commit date, e.g. `18.3.0-canary-388686f29-20230503` for Canary and `0.0.0-experimental-388686f29-20230503` for Experimental. -**The only officially supported release channel for user-facing applications is Latest**. Next and Experimental releases are provided for testing purposes only, and we provide no guarantees that behavior won't change between releases. They do not follow the semver protocol that we use for releases from Latest. +**The only officially supported release channel for user-facing applications is Latest**. Canary and Experimental releases are provided for testing purposes only, and we provide no guarantees that behavior won't change between releases. They do not follow the semver protocol that we use for releases from Latest. By publishing prereleases to the same registry that we use for stable releases, we are able to take advantage of the many tools that support the npm workflow, like [unpkg](https://unpkg.com) and [CodeSandbox](https://codesandbox.io). @@ -95,49 +95,49 @@ Latest is the channel used for stable React releases. It corresponds to the `lat **If you're not sure which channel you should use, it's Latest.** If you're a React developer, this is what you're already using. You can expect updates to Latest to be extremely stable. Versions follow the semantic versioning scheme, as [described earlier.](#stable-releases) -### Next channel {/*next-channel*/} +### Canary channel {/*canary-channel*/} -The Next channel is a prerelease channel that tracks the main branch of the React repository. We use prereleases in the Next channel as release candidates for the Latest channel. You can think of Next as a superset of Latest that is updated more frequently. +The Canary channel is a prerelease channel that tracks the main branch of the React repository. We use prereleases in the Canary channel as release candidates for the Latest channel. You can think of Canary as a superset of Latest that is updated more frequently. -The degree of change between the most recent Next release and the most recent Latest release is approximately the same as you would find between two minor semver releases. However, **the Next channel does not conform to semantic versioning.** You should expect occasional breaking changes between successive releases in the Next channel. +The degree of change between the most recent Canary release and the most recent Latest release is approximately the same as you would find between two minor semver releases. However, **the Canary channel does not conform to semantic versioning.** You should expect occasional breaking changes between successive releases in the Canary channel. **Do not use prereleases in user-facing applications.** -Releases in Next are published with the `next` tag on npm. Versions are generated from a hash of the build's contents and the commit date, e.g. `0.0.0-68053d940-20210623`. +Releases in Canary are published with the `canary` tag on npm. Versions are generated from a hash of the build's contents and the commit date, e.g. `18.3.0-canary-388686f29-20230503`. -#### Using the next channel for integration testing {/*using-the-next-channel-for-integration-testing*/} +#### Using the canary channel for integration testing {/*using-the-canary-channel-for-integration-testing*/} -The Next channel is designed to support integration testing between React and other projects. +The Canary channel is designed to support integration testing between React and other projects. All changes to React go through extensive internal testing before they are released to the public. However, there are a myriad of environments and configurations used throughout the React ecosystem, and it's not possible for us to test against every single one. If you're the author of a third party React framework, library, developer tool, or similar infrastructure-type project, you can help us keep React stable for your users and the entire React community by periodically running your test suite against the most recent changes. If you're interested, follow these steps: - Set up a cron job using your preferred continuous integration platform. Cron jobs are supported by both [CircleCI](https://circleci.com/docs/2.0/triggers/#scheduled-builds) and [Travis CI](https://docs.travis-ci.com/user/cron-jobs/). -- In the cron job, update your React packages to the most recent React release in the Next channel, using `next` tag on npm. Using the npm cli: +- In the cron job, update your React packages to the most recent React release in the Canary channel, using `canary` tag on npm. Using the npm cli: ```console - npm update react@next react-dom@next + npm update react@canary react-dom@canary ``` Or yarn: ```console - yarn upgrade react@next react-dom@next + yarn upgrade react@canary react-dom@canary ``` - Run your test suite against the updated packages. - If everything passes, great! You can expect that your project will work with the next minor React release. - If something breaks unexpectedly, please let us know by [filing an issue](https://github.com/facebook/react/issues). -A project that uses this workflow is Next.js. (No pun intended! Seriously!) You can refer to their [CircleCI configuration](https://github.com/zeit/next.js/blob/c0a1c0f93966fe33edd93fb53e5fafb0dcd80a9e/.circleci/config.yml) as an example. +A project that uses this workflow is Next.js. You can refer to their [CircleCI configuration](https://github.com/zeit/next.js/blob/c0a1c0f93966fe33edd93fb53e5fafb0dcd80a9e/.circleci/config.yml) as an example. ### Experimental channel {/*experimental-channel*/} -Like Next, the Experimental channel is a prerelease channel that tracks the main branch of the React repository. Unlike Next, Experimental releases include additional features and APIs that are not ready for wider release. +Like Canary, the Experimental channel is a prerelease channel that tracks the main branch of the React repository. Unlike Canary, Experimental releases include additional features and APIs that are not ready for wider release. -Usually, an update to Next is accompanied by a corresponding update to Experimental. They are based on the same source revision, but are built using a different set of feature flags. +Usually, an update to Canary is accompanied by a corresponding update to Experimental. They are based on the same source revision, but are built using a different set of feature flags. -Experimental releases may be significantly different than releases to Next and Latest. **Do not use Experimental releases in user-facing applications.** You should expect frequent breaking changes between releases in the Experimental channel. +Experimental releases may be significantly different than releases to Canary and Latest. **Do not use Experimental releases in user-facing applications.** You should expect frequent breaking changes between releases in the Experimental channel. Releases in Experimental are published with the `experimental` tag on npm. Versions are generated from a hash of the build's contents and the commit date, e.g. `0.0.0-experimental-68053d940-20210623`. @@ -147,11 +147,11 @@ Experimental features are ones that are not ready to be released to the wider pu For example, if the Experimental channel had existed when we announced Hooks, we would have released Hooks to the Experimental channel weeks before they were available in Latest. -You may find it valuable to run integration tests against Experimental. This is up to you. However, be advised that Experimental is even less stable than Next. **We do not guarantee any stability between Experimental releases.** +You may find it valuable to run integration tests against Experimental. This is up to you. However, be advised that Experimental is even less stable than Canary. **We do not guarantee any stability between Experimental releases.** #### How can I learn more about experimental features? {/*how-can-i-learn-more-about-experimental-features*/} -Experimental features may or may not be documented. Usually, experiments aren't documented until they are close to shipping in Next or Latest. +Experimental features may or may not be documented. Usually, experiments aren't documented until they are close to shipping in Canary or Latest. If a feature is not documented, they may be accompanied by an [RFC](https://github.com/reactjs/rfcs). From aa88d8a7766dcceb17cfe7abb53bad7687afede3 Mon Sep 17 00:00:00 2001 From: Dan Abramov Date: Wed, 3 May 2023 22:16:52 +0100 Subject: [PATCH 03/83] Canaries blog post --- src/content/blog/2023/05/03/react-canaries.md | 92 +++++++++++++++++++ src/content/blog/index.md | 5 + src/content/community/versioning-policy.md | 17 ++-- src/sidebarBlog.json | 7 ++ 4 files changed, 115 insertions(+), 6 deletions(-) create mode 100644 src/content/blog/2023/05/03/react-canaries.md diff --git a/src/content/blog/2023/05/03/react-canaries.md b/src/content/blog/2023/05/03/react-canaries.md new file mode 100644 index 000000000..2553255d5 --- /dev/null +++ b/src/content/blog/2023/05/03/react-canaries.md @@ -0,0 +1,92 @@ +--- +title: "React Canaries: Enabling Incremental Feature Rollout Outside Meta" +--- + +May 3, 2023 by [Dan Abramov](https://twitter.com/dan_abramov), [Sophie Alpert](https://twitter.com/sophiebits), [Rick Hanlon](https://twitter.com/rickhanlonii), [Sebastian Markbåge](https://twitter.com/sebmarkbage), and [Andrew Clark](https://twitter.com/acdlite) + +--- + + + +Traditionally, new React features used to only be available at Meta first, and land in the open source releases later. We'd like to offer the React community an option to adopt individual new features as soon as their design is close to final--similar to how Meta uses React internally. We are introducing a new officially supported [Canary release channel](/community/versioning-policy#canary-channel). It lets curated setups like frameworks decouple adoption of individual React features from the React release schedule. + + + +--- + +## tl;dr {/*tldr*/} + +* We're introducing an officially supported [Canary release channel](/community/versioning-policy#canary-channel) for React. +* Canaries let you start using individual new React features before they land in the semver-stable releases. +* Unlike the [Experimental](/community/versioning-policy#experimental-channel) channel, React Canaries only include features that we reasonably believe to be ready for adoption. We encourage frameworks to consider bundling pinned Canary React releases. +* We will announce breaking changes and new features on our blog as they land in Canary releases. +* **As always, React continues to follow semver for every Stable release.** + +## How React features are usually developed {/*how-react-features-are-usually-developed*/} + +Typically, every React feature goes through the same stages: + +1. We develop an initial version and prefix it with `experimental_` or `unstable_`. The feature is only available in the `experimental` release channel and at Meta. At this point, the feature is expected to change significantly. +2. We find a team at Meta willing to help us test this feature and provide feedback on it. This leads to a round of changes. As the feature becomes more stable, we work with more teams at Meta to try it out. +3. Eventually, we feel confident in the design. We remove the prefix from the API name, and make the feature available on the `main` branch by default. At this point, any team at Meta can use this feature. +4. When we are close to cutting an open source release, we post an RFC for the new feature. At this point we are confident the design works for a broad set of cases, but we might make some last minute adjustments. +5. Finally, we release the feature together with its documentation in a stable React release. + +This playbook works well for most features we've released so far. However, there can be a significant gap between when the feature is generally ready to use (step 3) and when it is released in open source (step 5). + +**We'd like to offer the React community an option to follow the same approach as Meta, and adopt individual new features earlier (as they become available) without having to wait for the next release cycle of React.** + +As always, all React features will eventually make it into a Stable release. + +## Can we just do more minor releases? {/*can-we-just-do-more-minor-releases*/} + +Generally, we *do* use minor releases for introducing new features. + +However, this isn't always possible. Sometimes, new features are interconnected with *other* new features which have not yet been fully completed and that we're still actively iterating on. We can't release them separately because their implementations are related. We can't version them separately because they affect the same packages (for example, `react` and `react-dom`). And we need to keep the ability to iterate on the pieces that aren't ready without a flurry of major version releases, which semver would require us to do. + +At Meta, we've solved this problem by building React from the `main` branch, and manually updating it to a specific pinned commit every week. This is also the approach that React Native releases have been following for the last several years. Every *stable* release of React Native is pinned to a specific commit from the `main` branch of the React repository. This lets React Native include important bugfixes and incrementally adopt new React features at the framework level without getting coupled to the global React release schedule. + +We would like to make this workflow available to other frameworks and curated setups. For example, it lets a framework *on top of* React include a React-related breaking change *before* this breaking change gets included into a stable React release. This is particularly useful because some breaking changes only affect framework integrations. This lets a framework release such a change in its own minor version without breaking semver. + +## Why not use experimental releases instead? {/*why-not-use-experimental-releases-instead*/} + +Although you *can* technically use [Experimental releases](/community/versioning-policy#canary-channel), we recommend against using them in production because they can contain significant unannounced breaking changes, or be completely broken. While Canaries can also contain mistakes (as with any release), going forward we plan to announce any significant breaking changes in Canaries on our blog. Canaries are the closest to the code we run internally, so you can generally expect them to be relatively stable. However, you *do* need to keep the version pinned and manually scan the GitHub commit log when updating between the pinned commits. + +**We expect that most people using React outside a curated setup (like a framework) will want to continue using the Stable releases.** However, if you're building a framework, you might want to consider bundling a Canary version of React pinned to a particular commit, and update it at your own pace. The benefit of that is that it lets you ship individual completed React features and bugfixes earlier for your users and at your own release schedule, similar to how React Native has been doing it for the last few years. The downside is that you would take on additional responsibility to communicate which React changes are included with your releases. + +If you're a framework author and want to try this approach, please get in touch with us. + +## Announcing breaking changes and new features early {/*announcing-breaking-changes-and-new-features-early*/} + +Canary releases represent our best guess of what will go into the next stable React release at any given time. + +Traditionally, we've only announced breaking changes at the *end* of the release cycle (when doing a major release). Now that Canary releases are an officially supported way to consume React, we plan to shift towards announcing breaking changes and significant new features *as they land* in Canaries. For example, if we merge a breaking change that will go out in a Canary, we will write a post about it on the React blog, including codemods and migration instructions if necessary. Then, if you're a framework author cutting a major release that updates the pinned React canary to include that change, you can link to our blog post from your release notes. Finally, when a stable major version of React is ready, we will link to those already published blog posts. + +We plan to document APIs as they land in Canaries--even if these APIs are not yet available outside of them. APIs that are only available in Canaries will be marked with a special note on the corresponding pages. This will include APIs like [`use`](https://github.com/reactjs/rfcs/pull/229), and some others (like `cache` and `createServerContext`) which we'll send RFCs for. + +## Canaries must be pinned {/*canaries-must-be-pinned*/} + +If you decide to adopt the Canary workflow for your app or framework, make sure you always pin the *exact* version of the Canary you're using. Since Canaries are pre-releases, they may still include breaking changes. + +## Example: React Server Components {/*example-react-server-components*/} + +As we [announced in March](/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023#react-server-components), the React Server Components conventions have been finalized, and we do not expect significant breaking changes related to their user-facing API contract. However, we can't release support for React Server Components in a stable version of React yet because we are still working on several intertwined framework-only features (such as [asset loading](/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023#asset-loading)) and expect more breaking changes there. + +This means that React Server Components are ready to be adopted by frameworks. However, until the next major React release, the only way for a framework to adopt them is to ship a pinned Canary version of React. (To avoid bundling two copies of React, frameworks that wish to do this would need to enforce resolution of `react` and `react-dom` to the pinned Canary they ship with their framework, and explain that to their users.) + +## Testing libraries against both Stable and Canary versions {/*testing-libraries-against-both-stable-and-canary-versions*/} + +We do not expect library authors to test every single Canary release since it would be prohibitively difficult. However, just as when we [originally introduced the different React pre-release channels three years ago](https://legacy.reactjs.org/blog/2019/10/22/react-release-channels.html), we encourage libraries to run tests against *both* the latest Stable and latest Canary versions. If you see a change in behavior that wasn't announced, please file a bug in the React repository so that we can help diagnose it. We expect that as this practice becomes widely adopted, it will reduce the amount of effort necessary to upgrade libraries to new major versions of React, since accidental regressions would be found as they land. + + + +Strictly speaking, Canary is not a *new* release channel--it used to be called Next. However, we've decided to rename it to avoid confusion with Next.js. We're announcing it as a *new* release channel to communicate the new expectations, such as Canaries being an officially supported way to use React. + + + +## Stable releases work like before {/*stable-releases-work-like-before*/} + +We are not introducing any changes to stable React releases. + + + diff --git a/src/content/blog/index.md b/src/content/blog/index.md index 3459965f6..fc8a2969b 100644 --- a/src/content/blog/index.md +++ b/src/content/blog/index.md @@ -10,6 +10,11 @@ This blog is the official source for the updates from the React team. Anything i
+ + +Traditionally, new React features used to only be available at Meta first, and land in the open source releases later. We'd like to offer the React community an option to adopt individual new features as soon as their design is close to final--similar to how Meta uses React internally. We are introducing a new officially supported Canary release channel. It lets curated setups like frameworks decouple adoption of individual React features from the React release schedule. + + diff --git a/src/content/community/versioning-policy.md b/src/content/community/versioning-policy.md index df3a730c7..68d5b8eb1 100644 --- a/src/content/community/versioning-policy.md +++ b/src/content/community/versioning-policy.md @@ -79,13 +79,18 @@ This section will be most relevant to developers who work on frameworks, librari Each of React's release channels is designed for a distinct use case: -- [**Latest**](#latest-channel) is for stable, semver React releases. It's what you get when you install React from npm. This is the channel you're already using today. **Use this for all user-facing React applications.** -- [**Canary**](#canary-channel) tracks the main branch of the React source code repository. Think of these as release candidates for the next minor semver release. Use this for integration testing between React and third party projects. +- [**Latest**](#latest-channel) is for stable, semver React releases. It's what you get when you install React from npm. This is the channel you're already using today. **User-facing applications that consume React directly use this channel.** +- [**Canary**](#canary-channel) tracks the main branch of the React source code repository. Think of these as release candidates for the next semver release. **[Frameworks or other curated setups may choose to use this channel with a pinned version of React.](/blog/2023/05/03/react-canaries) You can also Canaries for integration testing between React and third party projects.** - [**Experimental**](#experimental-channel) includes experimental APIs and features that aren't available in the stable releases. These also track the main branch, but with additional feature flags turned on. Use this to try out upcoming features before they are released. All releases are published to npm, but only Latest uses semantic versioning. Prereleases (those in the Canary and Experimental channels) have versions generated from a hash of their contents and the commit date, e.g. `18.3.0-canary-388686f29-20230503` for Canary and `0.0.0-experimental-388686f29-20230503` for Experimental. -**The only officially supported release channel for user-facing applications is Latest**. Canary and Experimental releases are provided for testing purposes only, and we provide no guarantees that behavior won't change between releases. They do not follow the semver protocol that we use for releases from Latest. +**Both Latest and Canary channels are officially supported for user-facing applications, but with different expectations**: + +* Latest releases follow the traditional semver model. +* Canary releases [must be pinned](/blog/2023/05/03/react-canaries) and may include breaking changes. They exist for curated setups (like frameworks) that want to gradually release new React features and bugfixes on their own release schedule. + +The Experimental releases are provided for testing purposes only, and we provide no guarantees that behavior won't change between releases. They do not follow the semver protocol that we use for releases from Latest. By publishing prereleases to the same registry that we use for stable releases, we are able to take advantage of the many tools that support the npm workflow, like [unpkg](https://unpkg.com) and [CodeSandbox](https://codesandbox.io). @@ -93,7 +98,7 @@ By publishing prereleases to the same registry that we use for stable releases, Latest is the channel used for stable React releases. It corresponds to the `latest` tag on npm. It is the recommended channel for all React apps that are shipped to real users. -**If you're not sure which channel you should use, it's Latest.** If you're a React developer, this is what you're already using. You can expect updates to Latest to be extremely stable. Versions follow the semantic versioning scheme, as [described earlier.](#stable-releases) +**If you're not sure which channel you should use, it's Latest.** If you're using React directly, this is what you're already using. You can expect updates to Latest to be extremely stable. Versions follow the semantic versioning scheme, as [described earlier.](#stable-releases) ### Canary channel {/*canary-channel*/} @@ -101,13 +106,13 @@ The Canary channel is a prerelease channel that tracks the main branch of the Re The degree of change between the most recent Canary release and the most recent Latest release is approximately the same as you would find between two minor semver releases. However, **the Canary channel does not conform to semantic versioning.** You should expect occasional breaking changes between successive releases in the Canary channel. -**Do not use prereleases in user-facing applications.** +**Do not use prereleases in user-facing applications directly unless you're following the [Canary workflow](/blog/2023/05/03/react-canaries).** Releases in Canary are published with the `canary` tag on npm. Versions are generated from a hash of the build's contents and the commit date, e.g. `18.3.0-canary-388686f29-20230503`. #### Using the canary channel for integration testing {/*using-the-canary-channel-for-integration-testing*/} -The Canary channel is designed to support integration testing between React and other projects. +The Canary channel also supports integration testing between React and other projects. All changes to React go through extensive internal testing before they are released to the public. However, there are a myriad of environments and configurations used throughout the React ecosystem, and it's not possible for us to test against every single one. diff --git a/src/sidebarBlog.json b/src/sidebarBlog.json index d6258e4a2..2141181b0 100644 --- a/src/sidebarBlog.json +++ b/src/sidebarBlog.json @@ -11,6 +11,13 @@ "path": "/blog", "skipBreadcrumb": true, "routes": [ + { + "title": "React Canaries: Enabling Incremental Feature Rollout Outside Meta", + "titleForHomepage": "React Canaries: Incremental Feature Rollout", + "icon": "blog", + "date": "May 3, 2023", + "path": "/blog/2023/05/03/react-canaries" + }, { "title": "React Labs: What We've Been Working On – March 2023", "titleForHomepage": "React Labs: March 2023", From 9a865fd5159b323c4c3e4c74b52e1bf720b36488 Mon Sep 17 00:00:00 2001 From: Dan Abramov Date: Wed, 3 May 2023 22:18:00 +0100 Subject: [PATCH 04/83] Revert "Canaries blog post" This reverts commit aa88d8a7766dcceb17cfe7abb53bad7687afede3. --- src/content/blog/2023/05/03/react-canaries.md | 92 ------------------- src/content/blog/index.md | 5 - src/content/community/versioning-policy.md | 17 ++-- src/sidebarBlog.json | 7 -- 4 files changed, 6 insertions(+), 115 deletions(-) delete mode 100644 src/content/blog/2023/05/03/react-canaries.md diff --git a/src/content/blog/2023/05/03/react-canaries.md b/src/content/blog/2023/05/03/react-canaries.md deleted file mode 100644 index 2553255d5..000000000 --- a/src/content/blog/2023/05/03/react-canaries.md +++ /dev/null @@ -1,92 +0,0 @@ ---- -title: "React Canaries: Enabling Incremental Feature Rollout Outside Meta" ---- - -May 3, 2023 by [Dan Abramov](https://twitter.com/dan_abramov), [Sophie Alpert](https://twitter.com/sophiebits), [Rick Hanlon](https://twitter.com/rickhanlonii), [Sebastian Markbåge](https://twitter.com/sebmarkbage), and [Andrew Clark](https://twitter.com/acdlite) - ---- - - - -Traditionally, new React features used to only be available at Meta first, and land in the open source releases later. We'd like to offer the React community an option to adopt individual new features as soon as their design is close to final--similar to how Meta uses React internally. We are introducing a new officially supported [Canary release channel](/community/versioning-policy#canary-channel). It lets curated setups like frameworks decouple adoption of individual React features from the React release schedule. - - - ---- - -## tl;dr {/*tldr*/} - -* We're introducing an officially supported [Canary release channel](/community/versioning-policy#canary-channel) for React. -* Canaries let you start using individual new React features before they land in the semver-stable releases. -* Unlike the [Experimental](/community/versioning-policy#experimental-channel) channel, React Canaries only include features that we reasonably believe to be ready for adoption. We encourage frameworks to consider bundling pinned Canary React releases. -* We will announce breaking changes and new features on our blog as they land in Canary releases. -* **As always, React continues to follow semver for every Stable release.** - -## How React features are usually developed {/*how-react-features-are-usually-developed*/} - -Typically, every React feature goes through the same stages: - -1. We develop an initial version and prefix it with `experimental_` or `unstable_`. The feature is only available in the `experimental` release channel and at Meta. At this point, the feature is expected to change significantly. -2. We find a team at Meta willing to help us test this feature and provide feedback on it. This leads to a round of changes. As the feature becomes more stable, we work with more teams at Meta to try it out. -3. Eventually, we feel confident in the design. We remove the prefix from the API name, and make the feature available on the `main` branch by default. At this point, any team at Meta can use this feature. -4. When we are close to cutting an open source release, we post an RFC for the new feature. At this point we are confident the design works for a broad set of cases, but we might make some last minute adjustments. -5. Finally, we release the feature together with its documentation in a stable React release. - -This playbook works well for most features we've released so far. However, there can be a significant gap between when the feature is generally ready to use (step 3) and when it is released in open source (step 5). - -**We'd like to offer the React community an option to follow the same approach as Meta, and adopt individual new features earlier (as they become available) without having to wait for the next release cycle of React.** - -As always, all React features will eventually make it into a Stable release. - -## Can we just do more minor releases? {/*can-we-just-do-more-minor-releases*/} - -Generally, we *do* use minor releases for introducing new features. - -However, this isn't always possible. Sometimes, new features are interconnected with *other* new features which have not yet been fully completed and that we're still actively iterating on. We can't release them separately because their implementations are related. We can't version them separately because they affect the same packages (for example, `react` and `react-dom`). And we need to keep the ability to iterate on the pieces that aren't ready without a flurry of major version releases, which semver would require us to do. - -At Meta, we've solved this problem by building React from the `main` branch, and manually updating it to a specific pinned commit every week. This is also the approach that React Native releases have been following for the last several years. Every *stable* release of React Native is pinned to a specific commit from the `main` branch of the React repository. This lets React Native include important bugfixes and incrementally adopt new React features at the framework level without getting coupled to the global React release schedule. - -We would like to make this workflow available to other frameworks and curated setups. For example, it lets a framework *on top of* React include a React-related breaking change *before* this breaking change gets included into a stable React release. This is particularly useful because some breaking changes only affect framework integrations. This lets a framework release such a change in its own minor version without breaking semver. - -## Why not use experimental releases instead? {/*why-not-use-experimental-releases-instead*/} - -Although you *can* technically use [Experimental releases](/community/versioning-policy#canary-channel), we recommend against using them in production because they can contain significant unannounced breaking changes, or be completely broken. While Canaries can also contain mistakes (as with any release), going forward we plan to announce any significant breaking changes in Canaries on our blog. Canaries are the closest to the code we run internally, so you can generally expect them to be relatively stable. However, you *do* need to keep the version pinned and manually scan the GitHub commit log when updating between the pinned commits. - -**We expect that most people using React outside a curated setup (like a framework) will want to continue using the Stable releases.** However, if you're building a framework, you might want to consider bundling a Canary version of React pinned to a particular commit, and update it at your own pace. The benefit of that is that it lets you ship individual completed React features and bugfixes earlier for your users and at your own release schedule, similar to how React Native has been doing it for the last few years. The downside is that you would take on additional responsibility to communicate which React changes are included with your releases. - -If you're a framework author and want to try this approach, please get in touch with us. - -## Announcing breaking changes and new features early {/*announcing-breaking-changes-and-new-features-early*/} - -Canary releases represent our best guess of what will go into the next stable React release at any given time. - -Traditionally, we've only announced breaking changes at the *end* of the release cycle (when doing a major release). Now that Canary releases are an officially supported way to consume React, we plan to shift towards announcing breaking changes and significant new features *as they land* in Canaries. For example, if we merge a breaking change that will go out in a Canary, we will write a post about it on the React blog, including codemods and migration instructions if necessary. Then, if you're a framework author cutting a major release that updates the pinned React canary to include that change, you can link to our blog post from your release notes. Finally, when a stable major version of React is ready, we will link to those already published blog posts. - -We plan to document APIs as they land in Canaries--even if these APIs are not yet available outside of them. APIs that are only available in Canaries will be marked with a special note on the corresponding pages. This will include APIs like [`use`](https://github.com/reactjs/rfcs/pull/229), and some others (like `cache` and `createServerContext`) which we'll send RFCs for. - -## Canaries must be pinned {/*canaries-must-be-pinned*/} - -If you decide to adopt the Canary workflow for your app or framework, make sure you always pin the *exact* version of the Canary you're using. Since Canaries are pre-releases, they may still include breaking changes. - -## Example: React Server Components {/*example-react-server-components*/} - -As we [announced in March](/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023#react-server-components), the React Server Components conventions have been finalized, and we do not expect significant breaking changes related to their user-facing API contract. However, we can't release support for React Server Components in a stable version of React yet because we are still working on several intertwined framework-only features (such as [asset loading](/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023#asset-loading)) and expect more breaking changes there. - -This means that React Server Components are ready to be adopted by frameworks. However, until the next major React release, the only way for a framework to adopt them is to ship a pinned Canary version of React. (To avoid bundling two copies of React, frameworks that wish to do this would need to enforce resolution of `react` and `react-dom` to the pinned Canary they ship with their framework, and explain that to their users.) - -## Testing libraries against both Stable and Canary versions {/*testing-libraries-against-both-stable-and-canary-versions*/} - -We do not expect library authors to test every single Canary release since it would be prohibitively difficult. However, just as when we [originally introduced the different React pre-release channels three years ago](https://legacy.reactjs.org/blog/2019/10/22/react-release-channels.html), we encourage libraries to run tests against *both* the latest Stable and latest Canary versions. If you see a change in behavior that wasn't announced, please file a bug in the React repository so that we can help diagnose it. We expect that as this practice becomes widely adopted, it will reduce the amount of effort necessary to upgrade libraries to new major versions of React, since accidental regressions would be found as they land. - - - -Strictly speaking, Canary is not a *new* release channel--it used to be called Next. However, we've decided to rename it to avoid confusion with Next.js. We're announcing it as a *new* release channel to communicate the new expectations, such as Canaries being an officially supported way to use React. - - - -## Stable releases work like before {/*stable-releases-work-like-before*/} - -We are not introducing any changes to stable React releases. - - - diff --git a/src/content/blog/index.md b/src/content/blog/index.md index fc8a2969b..3459965f6 100644 --- a/src/content/blog/index.md +++ b/src/content/blog/index.md @@ -10,11 +10,6 @@ This blog is the official source for the updates from the React team. Anything i
- - -Traditionally, new React features used to only be available at Meta first, and land in the open source releases later. We'd like to offer the React community an option to adopt individual new features as soon as their design is close to final--similar to how Meta uses React internally. We are introducing a new officially supported Canary release channel. It lets curated setups like frameworks decouple adoption of individual React features from the React release schedule. - - diff --git a/src/content/community/versioning-policy.md b/src/content/community/versioning-policy.md index 68d5b8eb1..df3a730c7 100644 --- a/src/content/community/versioning-policy.md +++ b/src/content/community/versioning-policy.md @@ -79,18 +79,13 @@ This section will be most relevant to developers who work on frameworks, librari Each of React's release channels is designed for a distinct use case: -- [**Latest**](#latest-channel) is for stable, semver React releases. It's what you get when you install React from npm. This is the channel you're already using today. **User-facing applications that consume React directly use this channel.** -- [**Canary**](#canary-channel) tracks the main branch of the React source code repository. Think of these as release candidates for the next semver release. **[Frameworks or other curated setups may choose to use this channel with a pinned version of React.](/blog/2023/05/03/react-canaries) You can also Canaries for integration testing between React and third party projects.** +- [**Latest**](#latest-channel) is for stable, semver React releases. It's what you get when you install React from npm. This is the channel you're already using today. **Use this for all user-facing React applications.** +- [**Canary**](#canary-channel) tracks the main branch of the React source code repository. Think of these as release candidates for the next minor semver release. Use this for integration testing between React and third party projects. - [**Experimental**](#experimental-channel) includes experimental APIs and features that aren't available in the stable releases. These also track the main branch, but with additional feature flags turned on. Use this to try out upcoming features before they are released. All releases are published to npm, but only Latest uses semantic versioning. Prereleases (those in the Canary and Experimental channels) have versions generated from a hash of their contents and the commit date, e.g. `18.3.0-canary-388686f29-20230503` for Canary and `0.0.0-experimental-388686f29-20230503` for Experimental. -**Both Latest and Canary channels are officially supported for user-facing applications, but with different expectations**: - -* Latest releases follow the traditional semver model. -* Canary releases [must be pinned](/blog/2023/05/03/react-canaries) and may include breaking changes. They exist for curated setups (like frameworks) that want to gradually release new React features and bugfixes on their own release schedule. - -The Experimental releases are provided for testing purposes only, and we provide no guarantees that behavior won't change between releases. They do not follow the semver protocol that we use for releases from Latest. +**The only officially supported release channel for user-facing applications is Latest**. Canary and Experimental releases are provided for testing purposes only, and we provide no guarantees that behavior won't change between releases. They do not follow the semver protocol that we use for releases from Latest. By publishing prereleases to the same registry that we use for stable releases, we are able to take advantage of the many tools that support the npm workflow, like [unpkg](https://unpkg.com) and [CodeSandbox](https://codesandbox.io). @@ -98,7 +93,7 @@ By publishing prereleases to the same registry that we use for stable releases, Latest is the channel used for stable React releases. It corresponds to the `latest` tag on npm. It is the recommended channel for all React apps that are shipped to real users. -**If you're not sure which channel you should use, it's Latest.** If you're using React directly, this is what you're already using. You can expect updates to Latest to be extremely stable. Versions follow the semantic versioning scheme, as [described earlier.](#stable-releases) +**If you're not sure which channel you should use, it's Latest.** If you're a React developer, this is what you're already using. You can expect updates to Latest to be extremely stable. Versions follow the semantic versioning scheme, as [described earlier.](#stable-releases) ### Canary channel {/*canary-channel*/} @@ -106,13 +101,13 @@ The Canary channel is a prerelease channel that tracks the main branch of the Re The degree of change between the most recent Canary release and the most recent Latest release is approximately the same as you would find between two minor semver releases. However, **the Canary channel does not conform to semantic versioning.** You should expect occasional breaking changes between successive releases in the Canary channel. -**Do not use prereleases in user-facing applications directly unless you're following the [Canary workflow](/blog/2023/05/03/react-canaries).** +**Do not use prereleases in user-facing applications.** Releases in Canary are published with the `canary` tag on npm. Versions are generated from a hash of the build's contents and the commit date, e.g. `18.3.0-canary-388686f29-20230503`. #### Using the canary channel for integration testing {/*using-the-canary-channel-for-integration-testing*/} -The Canary channel also supports integration testing between React and other projects. +The Canary channel is designed to support integration testing between React and other projects. All changes to React go through extensive internal testing before they are released to the public. However, there are a myriad of environments and configurations used throughout the React ecosystem, and it's not possible for us to test against every single one. diff --git a/src/sidebarBlog.json b/src/sidebarBlog.json index 2141181b0..d6258e4a2 100644 --- a/src/sidebarBlog.json +++ b/src/sidebarBlog.json @@ -11,13 +11,6 @@ "path": "/blog", "skipBreadcrumb": true, "routes": [ - { - "title": "React Canaries: Enabling Incremental Feature Rollout Outside Meta", - "titleForHomepage": "React Canaries: Incremental Feature Rollout", - "icon": "blog", - "date": "May 3, 2023", - "path": "/blog/2023/05/03/react-canaries" - }, { "title": "React Labs: What We've Been Working On – March 2023", "titleForHomepage": "React Labs: March 2023", From 69ca3dfda09b7f36dbb3e668d3267f32ee7e4eb0 Mon Sep 17 00:00:00 2001 From: Elton Maiyo Date: Thu, 4 May 2023 00:20:43 +0300 Subject: [PATCH 05/83] Fixes grammar (#5967) --- src/content/learn/state-as-a-snapshot.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/learn/state-as-a-snapshot.md b/src/content/learn/state-as-a-snapshot.md index adf61e807..503b0abb4 100644 --- a/src/content/learn/state-as-a-snapshot.md +++ b/src/content/learn/state-as-a-snapshot.md @@ -327,7 +327,7 @@ But what if you wanted to read the latest state before a re-render? You'll want #### Implement a traffic light {/*implement-a-traffic-light*/} -Here is a crosswalk light component that toggles on when the button is pressed: +Here is a crosswalk light component that toggles when the button is pressed: From 1c55fe8a44616f5ae6eac23915eb5865576a0245 Mon Sep 17 00:00:00 2001 From: dan Date: Wed, 3 May 2023 23:07:50 +0100 Subject: [PATCH 06/83] Canaries blog post (#5993) * Revert "Revert "Canaries blog post"" This reverts commit 9a865fd5159b323c4c3e4c74b52e1bf720b36488. * words --------- Co-authored-by: Sophie Alpert --- src/content/blog/2023/05/03/react-canaries.md | 94 +++++++++++++++++++ src/content/blog/index.md | 5 + src/content/community/versioning-policy.md | 17 ++-- src/sidebarBlog.json | 7 ++ 4 files changed, 117 insertions(+), 6 deletions(-) create mode 100644 src/content/blog/2023/05/03/react-canaries.md diff --git a/src/content/blog/2023/05/03/react-canaries.md b/src/content/blog/2023/05/03/react-canaries.md new file mode 100644 index 000000000..00b725cc7 --- /dev/null +++ b/src/content/blog/2023/05/03/react-canaries.md @@ -0,0 +1,94 @@ +--- +title: "React Canaries: Enabling Incremental Feature Rollout Outside Meta" +--- + +May 3, 2023 by [Dan Abramov](https://twitter.com/dan_abramov), [Sophie Alpert](https://twitter.com/sophiebits), [Rick Hanlon](https://twitter.com/rickhanlonii), [Sebastian Markbåge](https://twitter.com/sebmarkbage), and [Andrew Clark](https://twitter.com/acdlite) + +--- + + + +Traditionally, Meta has run a bleeding-edge version of React in order to test new React features before they're released in a stable version. We'd like to offer the React community an option to adopt individual new features as soon as their design is close to final--similar to how Meta has used React internally. We are introducing a new officially supported [Canary release channel](/community/versioning-policy#canary-channel). It lets curated setups like frameworks decouple adoption of individual React features from the React release schedule. + + + +--- + +## tl;dr {/*tldr*/} + +* We're introducing an officially supported [Canary release channel](/community/versioning-policy#canary-channel) for React. Since it's officially supported, if any regressions land, we'll treat them with a similar urgency to bugs in stable releases. +* Canaries let you start using individual new React features before they land in the semver-stable releases. +* Unlike the [Experimental](/community/versioning-policy#experimental-channel) channel, React Canaries only include features that we reasonably believe to be ready for adoption. We encourage frameworks to consider bundling pinned Canary React releases. +* We will announce breaking changes and new features on our blog as they land in Canary releases. +* **As always, React continues to follow semver for every Stable release.** + +## How React features are usually developed {/*how-react-features-are-usually-developed*/} + +Typically, every React feature has gone through the same stages: + +1. We develop an initial version and prefix it with `experimental_` or `unstable_`. The feature is only available in the `experimental` release channel. At this point, the feature is expected to change significantly. +2. We find a team at Meta willing to help us test this feature and provide feedback on it. This leads to a round of changes. As the feature becomes more stable, we work with more teams at Meta to try it out. +3. Eventually, we feel confident in the design. We remove the prefix from the API name, and make the feature available on the `main` branch by default, which most Meta products use. At this point, any team at Meta can use this feature. +4. As we build confidence in the direction, we also post an RFC for the new feature. At this point we know the design works for a broad set of cases, but we might make some last minute adjustments. +5. When we are close to cutting an open source release, we write documentation for the feature and finally release the feature in a stable React release. + +This playbook works well for most features we've released so far. However, there can be a significant gap between when the feature is generally ready to use (step 3) and when it is released in open source (step 5). + +**We'd like to offer the React community an option to follow the same approach as Meta, and adopt individual new features earlier (as they become available) without having to wait for the next release cycle of React.** + +As always, all React features will eventually make it into a Stable release. + +## Can we just do more minor releases? {/*can-we-just-do-more-minor-releases*/} + +Generally, we *do* use minor releases for introducing new features. + +However, this isn't always possible. Sometimes, new features are interconnected with *other* new features which have not yet been fully completed and that we're still actively iterating on. We can't release them separately because their implementations are related. We can't version them separately because they affect the same packages (for example, `react` and `react-dom`). And we need to keep the ability to iterate on the pieces that aren't ready without a flurry of major version releases, which semver would require us to do. + +At Meta, we've solved this problem by building React from the `main` branch, and manually updating it to a specific pinned commit every week. This is also the approach that React Native releases have been following for the last several years. Every *stable* release of React Native is pinned to a specific commit from the `main` branch of the React repository. This lets React Native include important bugfixes and incrementally adopt new React features at the framework level without getting coupled to the global React release schedule. + +We would like to make this workflow available to other frameworks and curated setups. For example, it lets a framework *on top of* React include a React-related breaking change *before* this breaking change gets included into a stable React release. This is particularly useful because some breaking changes only affect framework integrations. This lets a framework release such a change in its own minor version without breaking semver. + +Rolling releases with the Canaries channel will allow us to have a tighter feedback loop and ensure that new features get comprehensive testing in the community. This workflow is closer to how TC39, the JavaScript standards committee, [handles changes in numbered stages](https://tc39.es/process-document/). New React features may be available in frameworks built on React before they are in a React stable release, just as new JavaScript features ship in browsers before they are officially ratified as part of the specification. + +## Why not use experimental releases instead? {/*why-not-use-experimental-releases-instead*/} + +Although you *can* technically use [Experimental releases](/community/versioning-policy#canary-channel), we recommend against using them in production because experimental APIs can undergo significant breaking changes on their way to stabilization (or can even be removed entirely). While Canaries can also contain mistakes (as with any release), going forward we plan to announce any significant breaking changes in Canaries on our blog. Canaries are the closest to the code Meta runs internally, so you can generally expect them to be relatively stable. However, you *do* need to keep the version pinned and manually scan the GitHub commit log when updating between the pinned commits. + +**We expect that most people using React outside a curated setup (like a framework) will want to continue using the Stable releases.** However, if you're building a framework, you might want to consider bundling a Canary version of React pinned to a particular commit, and update it at your own pace. The benefit of that is that it lets you ship individual completed React features and bugfixes earlier for your users and at your own release schedule, similar to how React Native has been doing it for the last few years. The downside is that you would take on additional responsibility to review which React commits are being pulled in and communicate to your users which React changes are included with your releases. + +If you're a framework author and want to try this approach, please get in touch with us. + +## Announcing breaking changes and new features early {/*announcing-breaking-changes-and-new-features-early*/} + +Canary releases represent our best guess of what will go into the next stable React release at any given time. + +Traditionally, we've only announced breaking changes at the *end* of the release cycle (when doing a major release). Now that Canary releases are an officially supported way to consume React, we plan to shift towards announcing breaking changes and significant new features *as they land* in Canaries. For example, if we merge a breaking change that will go out in a Canary, we will write a post about it on the React blog, including codemods and migration instructions if necessary. Then, if you're a framework author cutting a major release that updates the pinned React canary to include that change, you can link to our blog post from your release notes. Finally, when a stable major version of React is ready, we will link to those already published blog posts, which we hope will help our team make progress faster. + +We plan to document APIs as they land in Canaries--even if these APIs are not yet available outside of them. APIs that are only available in Canaries will be marked with a special note on the corresponding pages. This will include APIs like [`use`](https://github.com/reactjs/rfcs/pull/229), and some others (like `cache` and `createServerContext`) which we'll send RFCs for. + +## Canaries must be pinned {/*canaries-must-be-pinned*/} + +If you decide to adopt the Canary workflow for your app or framework, make sure you always pin the *exact* version of the Canary you're using. Since Canaries are pre-releases, they may still include breaking changes. + +## Example: React Server Components {/*example-react-server-components*/} + +As we [announced in March](/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023#react-server-components), the React Server Components conventions have been finalized, and we do not expect significant breaking changes related to their user-facing API contract. However, we can't release support for React Server Components in a stable version of React yet because we are still working on several intertwined framework-only features (such as [asset loading](/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023#asset-loading)) and expect more breaking changes there. + +This means that React Server Components are ready to be adopted by frameworks. However, until the next major React release, the only way for a framework to adopt them is to ship a pinned Canary version of React. (To avoid bundling two copies of React, frameworks that wish to do this would need to enforce resolution of `react` and `react-dom` to the pinned Canary they ship with their framework, and explain that to their users. As an example, this is what Next.js App Router does.) + +## Testing libraries against both Stable and Canary versions {/*testing-libraries-against-both-stable-and-canary-versions*/} + +We do not expect library authors to test every single Canary release since it would be prohibitively difficult. However, just as when we [originally introduced the different React pre-release channels three years ago](https://legacy.reactjs.org/blog/2019/10/22/react-release-channels.html), we encourage libraries to run tests against *both* the latest Stable and latest Canary versions. If you see a change in behavior that wasn't announced, please file a bug in the React repository so that we can help diagnose it. We expect that as this practice becomes widely adopted, it will reduce the amount of effort necessary to upgrade libraries to new major versions of React, since accidental regressions would be found as they land. + + + +Strictly speaking, Canary is not a *new* release channel--it used to be called Next. However, we've decided to rename it to avoid confusion with Next.js. We're announcing it as a *new* release channel to communicate the new expectations, such as Canaries being an officially supported way to use React. + + + +## Stable releases work like before {/*stable-releases-work-like-before*/} + +We are not introducing any changes to stable React releases. + + + diff --git a/src/content/blog/index.md b/src/content/blog/index.md index 3459965f6..fc8a2969b 100644 --- a/src/content/blog/index.md +++ b/src/content/blog/index.md @@ -10,6 +10,11 @@ This blog is the official source for the updates from the React team. Anything i
+ + +Traditionally, new React features used to only be available at Meta first, and land in the open source releases later. We'd like to offer the React community an option to adopt individual new features as soon as their design is close to final--similar to how Meta uses React internally. We are introducing a new officially supported Canary release channel. It lets curated setups like frameworks decouple adoption of individual React features from the React release schedule. + + diff --git a/src/content/community/versioning-policy.md b/src/content/community/versioning-policy.md index df3a730c7..68d5b8eb1 100644 --- a/src/content/community/versioning-policy.md +++ b/src/content/community/versioning-policy.md @@ -79,13 +79,18 @@ This section will be most relevant to developers who work on frameworks, librari Each of React's release channels is designed for a distinct use case: -- [**Latest**](#latest-channel) is for stable, semver React releases. It's what you get when you install React from npm. This is the channel you're already using today. **Use this for all user-facing React applications.** -- [**Canary**](#canary-channel) tracks the main branch of the React source code repository. Think of these as release candidates for the next minor semver release. Use this for integration testing between React and third party projects. +- [**Latest**](#latest-channel) is for stable, semver React releases. It's what you get when you install React from npm. This is the channel you're already using today. **User-facing applications that consume React directly use this channel.** +- [**Canary**](#canary-channel) tracks the main branch of the React source code repository. Think of these as release candidates for the next semver release. **[Frameworks or other curated setups may choose to use this channel with a pinned version of React.](/blog/2023/05/03/react-canaries) You can also Canaries for integration testing between React and third party projects.** - [**Experimental**](#experimental-channel) includes experimental APIs and features that aren't available in the stable releases. These also track the main branch, but with additional feature flags turned on. Use this to try out upcoming features before they are released. All releases are published to npm, but only Latest uses semantic versioning. Prereleases (those in the Canary and Experimental channels) have versions generated from a hash of their contents and the commit date, e.g. `18.3.0-canary-388686f29-20230503` for Canary and `0.0.0-experimental-388686f29-20230503` for Experimental. -**The only officially supported release channel for user-facing applications is Latest**. Canary and Experimental releases are provided for testing purposes only, and we provide no guarantees that behavior won't change between releases. They do not follow the semver protocol that we use for releases from Latest. +**Both Latest and Canary channels are officially supported for user-facing applications, but with different expectations**: + +* Latest releases follow the traditional semver model. +* Canary releases [must be pinned](/blog/2023/05/03/react-canaries) and may include breaking changes. They exist for curated setups (like frameworks) that want to gradually release new React features and bugfixes on their own release schedule. + +The Experimental releases are provided for testing purposes only, and we provide no guarantees that behavior won't change between releases. They do not follow the semver protocol that we use for releases from Latest. By publishing prereleases to the same registry that we use for stable releases, we are able to take advantage of the many tools that support the npm workflow, like [unpkg](https://unpkg.com) and [CodeSandbox](https://codesandbox.io). @@ -93,7 +98,7 @@ By publishing prereleases to the same registry that we use for stable releases, Latest is the channel used for stable React releases. It corresponds to the `latest` tag on npm. It is the recommended channel for all React apps that are shipped to real users. -**If you're not sure which channel you should use, it's Latest.** If you're a React developer, this is what you're already using. You can expect updates to Latest to be extremely stable. Versions follow the semantic versioning scheme, as [described earlier.](#stable-releases) +**If you're not sure which channel you should use, it's Latest.** If you're using React directly, this is what you're already using. You can expect updates to Latest to be extremely stable. Versions follow the semantic versioning scheme, as [described earlier.](#stable-releases) ### Canary channel {/*canary-channel*/} @@ -101,13 +106,13 @@ The Canary channel is a prerelease channel that tracks the main branch of the Re The degree of change between the most recent Canary release and the most recent Latest release is approximately the same as you would find between two minor semver releases. However, **the Canary channel does not conform to semantic versioning.** You should expect occasional breaking changes between successive releases in the Canary channel. -**Do not use prereleases in user-facing applications.** +**Do not use prereleases in user-facing applications directly unless you're following the [Canary workflow](/blog/2023/05/03/react-canaries).** Releases in Canary are published with the `canary` tag on npm. Versions are generated from a hash of the build's contents and the commit date, e.g. `18.3.0-canary-388686f29-20230503`. #### Using the canary channel for integration testing {/*using-the-canary-channel-for-integration-testing*/} -The Canary channel is designed to support integration testing between React and other projects. +The Canary channel also supports integration testing between React and other projects. All changes to React go through extensive internal testing before they are released to the public. However, there are a myriad of environments and configurations used throughout the React ecosystem, and it's not possible for us to test against every single one. diff --git a/src/sidebarBlog.json b/src/sidebarBlog.json index d6258e4a2..2141181b0 100644 --- a/src/sidebarBlog.json +++ b/src/sidebarBlog.json @@ -11,6 +11,13 @@ "path": "/blog", "skipBreadcrumb": true, "routes": [ + { + "title": "React Canaries: Enabling Incremental Feature Rollout Outside Meta", + "titleForHomepage": "React Canaries: Incremental Feature Rollout", + "icon": "blog", + "date": "May 3, 2023", + "path": "/blog/2023/05/03/react-canaries" + }, { "title": "React Labs: What We've Been Working On – March 2023", "titleForHomepage": "React Labs: March 2023", From 1863ab2cb585595f39251bb34380d23dbdc0f3bb Mon Sep 17 00:00:00 2001 From: Sophie Alpert Date: Wed, 3 May 2023 15:35:52 -0700 Subject: [PATCH 07/83] tweak --- src/content/blog/2023/05/03/react-canaries.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/blog/2023/05/03/react-canaries.md b/src/content/blog/2023/05/03/react-canaries.md index 00b725cc7..81da3fd00 100644 --- a/src/content/blog/2023/05/03/react-canaries.md +++ b/src/content/blog/2023/05/03/react-canaries.md @@ -8,7 +8,7 @@ May 3, 2023 by [Dan Abramov](https://twitter.com/dan_abramov), [Sophie Alpert](h -Traditionally, Meta has run a bleeding-edge version of React in order to test new React features before they're released in a stable version. We'd like to offer the React community an option to adopt individual new features as soon as their design is close to final--similar to how Meta has used React internally. We are introducing a new officially supported [Canary release channel](/community/versioning-policy#canary-channel). It lets curated setups like frameworks decouple adoption of individual React features from the React release schedule. +We'd like to offer the React community an option to adopt individual new features as soon as their design is close to final, before they're released in a stable version--similar to how Meta has long used bleeding-edge versions of React internally. We are introducing a new officially supported [Canary release channel](/community/versioning-policy#canary-channel). It lets curated setups like frameworks decouple adoption of individual React features from the React release schedule. From 8e24e40078c71e909096449cf04fea0a31bb1a7a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?S=C3=A9bastien=20Lorber?= Date: Fri, 5 May 2023 18:01:08 +0200 Subject: [PATCH 08/83] renderToReadableStream => renders a readable web stream (and not a Node.js stream) (#6001) --- .../reference/react-dom/server/renderToReadableStream.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/reference/react-dom/server/renderToReadableStream.md b/src/content/reference/react-dom/server/renderToReadableStream.md index 3f610d65a..d6d5b3264 100644 --- a/src/content/reference/react-dom/server/renderToReadableStream.md +++ b/src/content/reference/react-dom/server/renderToReadableStream.md @@ -26,7 +26,7 @@ This API depends on [Web Streams.](https://developer.mozilla.org/en-US/docs/Web/ ### `renderToReadableStream(reactNode, options?)` {/*rendertoreadablestream*/} -Call `renderToReadableStream` to render your React tree as HTML into a [Node.js Stream.](https://nodejs.org/api/stream.html#writable-streams) +Call `renderToReadableStream` to render your React tree as HTML into a [Readable Web Stream.](https://developer.mozilla.org/en-US/docs/Web/API/ReadableStream) ```js import { renderToReadableStream } from 'react-dom/server'; From fe5737bd0328ca7ce69fe432656efd469df6066a Mon Sep 17 00:00:00 2001 From: declval <123750459+declval@users.noreply.github.com> Date: Fri, 5 May 2023 16:01:29 +0000 Subject: [PATCH 09/83] Update Profiler.md (#6000) --- src/content/reference/react/Profiler.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/reference/react/Profiler.md b/src/content/reference/react/Profiler.md index 5bfa3b317..8e149634a 100644 --- a/src/content/reference/react/Profiler.md +++ b/src/content/reference/react/Profiler.md @@ -33,7 +33,7 @@ Wrap a component tree in a `` to measure its rendering performance. #### Props {/*props*/} * `id`: A string identifying the part of the UI you are measuring. -* `onRender`: An [`onRender` callback](#onrender-callback) that React calls it every time components within the profiled tree update. It receives information about what was rendered and how much time it took. +* `onRender`: An [`onRender` callback](#onrender-callback) that React calls every time components within the profiled tree update. It receives information about what was rendered and how much time it took. #### Caveats {/*caveats*/} From 01d44e9a38afff0cbe125cf9b7dea20b8a1ca6fc Mon Sep 17 00:00:00 2001 From: Hernani Fernandes Date: Fri, 5 May 2023 18:06:39 +0200 Subject: [PATCH 10/83] remove cancelled conference 2023 (#5999) --- src/content/community/conferences.md | 5 ----- 1 file changed, 5 deletions(-) diff --git a/src/content/community/conferences.md b/src/content/community/conferences.md index b1860ac0d..792dbeecf 100644 --- a/src/content/community/conferences.md +++ b/src/content/community/conferences.md @@ -60,11 +60,6 @@ August 17 & 18, 2023. Salt Lake City, UT, USA [Website](https://www.reactrally.com/) - [Twitter](https://twitter.com/ReactRally) - [Instagram](https://www.instagram.com/reactrally/) -### React On The Beach 2023 {/*react-on-the-beach-2023*/} -September 07, 2023. Amsterdam, Netherlands (In-person event) - -[Website](https://reactonthebeach.com/) - [Twitter](https://twitter.com/reactonthebeach) - ### React India 2023 {/*react-india-2023*/} Oct 5 - 7, 2023. In-person in Goa, India (hybrid event) + Oct 3 2023 - remote day From 07a3ee594f77cec139fa64258c4b0adb1672a5db Mon Sep 17 00:00:00 2001 From: Jan Kassens Date: Fri, 5 May 2023 13:58:18 -0400 Subject: [PATCH 11/83] Minor tweak to remove implication that mounting can happen only once (#6003) Mounting with Suspense and Offscreen can happen multiple times. This removes some wording that implies a that effects / lifecycle hooks only happen on first mount. --- src/content/reference/react/Component.md | 4 ++-- src/content/reference/react/useEffect.md | 2 +- src/content/reference/react/useInsertionEffect.md | 2 +- src/content/reference/react/useLayoutEffect.md | 6 +----- 4 files changed, 5 insertions(+), 9 deletions(-) diff --git a/src/content/reference/react/Component.md b/src/content/reference/react/Component.md index c1b605803..006ade5d8 100644 --- a/src/content/reference/react/Component.md +++ b/src/content/reference/react/Component.md @@ -248,7 +248,7 @@ There is no direct equivalent for `componentDidCatch` in function components yet ### `componentDidMount()` {/*componentdidmount*/} -If you define the `componentDidMount` method, React will call it when your component is first added *(mounted)* to the screen. This is a common place to start data fetching, set up subscriptions, or manipulate the DOM nodes. +If you define the `componentDidMount` method, React will call it when your component is added *(mounted)* to the screen. This is a common place to start data fetching, set up subscriptions, or manipulate the DOM nodes. If you implement `componentDidMount`, you usually need to implement other lifecycle methods to avoid bugs. For example, if `componentDidMount` reads some state or props, you also have to implement [`componentDidUpdate`](#componentdidupdate) to handle their changes, and [`componentWillUnmount`](#componentwillunmount) to clean up whatever `componentDidMount` was doing. @@ -1215,7 +1215,7 @@ We recommend defining components as functions instead of classes. [See how to mi There are a few special methods you can define on your class. -If you define the [`componentDidMount`](#componentdidmount) method, React will call it when your component is first added *(mounted)* to the screen. React will call [`componentDidUpdate`](#componentdidupdate) after your component re-renders due to changed props or state. React will call [`componentWillUnmount`](#componentwillunmount) after your component has been removed *(unmounted)* from the screen. +If you define the [`componentDidMount`](#componentdidmount) method, React will call it when your component is added *(mounted)* to the screen. React will call [`componentDidUpdate`](#componentdidupdate) after your component re-renders due to changed props or state. React will call [`componentWillUnmount`](#componentwillunmount) after your component has been removed *(unmounted)* from the screen. If you implement `componentDidMount`, you usually need to implement all three lifecycles to avoid bugs. For example, if `componentDidMount` reads some state or props, you also have to implement `componentDidUpdate` to handle their changes, and `componentWillUnmount` to clean up whatever `componentDidMount` was doing. diff --git a/src/content/reference/react/useEffect.md b/src/content/reference/react/useEffect.md index bc76bdfbe..8614991ca 100644 --- a/src/content/reference/react/useEffect.md +++ b/src/content/reference/react/useEffect.md @@ -44,7 +44,7 @@ function ChatRoom({ roomId }) { #### Parameters {/*parameters*/} -* `setup`: The function with your Effect's logic. Your setup function may also optionally return a *cleanup* function. When your component is first added to the DOM, React will run your setup function. After every re-render with changed dependencies, React will first run the cleanup function (if you provided it) with the old values, and then run your setup function with the new values. After your component is removed from the DOM, React will run your cleanup function one last time. +* `setup`: The function with your Effect's logic. Your setup function may also optionally return a *cleanup* function. When your component is added to the DOM, React will run your setup function. After every re-render with changed dependencies, React will first run the cleanup function (if you provided it) with the old values, and then run your setup function with the new values. After your component is removed from the DOM, React will run your cleanup function. * **optional** `dependencies`: The list of all reactive values referenced inside of the `setup` code. Reactive values include props, state, and all the variables and functions declared directly inside your component body. If your linter is [configured for React](/learn/editor-setup#linting), it will verify that every reactive value is correctly specified as a dependency. The list of dependencies must have a constant number of items and be written inline like `[dep1, dep2, dep3]`. React will compare each dependency with its previous value using the [`Object.is`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/is) comparison. If you omit this argument, your Effect will re-run after every re-render of the component. [See the difference between passing an array of dependencies, an empty array, and no dependencies at all.](#examples-dependencies) diff --git a/src/content/reference/react/useInsertionEffect.md b/src/content/reference/react/useInsertionEffect.md index 5c92db2e6..175b4476f 100644 --- a/src/content/reference/react/useInsertionEffect.md +++ b/src/content/reference/react/useInsertionEffect.md @@ -44,7 +44,7 @@ function useCSS(rule) { #### Parameters {/*parameters*/} -* `setup`: The function with your Effect's logic. Your setup function may also optionally return a *cleanup* function. Before your component is first added to the DOM, React will run your setup function. After every re-render with changed dependencies, React will first run the cleanup function (if you provided it) with the old values, and then run your setup function with the new values. Before your component is removed from the DOM, React will run your cleanup function one last time. +* `setup`: The function with your Effect's logic. Your setup function may also optionally return a *cleanup* function. Before your component is added to the DOM, React will run your setup function. After every re-render with changed dependencies, React will first run the cleanup function (if you provided it) with the old values, and then run your setup function with the new values. Before your component is removed from the DOM, React will run your cleanup function. * **optional** `dependencies`: The list of all reactive values referenced inside of the `setup` code. Reactive values include props, state, and all the variables and functions declared directly inside your component body. If your linter is [configured for React](/learn/editor-setup#linting), it will verify that every reactive value is correctly specified as a dependency. The list of dependencies must have a constant number of items and be written inline like `[dep1, dep2, dep3]`. React will compare each dependency with its previous value using the [`Object.is`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/is) comparison algorithm. If you don't specify the dependencies at all, your Effect will re-run after every re-render of the component. diff --git a/src/content/reference/react/useLayoutEffect.md b/src/content/reference/react/useLayoutEffect.md index fdbc50b3e..d30ebbd16 100644 --- a/src/content/reference/react/useLayoutEffect.md +++ b/src/content/reference/react/useLayoutEffect.md @@ -47,7 +47,7 @@ function Tooltip() { #### Parameters {/*parameters*/} -* `setup`: The function with your Effect's logic. Your setup function may also optionally return a *cleanup* function. Before your component is first added to the DOM, React will run your setup function. After every re-render with changed dependencies, React will first run the cleanup function (if you provided it) with the old values, and then run your setup function with the new values. Before your component is removed from the DOM, React will run your cleanup function one last time. +* `setup`: The function with your Effect's logic. Your setup function may also optionally return a *cleanup* function. Before your component is added to the DOM, React will run your setup function. After every re-render with changed dependencies, React will first run the cleanup function (if you provided it) with the old values, and then run your setup function with the new values. Before your component is removed from the DOM, React will run your cleanup function. * **optional** `dependencies`: The list of all reactive values referenced inside of the `setup` code. Reactive values include props, state, and all the variables and functions declared directly inside your component body. If your linter is [configured for React](/learn/editor-setup#linting), it will verify that every reactive value is correctly specified as a dependency. The list of dependencies must have a constant number of items and be written inline like `[dep1, dep2, dep3]`. React will compare each dependency with its previous value using the [`Object.is`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/is) comparison. If you omit this argument, your Effect will re-run after every re-render of the component. @@ -737,7 +737,3 @@ However, if you're running into this problem, you have a few different options: - Alternatively, you can render a component with `useLayoutEffect` only after hydration. Keep a boolean `isMounted` state that's initialized to `false`, and set it to `true` inside a `useEffect` call. Your rendering logic can then be like `return isMounted ? : `. On the server and during the hydration, the user will see `FallbackContent` which should not call `useLayoutEffect`. Then React will replace it with `RealContent` which runs on the client only and can include `useLayoutEffect` calls. - If you synchronize your component with an external data store and rely on `useLayoutEffect` for different reasons than measuring layout, consider [`useSyncExternalStore`](/reference/react/useSyncExternalStore) instead which [supports server rendering.](/reference/react/useSyncExternalStore#adding-support-for-server-rendering) - - - - From da93812c7802e916d75bbb293889fda42c8d06aa Mon Sep 17 00:00:00 2001 From: Sami Romdhana <64911368+sami-romdhana@users.noreply.github.com> Date: Sun, 7 May 2023 00:06:40 +0200 Subject: [PATCH 12/83] Conditionally render offset div (#5997) Otherwise the address is being offset to the right when the refresh icon is not displayed --- src/components/Layout/HomeContent.js | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/components/Layout/HomeContent.js b/src/components/Layout/HomeContent.js index 0597642ae..5ff366d31 100644 --- a/src/components/Layout/HomeContent.js +++ b/src/components/Layout/HomeContent.js @@ -1274,7 +1274,7 @@ function BrowserChrome({children, hasPulse, hasRefresh, domain, path}) {
-
+ {hasRefresh &&
}
Date: Fri, 12 May 2023 18:15:37 +0200 Subject: [PATCH 13/83] Remove unnecessary backticks breaking markdown highlighting (#6025) --- src/content/learn/removing-effect-dependencies.md | 4 ++-- src/content/learn/separating-events-from-effects.md | 6 +++--- src/content/learn/updating-objects-in-state.md | 2 +- src/content/reference/react-dom/client/createRoot.md | 4 ++-- src/content/reference/react-dom/client/hydrateRoot.md | 2 +- src/content/reference/react-dom/hydrate.md | 2 +- src/content/reference/react-dom/render.md | 2 +- src/content/reference/react-dom/unmountComponentAtNode.md | 2 +- src/content/reference/react/cloneElement.md | 2 +- src/content/reference/react/createContext.md | 2 +- src/content/reference/react/useEffect.md | 2 +- 11 files changed, 15 insertions(+), 15 deletions(-) diff --git a/src/content/learn/removing-effect-dependencies.md b/src/content/learn/removing-effect-dependencies.md index dc34eedad..0a5151daa 100644 --- a/src/content/learn/removing-effect-dependencies.md +++ b/src/content/learn/removing-effect-dependencies.md @@ -882,7 +882,7 @@ const options2 = { serverUrl: 'https://localhost:1234', roomId: 'music' }; // These are two different objects! console.log(Object.is(options1, options2)); // false -```` +``` **Object and function dependencies can make your Effect re-synchronize more often than you need.** @@ -968,7 +968,7 @@ const roomId2 = 'music'; // These two strings are the same! console.log(Object.is(roomId1, roomId2)); // true -```` +``` Thanks to this fix, the chat no longer re-connects if you edit the input: diff --git a/src/content/learn/separating-events-from-effects.md b/src/content/learn/separating-events-from-effects.md index e932e8afd..a897a602b 100644 --- a/src/content/learn/separating-events-from-effects.md +++ b/src/content/learn/separating-events-from-effects.md @@ -239,7 +239,7 @@ function ChatRoom({ roomId, theme }) { }); connection.connect(); // ... -```` +``` However, `theme` is a reactive value (it can change as a result of re-rendering), and [every reactive value read by an Effect must be declared as its dependency.](/learn/lifecycle-of-reactive-effects#react-verifies-that-you-specified-every-reactive-value-as-a-dependency) Now you have to specify `theme` as a dependency of your Effect: @@ -256,7 +256,7 @@ function ChatRoom({ roomId, theme }) { }; }, [roomId, theme]); // ✅ All dependencies declared // ... -```` +``` Play with this example and see if you can spot the problem with this user experience: @@ -416,7 +416,7 @@ function ChatRoom({ roomId, theme }) { showNotification('Connected!', theme); }); // ... -```` +``` Here, `onConnected` is called an *Effect Event.* It's a part of your Effect logic, but it behaves a lot more like an event handler. The logic inside it is not reactive, and it always "sees" the latest values of your props and state. diff --git a/src/content/learn/updating-objects-in-state.md b/src/content/learn/updating-objects-in-state.md index 1e23c8d3d..9289f2454 100644 --- a/src/content/learn/updating-objects-in-state.md +++ b/src/content/learn/updating-objects-in-state.md @@ -184,7 +184,7 @@ const nextPosition = {}; nextPosition.x = e.clientX; nextPosition.y = e.clientY; setPosition(nextPosition); -```` +``` In fact, it is completely equivalent to writing this: diff --git a/src/content/reference/react-dom/client/createRoot.md b/src/content/reference/react-dom/client/createRoot.md index 9121e1d78..d91bc20c6 100644 --- a/src/content/reference/react-dom/client/createRoot.md +++ b/src/content/reference/react-dom/client/createRoot.md @@ -133,7 +133,7 @@ import { createRoot } from 'react-dom/client'; const root = createRoot(document.getElementById('root')); root.render(); -```` +``` Usually, you only need to run this code once at startup. It will: @@ -395,7 +395,7 @@ root.render(App); // ✅ Correct: is a component. root.render(); -```` +``` Or if you pass a function to `root.render`, instead of the result of calling it: diff --git a/src/content/reference/react-dom/client/hydrateRoot.md b/src/content/reference/react-dom/client/hydrateRoot.md index c875560da..db558bb80 100644 --- a/src/content/reference/react-dom/client/hydrateRoot.md +++ b/src/content/reference/react-dom/client/hydrateRoot.md @@ -127,7 +127,7 @@ If your app's HTML was generated by [`react-dom/server`](/reference/react-dom/cl import { hydrateRoot } from 'react-dom/client'; hydrateRoot(document.getElementById('root'), ); -```` +``` This will hydrate the server HTML inside the browser DOM node with the React component for your app. Usually, you will do it once at startup. If you use a framework, it might do this behind the scenes for you. diff --git a/src/content/reference/react-dom/hydrate.md b/src/content/reference/react-dom/hydrate.md index ab036caa1..639c7ab25 100644 --- a/src/content/reference/react-dom/hydrate.md +++ b/src/content/reference/react-dom/hydrate.md @@ -68,7 +68,7 @@ Call `hydrate` to attach a React component into a import { hydrate } from 'react-dom'; hydrate(, document.getElementById('root')); -```` +``` Using `hydrate()` to render a client-only app (an app without server-rendered HTML) is not supported. Use [`render()`](/reference/react-dom/render) (in React 17 and below) or [`createRoot()`](/reference/react-dom/client/createRoot) (in React 18+) instead. diff --git a/src/content/reference/react-dom/render.md b/src/content/reference/react-dom/render.md index 1a3baead7..a0f751278 100644 --- a/src/content/reference/react-dom/render.md +++ b/src/content/reference/react-dom/render.md @@ -77,7 +77,7 @@ import { render } from 'react-dom'; import App from './App.js'; render(, document.getElementById('root')); -```` +``` ### Rendering the root component {/*rendering-the-root-component*/} diff --git a/src/content/reference/react-dom/unmountComponentAtNode.md b/src/content/reference/react-dom/unmountComponentAtNode.md index e538ceb34..12f11dc74 100644 --- a/src/content/reference/react-dom/unmountComponentAtNode.md +++ b/src/content/reference/react-dom/unmountComponentAtNode.md @@ -64,7 +64,7 @@ render(, rootNode); // ... unmountComponentAtNode(rootNode); -```` +``` ### Removing a React app from a DOM element {/*removing-a-react-app-from-a-dom-element*/} diff --git a/src/content/reference/react/cloneElement.md b/src/content/reference/react/cloneElement.md index 86711f4d8..d6ef84b0a 100644 --- a/src/content/reference/react/cloneElement.md +++ b/src/content/reference/react/cloneElement.md @@ -427,7 +427,7 @@ With this approach, `Row` does not need to receive an `isHighlighted` prop at al export default function Row({ title }) { const isHighlighted = useContext(HighlightContext); // ... -```` +``` This allows the calling component to not know or worry about passing `isHighlighted` to ``: diff --git a/src/content/reference/react/createContext.md b/src/content/reference/react/createContext.md index ff9032aac..a653633c1 100644 --- a/src/content/reference/react/createContext.md +++ b/src/content/reference/react/createContext.md @@ -166,7 +166,7 @@ import { createContext } from 'react'; export const ThemeContext = createContext('light'); export const AuthContext = createContext(null); -```` +``` Components declared in other files can then use the [`import`](https://developer.mozilla.org/en-US/docs/web/javascript/reference/statements/import) statement to read or provide this context: diff --git a/src/content/reference/react/useEffect.md b/src/content/reference/react/useEffect.md index 8614991ca..dd84fd2ea 100644 --- a/src/content/reference/react/useEffect.md +++ b/src/content/reference/react/useEffect.md @@ -531,7 +531,7 @@ function ChatRoom({ roomId }) { serverUrl: serverUrl }); // ... -```` +``` There are also many excellent custom Hooks for every purpose available in the React ecosystem. From fd8ba03f4d7222ac4813374843a44755fc8c64c4 Mon Sep 17 00:00:00 2001 From: Choi siun Date: Wed, 17 May 2023 03:01:40 +0900 Subject: [PATCH 14/83] docs(types): Fix incorrect period positioning in common.md (#6040) --- src/content/reference/react-dom/components/common.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/reference/react-dom/components/common.md b/src/content/reference/react-dom/components/common.md index ca16b6a6e..b8b80ea2f 100644 --- a/src/content/reference/react-dom/components/common.md +++ b/src/content/reference/react-dom/components/common.md @@ -156,7 +156,7 @@ nt. * [`title`](https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/title): A string. Specifies the tooltip text for the element. * [`translate`](https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/translate): Either `'yes'` or `'no'`. Passing `'no'` excludes the element content from being translated. -You can also pass custom attributes as props, for example `mycustomprop="someValue".` This can be useful when integrating with third-party libraries. The custom attribute name must be lowercase and must not start with `on`. The value will be converted to a string. If you pass `null` or `undefined`, the custom attribute will be removed. +You can also pass custom attributes as props, for example `mycustomprop="someValue"`. This can be useful when integrating with third-party libraries. The custom attribute name must be lowercase and must not start with `on`. The value will be converted to a string. If you pass `null` or `undefined`, the custom attribute will be removed. These events fire only for the [`
`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/form) elements: From bea2ff778d489eb0401eef173a3b7bf74563930e Mon Sep 17 00:00:00 2001 From: vicsantizo <68677648+vicsantizo@users.noreply.github.com> Date: Tue, 16 May 2023 12:01:59 -0600 Subject: [PATCH 15/83] fix(typos): replace word "ever" with "every" (#6039) --- src/content/reference/react-dom/components/common.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/reference/react-dom/components/common.md b/src/content/reference/react-dom/components/common.md index b8b80ea2f..f1e4fcd0c 100644 --- a/src/content/reference/react-dom/components/common.md +++ b/src/content/reference/react-dom/components/common.md @@ -260,7 +260,7 @@ React will also call your `ref` callback whenever you pass a *different* `ref` c #### Parameters {/*ref-callback-parameters*/} -* `node`: A DOM node or `null`. React will pass you the DOM node when the ref gets attached, and `null` when the ref gets detached. Unless you pass the same function reference for the `ref` callback on every render, the callback will get temporarily detached and re-attached during ever re-render of the component. +* `node`: A DOM node or `null`. React will pass you the DOM node when the ref gets attached, and `null` when the ref gets detached. Unless you pass the same function reference for the `ref` callback on every render, the callback will get temporarily detached and re-attached during every re-render of the component. #### Returns {/*returns*/} From 5bc25d3c36b6e67cd2d86a1145daf6dfa21d4f40 Mon Sep 17 00:00:00 2001 From: Kathryn Middleton Date: Thu, 18 May 2023 12:48:40 -0400 Subject: [PATCH 16/83] Add accessibility note to interactivity section in the new React docs (#6026) * Add accessibility note to interactivity section in the new React docs * Add a11y note to Responding to Events section * Update responding-to-events.md --------- Co-authored-by: dan --- src/content/learn/responding-to-events.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/content/learn/responding-to-events.md b/src/content/learn/responding-to-events.md index 782b6c0f1..4450c4613 100644 --- a/src/content/learn/responding-to-events.md +++ b/src/content/learn/responding-to-events.md @@ -313,6 +313,12 @@ button { margin-right: 10px; } Notice how the `App` component does not need to know *what* `Toolbar` will do with `onPlayMovie` or `onUploadImage`. That's an implementation detail of the `Toolbar`. Here, `Toolbar` passes them down as `onClick` handlers to its `Button`s, but it could later also trigger them on a keyboard shortcut. Naming props after app-specific interactions like `onPlayMovie` gives you the flexibility to change how they're used later. + + + +Make sure that you use the appropriate HTML tags for your event handlers. For example, to handle clicks, use [`
`. Using a real browser `
- - - - React - + + + React
diff --git a/src/components/MDX/BlogCard.tsx b/src/components/MDX/BlogCard.tsx index 9d86f9211..ba610b111 100644 --- a/src/components/MDX/BlogCard.tsx +++ b/src/components/MDX/BlogCard.tsx @@ -16,62 +16,62 @@ export interface BlogCardProps { function BlogCard({title, badge, date, icon, url, children}: BlogCardProps) { return ( - - -
-
-

- {title} -

-
-
-
- {icon === 'labs' && ( - - - - )} - {icon === 'blog' && ( - - - - )} - {date} - {badge ? ( -
- New -
- ) : null} -
- - {children} - - {children != null && ( -
- Read more -
+ + ); } diff --git a/src/components/MDX/Link.tsx b/src/components/MDX/Link.tsx index 8986d07a5..7bf041e56 100644 --- a/src/components/MDX/Link.tsx +++ b/src/components/MDX/Link.tsx @@ -13,7 +13,7 @@ function Link({ className, children, ...props -}: JSX.IntrinsicElements['a']) { +}: React.AnchorHTMLAttributes) { const classes = 'inline text-link dark:text-link-dark border-b border-link border-opacity-0 hover:border-opacity-100 duration-100 ease-in transition leading-normal'; const modifiedChildren = Children.toArray(children).map((child: any) => { @@ -41,11 +41,8 @@ function Link({ {modifiedChildren} ) : ( - - {/* eslint-disable-next-line jsx-a11y/anchor-has-content */} - - {modifiedChildren} - + + {modifiedChildren} )} diff --git a/src/components/MDX/Sandpack/DownloadButton.tsx b/src/components/MDX/Sandpack/DownloadButton.tsx index 4181dbe95..4d206fff8 100644 --- a/src/components/MDX/Sandpack/DownloadButton.tsx +++ b/src/components/MDX/Sandpack/DownloadButton.tsx @@ -7,19 +7,22 @@ import {useSandpack} from '@codesandbox/sandpack-react'; import {IconDownload} from '../../Icon/IconDownload'; export interface DownloadButtonProps {} -let supportsImportMap: boolean | void; +let supportsImportMap = false; + +function subscribe(cb: () => void) { + // This shouldn't actually need to update, but this works around + // https://github.com/facebook/react/issues/26095 + let timeout = setTimeout(() => { + supportsImportMap = + (HTMLScriptElement as any).supports && + (HTMLScriptElement as any).supports('importmap'); + cb(); + }, 0); + return () => clearTimeout(timeout); +} function useSupportsImportMap() { - function subscribe() { - // It never updates. - return () => {}; - } function getCurrentValue() { - if (supportsImportMap === undefined) { - supportsImportMap = - (HTMLScriptElement as any).supports && - (HTMLScriptElement as any).supports('importmap'); - } return supportsImportMap; } function getServerSnapshot() { diff --git a/src/components/Search.tsx b/src/components/Search.tsx index 0e8f84f0d..2a9743ec3 100644 --- a/src/components/Search.tsx +++ b/src/components/Search.tsx @@ -22,11 +22,7 @@ export interface SearchProps { } function Hit({hit, children}: any) { - return ( - - {children} - - ); + return {children}; } // Copy-pasted from @docsearch/react to avoid importing the whole bundle. diff --git a/yarn.lock b/yarn.lock index 5aa76ffbe..d6e0c82c1 100644 --- a/yarn.lock +++ b/yarn.lock @@ -896,10 +896,10 @@ unist-util-visit "^4.0.0" vfile "^5.0.0" -"@next/env@12.3.2-canary.7": - version "12.3.2-canary.7" - resolved "https://registry.yarnpkg.com/@next/env/-/env-12.3.2-canary.7.tgz#98cf3ed5e7d6af93965c708799ac02cb46ca3831" - integrity sha512-uk5yDvh8ra8PlIczZBTZKyt5Rf6a6mH2tGB3hwRAXD5hVLd74LzBQza2aYMEcDlRafAknsbL0dnqI3CkFYat9w== +"@next/env@13.4.1": + version "13.4.1" + resolved "https://registry.yarnpkg.com/@next/env/-/env-13.4.1.tgz#57322da2630b6bb6d7204577b0a18f6f9324db0c" + integrity sha512-eD6WCBMFjLFooLM19SIhSkWBHtaFrZFfg2Cxnyl3vS3DAdFRfnx5TY2RxlkuKXdIRCC0ySbtK9JXXt8qLCqzZg== "@next/eslint-plugin-next@12.0.3": version "12.0.3" @@ -908,70 +908,50 @@ dependencies: glob "7.1.7" -"@next/swc-android-arm-eabi@12.3.2-canary.7": - version "12.3.2-canary.7" - resolved "https://registry.yarnpkg.com/@next/swc-android-arm-eabi/-/swc-android-arm-eabi-12.3.2-canary.7.tgz#21811767685d8a58756bbfff23a4e61c8da65a15" - integrity sha512-pusM/ylasGBweiwhINtqWCgy5bOjLmIctFD0etpmh9+DqCg09yu58hJ1Dn/UTW8EbB1nkTP1z3dEoMKLh4fV2A== - -"@next/swc-android-arm64@12.3.2-canary.7": - version "12.3.2-canary.7" - resolved "https://registry.yarnpkg.com/@next/swc-android-arm64/-/swc-android-arm64-12.3.2-canary.7.tgz#278e709c31ac5aceebd5e7f66efb81dae40ccab6" - integrity sha512-x11T0ocPE9xrnqMeDzUMepN3P8CHIN8iiLgiFkbTbKTbSciuH3juOvKggJO9APZRG5Ch5eePWcCy2gHedAbhnA== - -"@next/swc-darwin-arm64@12.3.2-canary.7": - version "12.3.2-canary.7" - resolved "https://registry.yarnpkg.com/@next/swc-darwin-arm64/-/swc-darwin-arm64-12.3.2-canary.7.tgz#7858ecf88a4e252ef6b66c59e38449a79647e362" - integrity sha512-tcO9hDaMfcbiaZp1B+HZcLzGGs36dnmjQ0YXyn6C88HEUoKyxanYleVHtTmWHlgsxxjZdDd/RzOze1ycWs2oXw== - -"@next/swc-darwin-x64@12.3.2-canary.7": - version "12.3.2-canary.7" - resolved "https://registry.yarnpkg.com/@next/swc-darwin-x64/-/swc-darwin-x64-12.3.2-canary.7.tgz#9225324b6de548ce7fd21c31d4725910c5b7d136" - integrity sha512-WjAyU67zj69nRM2GNAnBLvghq4EHTyDzMO02GjG6yexVhDvkE0OFlvh0BQLI3DIOz+B3RjJRcW3OoHi8XzW9UA== - -"@next/swc-freebsd-x64@12.3.2-canary.7": - version "12.3.2-canary.7" - resolved "https://registry.yarnpkg.com/@next/swc-freebsd-x64/-/swc-freebsd-x64-12.3.2-canary.7.tgz#cf3374f2c3ddf370ed27cac84258760b282b6981" - integrity sha512-cQrdPCMhP1Mc+pIt16FlC5BVgcXzLXRlm7qZ7wBRKG6r/IIIn/qNRFgQQcB3iyvfNZo7lURLKcfsxNmMGclldQ== - -"@next/swc-linux-arm-gnueabihf@12.3.2-canary.7": - version "12.3.2-canary.7" - resolved "https://registry.yarnpkg.com/@next/swc-linux-arm-gnueabihf/-/swc-linux-arm-gnueabihf-12.3.2-canary.7.tgz#b8e82ec743ceadfce25b7e74dfb447913b603c44" - integrity sha512-LEL+dUe10FhQHyXq9Mul5pOJwKDtrAylh9chktWf8eFr14j/YrfPbkLHv1+tCK8brDV3afVJMl0IpoCo75Yfyg== - -"@next/swc-linux-arm64-gnu@12.3.2-canary.7": - version "12.3.2-canary.7" - resolved "https://registry.yarnpkg.com/@next/swc-linux-arm64-gnu/-/swc-linux-arm64-gnu-12.3.2-canary.7.tgz#1711f46f004553f3c8ab7546b49e65f88abbbfd6" - integrity sha512-mbDqHk3C76UGIzkOv+G5NslKiSYIXyWQwbkuty0+0wLVJttWjWi2dMN7DFJQPMNvBefU9/vxVJdUnGVGEZfUXw== - -"@next/swc-linux-arm64-musl@12.3.2-canary.7": - version "12.3.2-canary.7" - resolved "https://registry.yarnpkg.com/@next/swc-linux-arm64-musl/-/swc-linux-arm64-musl-12.3.2-canary.7.tgz#e20b71ce215280bc2cadcf94f9755fdf3ffc0b24" - integrity sha512-gJ3VQHuqb3ABiOKPxfWAJQdO4mp3yNnWIAPN8n52F7Zu38udbHXvcbIylWfQW/Qah+RRf7P7y2txH2kC07QOPA== - -"@next/swc-linux-x64-gnu@12.3.2-canary.7": - version "12.3.2-canary.7" - resolved "https://registry.yarnpkg.com/@next/swc-linux-x64-gnu/-/swc-linux-x64-gnu-12.3.2-canary.7.tgz#176cf50080f121537877dbdfb7d667be19333a8c" - integrity sha512-/PBLiC+JfMJIzwMCQaSQgnLoIOjdSjTA9zarj2Kk1eCLjH8/VnsfBWtmP7TdbgIRYnZ8QKb4HXSOq94ZQS/fkw== - -"@next/swc-linux-x64-musl@12.3.2-canary.7": - version "12.3.2-canary.7" - resolved "https://registry.yarnpkg.com/@next/swc-linux-x64-musl/-/swc-linux-x64-musl-12.3.2-canary.7.tgz#96b858043d76b87f90b7da43afe13c5942dbceea" - integrity sha512-Bf3goHoUd0SB58sVTMva0ByoLM+aEhm5YJRqsi7SsOAu9EAQwYfWgY2Hx60ah5i1N4ihYK0xjs8kwlfdDVOuow== - -"@next/swc-win32-arm64-msvc@12.3.2-canary.7": - version "12.3.2-canary.7" - resolved "https://registry.yarnpkg.com/@next/swc-win32-arm64-msvc/-/swc-win32-arm64-msvc-12.3.2-canary.7.tgz#dd1a36d4afbecc623e71426897cea683a3a75666" - integrity sha512-aPRQ4dY5MuLgHCVdY+/Grgg4oX38pG4S0sT8mpatK3oIdjhj3961cj33QpPAy6dhhCs8m0/eCWYmM9KKlAAUsg== - -"@next/swc-win32-ia32-msvc@12.3.2-canary.7": - version "12.3.2-canary.7" - resolved "https://registry.yarnpkg.com/@next/swc-win32-ia32-msvc/-/swc-win32-ia32-msvc-12.3.2-canary.7.tgz#a7455ea57f88345a92c0067e82aa1b7aa5728088" - integrity sha512-hr+TBDICVezyn0HDK4QootalbcuLj9F8qUzZZAw3gHz16rUDpqpnlRjw3RC99AzkKL7qMsdR/+SwnBlBY7ZK7Q== - -"@next/swc-win32-x64-msvc@12.3.2-canary.7": - version "12.3.2-canary.7" - resolved "https://registry.yarnpkg.com/@next/swc-win32-x64-msvc/-/swc-win32-x64-msvc-12.3.2-canary.7.tgz#4e0d6d567c254e2cf00738f876ddafe5b611ee03" - integrity sha512-1n29b6meb54h/Mw/1xPoJB682nWbtEsUQo7rFJ6G44Nj3fYFXe+XOWQxWu6Sl8yvdBXcZRhRCHuAZGqYtmqorQ== +"@next/swc-darwin-arm64@13.4.1": + version "13.4.1" + resolved "https://registry.yarnpkg.com/@next/swc-darwin-arm64/-/swc-darwin-arm64-13.4.1.tgz#3748040d2dd0d89d3cdcc897f96aeda5130eed8f" + integrity sha512-eF8ARHtYfnoYtDa6xFHriUKA/Mfj/cCbmKb3NofeKhMccs65G6/loZ15a6wYCCx4rPAd6x4t1WmVYtri7EdeBg== + +"@next/swc-darwin-x64@13.4.1": + version "13.4.1" + resolved "https://registry.yarnpkg.com/@next/swc-darwin-x64/-/swc-darwin-x64-13.4.1.tgz#c59fc270005f17e04eb7eab4fd68793d0e3409a4" + integrity sha512-7cmDgF9tGWTgn5Gw+vP17miJbH4wcraMHDCOHTYWkO/VeKT73dUWG23TNRLfgtCNSPgH4V5B4uLHoZTanx9bAw== + +"@next/swc-linux-arm64-gnu@13.4.1": + version "13.4.1" + resolved "https://registry.yarnpkg.com/@next/swc-linux-arm64-gnu/-/swc-linux-arm64-gnu-13.4.1.tgz#1aef371bcef5d832d7f7e3aec3e68cfb98282393" + integrity sha512-qwJqmCri2ie8aTtE5gjTSr8S6O8B67KCYgVZhv9gKH44yvc/zXbAY8u23QGULsYOyh1islWE5sWfQNLOj9iryg== + +"@next/swc-linux-arm64-musl@13.4.1": + version "13.4.1" + resolved "https://registry.yarnpkg.com/@next/swc-linux-arm64-musl/-/swc-linux-arm64-musl-13.4.1.tgz#2522927cb0af6918405a49f5a1d1687d6847f3ec" + integrity sha512-qcC54tWNGDv/VVIFkazxhqH1Bnagjfs4enzELVRlUOoJPD2BGJTPI7z08pQPbbgxLtRiu8gl2mXvpB8WlOkMeA== + +"@next/swc-linux-x64-gnu@13.4.1": + version "13.4.1" + resolved "https://registry.yarnpkg.com/@next/swc-linux-x64-gnu/-/swc-linux-x64-gnu-13.4.1.tgz#5ec9418a35510048a5ceb79ed300463e1a9b312d" + integrity sha512-9TeWFlpLsBosZ+tsm/rWBaMwt5It9tPH8m3nawZqFUUrZyGRfGcI67js774vtx0k3rL9qbyY6+3pw9BCVpaYUA== + +"@next/swc-linux-x64-musl@13.4.1": + version "13.4.1" + resolved "https://registry.yarnpkg.com/@next/swc-linux-x64-musl/-/swc-linux-x64-musl-13.4.1.tgz#3478b9c89b75c1d0e7def9f35a9a77cb15d1a115" + integrity sha512-sNDGaWmSqTS4QRUzw61wl4mVPeSqNIr1OOjLlQTRuyInxMxtqImRqdvzDvFTlDfdeUMU/DZhWGYoHrXLlZXe6A== + +"@next/swc-win32-arm64-msvc@13.4.1": + version "13.4.1" + resolved "https://registry.yarnpkg.com/@next/swc-win32-arm64-msvc/-/swc-win32-arm64-msvc-13.4.1.tgz#efe53d48ff51d2485eabb910ab7caee78425fc01" + integrity sha512-+CXZC7u1iXdLRudecoUYbhbsXpglYv8KFYsFxKBPn7kg+bk7eJo738wAA4jXIl8grTF2mPdmO93JOQym+BlYGA== + +"@next/swc-win32-ia32-msvc@13.4.1": + version "13.4.1" + resolved "https://registry.yarnpkg.com/@next/swc-win32-ia32-msvc/-/swc-win32-ia32-msvc-13.4.1.tgz#952cdf1c53df46a90d5151d99310195d2c384e55" + integrity sha512-vIoXVVc7UYO68VwVMDKwJC2+HqAZQtCYiVlApyKEeIPIQpz2gpufzGxk1z3/gwrJt/kJ5CDZjlhYDCzd3hdz+g== + +"@next/swc-win32-x64-msvc@13.4.1": + version "13.4.1" + resolved "https://registry.yarnpkg.com/@next/swc-win32-x64-msvc/-/swc-win32-x64-msvc-13.4.1.tgz#447b7dcee5f5d4824cdff331a4ec34b13d0b449d" + integrity sha512-n8V5ImLQZibKTu10UUdI3nIeTLkliEXe628qxqW9v8My3BAH2a7H0SaCqkV2OgqFnn8sG1wxKYw9/SNJ632kSA== "@nodelib/fs.scandir@2.1.5": version "2.1.5" @@ -1022,10 +1002,10 @@ resolved "https://registry.yarnpkg.com/@stitches/core/-/core-1.2.8.tgz#dce3b8fdc764fbc6dbea30c83b73bfb52cf96173" integrity sha512-Gfkvwk9o9kE9r9XNBmJRfV8zONvXThnm1tcuojL04Uy5uRyqg93DC83lDebl0rocZCfKSjUv+fWYtMQmEDJldg== -"@swc/helpers@0.4.11": - version "0.4.11" - resolved "https://registry.yarnpkg.com/@swc/helpers/-/helpers-0.4.11.tgz#db23a376761b3d31c26502122f349a21b592c8de" - integrity sha512-rEUrBSGIoSFuYxwBYtlUFMlE2CwGhmW+w9355/5oduSw8e5h2+Tj4UrAGNNgP9915++wj5vkQo0UuOBqOAq4nw== +"@swc/helpers@0.5.1": + version "0.5.1" + resolved "https://registry.yarnpkg.com/@swc/helpers/-/helpers-0.5.1.tgz#e9031491aa3f26bfcc974a67f48bd456c8a5357a" + integrity sha512-sJ902EfIzn1Fa+qYmjdQqh8tPsoxyBz+8yBKC2HKUxyezKJFwPGOn7pv4WY6QuQW//ySQi5lJjA/ZT9sNWWNTg== dependencies: tslib "^2.4.0" @@ -1684,6 +1664,13 @@ browserslist@^4.20.2: node-releases "^2.0.6" update-browserslist-db "^1.0.5" +busboy@1.6.0: + version "1.6.0" + resolved "https://registry.yarnpkg.com/busboy/-/busboy-1.6.0.tgz#966ea36a9502e43cdb9146962523b92f531f6893" + integrity sha512-8SFQbg/0hQ9xy3UNTB0YEnsNBbWfhf7RtnzpL7TkBiTBRfrQ9Fxcnz7VJsleJpyp6rVLvXiuORqjlHi5q+PYuA== + dependencies: + streamsearch "^1.1.0" + bytes@3.1.2: version "3.1.2" resolved "https://registry.yarnpkg.com/bytes/-/bytes-3.1.2.tgz#8b0beeb98605adf1b128fa4386403c009e0221a5" @@ -1852,6 +1839,11 @@ cli-truncate@^3.1.0: slice-ansi "^5.0.0" string-width "^5.0.0" +client-only@0.0.1: + version "0.0.1" + resolved "https://registry.yarnpkg.com/client-only/-/client-only-0.0.1.tgz#38bba5d403c41ab150bff64a95c85013cf73bca1" + integrity sha512-IV3Ou0jSMzZrd3pZ48nLkT9DA7Ag1pnPzaiQhpW7c3RbcqqzvzzVu+L8gfqMp/8IM2MQtSiqaCxrrcfu8I8rMA== + codesandbox-import-util-types@^1.3.7: version "1.3.7" resolved "https://registry.yarnpkg.com/codesandbox-import-util-types/-/codesandbox-import-util-types-1.3.7.tgz#7a6097e248a75424d13b06b74368cd76bd2b3e10" @@ -4488,31 +4480,28 @@ next-tick@^1.1.0: resolved "https://registry.yarnpkg.com/next-tick/-/next-tick-1.1.0.tgz#1836ee30ad56d67ef281b22bd199f709449b35eb" integrity sha512-CXdUiJembsNjuToQvxayPZF9Vqht7hewsvy2sOWafLvi2awflj9mOC6bHIg50orX8IJvWKY9wYQ/zB2kogPslQ== -next@12.3.2-canary.7: - version "12.3.2-canary.7" - resolved "https://registry.yarnpkg.com/next/-/next-12.3.2-canary.7.tgz#c739348174a3d7d97a638aa409376a96577a31d8" - integrity sha512-zUosveWzpeRVy7j4ANoJ4gu0TBrkLYwPlIUEXrqqs/zLpHMu+tanxA1R1ts2d7h/2dSmeVZgGcHiVcHj5uspEA== +next@^13.4.1: + version "13.4.1" + resolved "https://registry.yarnpkg.com/next/-/next-13.4.1.tgz#8d23f94c81b3f9cc8b34165ad528457e5befd726" + integrity sha512-JBw2kAIyhKDpjhEWvNVoFeIzNp9xNxg8wrthDOtMctfn3EpqGCmW0FSviNyGgOSOSn6zDaX48pmvbdf6X2W9xA== dependencies: - "@next/env" "12.3.2-canary.7" - "@swc/helpers" "0.4.11" + "@next/env" "13.4.1" + "@swc/helpers" "0.5.1" + busboy "1.6.0" caniuse-lite "^1.0.30001406" postcss "8.4.14" - styled-jsx "5.0.7" - use-sync-external-store "1.2.0" + styled-jsx "5.1.1" + zod "3.21.4" optionalDependencies: - "@next/swc-android-arm-eabi" "12.3.2-canary.7" - "@next/swc-android-arm64" "12.3.2-canary.7" - "@next/swc-darwin-arm64" "12.3.2-canary.7" - "@next/swc-darwin-x64" "12.3.2-canary.7" - "@next/swc-freebsd-x64" "12.3.2-canary.7" - "@next/swc-linux-arm-gnueabihf" "12.3.2-canary.7" - "@next/swc-linux-arm64-gnu" "12.3.2-canary.7" - "@next/swc-linux-arm64-musl" "12.3.2-canary.7" - "@next/swc-linux-x64-gnu" "12.3.2-canary.7" - "@next/swc-linux-x64-musl" "12.3.2-canary.7" - "@next/swc-win32-arm64-msvc" "12.3.2-canary.7" - "@next/swc-win32-ia32-msvc" "12.3.2-canary.7" - "@next/swc-win32-x64-msvc" "12.3.2-canary.7" + "@next/swc-darwin-arm64" "13.4.1" + "@next/swc-darwin-x64" "13.4.1" + "@next/swc-linux-arm64-gnu" "13.4.1" + "@next/swc-linux-arm64-musl" "13.4.1" + "@next/swc-linux-x64-gnu" "13.4.1" + "@next/swc-linux-x64-musl" "13.4.1" + "@next/swc-win32-arm64-msvc" "13.4.1" + "@next/swc-win32-ia32-msvc" "13.4.1" + "@next/swc-win32-x64-msvc" "13.4.1" nice-try@^1.0.4: version "1.0.5" @@ -5357,13 +5346,13 @@ react-devtools-inline@4.4.0: dependencies: es6-symbol "^3" -react-dom@0.0.0-experimental-cb5084d1c-20220924: - version "0.0.0-experimental-cb5084d1c-20220924" - resolved "https://registry.yarnpkg.com/react-dom/-/react-dom-0.0.0-experimental-cb5084d1c-20220924.tgz#7a8334c5cf4baeb5651ca76fc9eb92ebbaf223bf" - integrity sha512-0IHzPGHESn3uu8nI1w5596GX8bCGCE94DpaHkKSGWOlB6uhoVecU0fyOCkkNuB4cMc9WeOWiH2gsM100EWZDPQ== +react-dom@^0.0.0-experimental-16d053d59-20230506: + version "0.0.0-experimental-16d053d59-20230506" + resolved "https://registry.yarnpkg.com/react-dom/-/react-dom-0.0.0-experimental-16d053d59-20230506.tgz#1870c355f1027262992b2226191810ba15eedab3" + integrity sha512-I4PIT9ZAdDgpbav9BxfzPv2p5otJz6BEbFEBvFwd1BnQJmtkKKApUU7RYdGKnwY2/r6hdfxPm2pne+NhiyBkzg== dependencies: loose-envify "^1.1.0" - scheduler "0.0.0-experimental-cb5084d1c-20220924" + scheduler "0.0.0-experimental-16d053d59-20230506" react-is@^16.13.1: version "16.13.1" @@ -5375,10 +5364,10 @@ react-is@^17.0.2: resolved "https://registry.yarnpkg.com/react-is/-/react-is-17.0.2.tgz#e691d4a8e9c789365655539ab372762b0efb54f0" integrity sha512-w2GsyukL62IJnlaff/nRegPQR94C/XXamvMWmSHRJ4y7Ts/4ocGRmTHvOs8PSE6pB3dWOrD/nueuU5sduBsQ4w== -react@0.0.0-experimental-cb5084d1c-20220924: - version "0.0.0-experimental-cb5084d1c-20220924" - resolved "https://registry.yarnpkg.com/react/-/react-0.0.0-experimental-cb5084d1c-20220924.tgz#ab661af674be824ae2989467506443b8bc4318d3" - integrity sha512-66AdfxkJrwCaCEKT0LQRd9J9GQ9T+yN7Wx9XT+tNxKycYQ0Exm+DZxOTedagWDlsFMXroyhrTWzgdC18R2PaOQ== +react@^0.0.0-experimental-16d053d59-20230506: + version "0.0.0-experimental-16d053d59-20230506" + resolved "https://registry.yarnpkg.com/react/-/react-0.0.0-experimental-16d053d59-20230506.tgz#98a7a9d19ab1820f882111ce4fc4e23f3cb8aaad" + integrity sha512-8PdloFcanNcryJLohpr4rVQfB4oJvsL0Z+TzJ8B66RxauwF95QqUNorGsK1heESrtj4As0oHCmiZkoYzA4uW8w== dependencies: loose-envify "^1.1.0" @@ -5709,10 +5698,10 @@ safe-buffer@~5.1.1: resolved "https://registry.yarnpkg.com/safer-buffer/-/safer-buffer-2.1.2.tgz#44fa161b0187b9549dd84bb91802f9bd8385cd6a" integrity sha512-YZo3K82SD7Riyi0E1EQPojLz7kpepnSQI9IyPbHHg1XXXevb5dJI7tpyN2ADxGcQbHG7vcyRHk0cbwqcQriUtg== -scheduler@0.0.0-experimental-cb5084d1c-20220924: - version "0.0.0-experimental-cb5084d1c-20220924" - resolved "https://registry.yarnpkg.com/scheduler/-/scheduler-0.0.0-experimental-cb5084d1c-20220924.tgz#9986680e1fbf7e4ccfe7606fef5920939d3a1abe" - integrity sha512-SeszKCdhM5OHxNMStjpKIAaloARUMZqIpDZjkZeGuRsyr7YlAqvlsCXyee4ZQOOU1pbr7BIvQntKy5Hil+DQJA== +scheduler@0.0.0-experimental-16d053d59-20230506: + version "0.0.0-experimental-16d053d59-20230506" + resolved "https://registry.yarnpkg.com/scheduler/-/scheduler-0.0.0-experimental-16d053d59-20230506.tgz#cb76957af2849452a5e40c82fb53168da255e32f" + integrity sha512-gGnyU4CkC/+msd1dOQW9zuquI3GoEziuS42soP0AvbTCvRkeU4qhR/mRRaU+/a7JK/OFeSSudcz7enkrkZdSPA== dependencies: loose-envify "^1.1.0" @@ -5941,6 +5930,11 @@ statuses@2.0.1: resolved "https://registry.yarnpkg.com/statuses/-/statuses-2.0.1.tgz#55cb000ccf1d48728bd23c685a063998cf1a1b63" integrity sha512-RwNA9Z/7PrK06rYLIzFMlaF+l73iwpzsqRIFgbMLbTcLD6cOao82TaWefPXQvB2fOC4AjuYSEndS7N/mTCbkdQ== +streamsearch@^1.1.0: + version "1.1.0" + resolved "https://registry.yarnpkg.com/streamsearch/-/streamsearch-1.1.0.tgz#404dd1e2247ca94af554e841a8ef0eaa238da764" + integrity sha512-Mcc5wHehp9aXz1ax6bZUyY5afg9u2rv5cqQI3mRrYkGC8rW2hM02jWuwjtL++LS5qinSyhj2QfLyNsuc+VsExg== + string-argv@^0.3.1: version "0.3.1" resolved "https://registry.yarnpkg.com/string-argv/-/string-argv-0.3.1.tgz#95e2fbec0427ae19184935f816d74aaa4c5c19da" @@ -6066,10 +6060,12 @@ style-to-object@^0.3.0: dependencies: inline-style-parser "0.1.1" -styled-jsx@5.0.7: - version "5.0.7" - resolved "https://registry.yarnpkg.com/styled-jsx/-/styled-jsx-5.0.7.tgz#be44afc53771b983769ac654d355ca8d019dff48" - integrity sha512-b3sUzamS086YLRuvnaDigdAewz1/EFYlHpYBP5mZovKEdQQOIIYq8lApylub3HHZ6xFjV051kkGU7cudJmrXEA== +styled-jsx@5.1.1: + version "5.1.1" + resolved "https://registry.yarnpkg.com/styled-jsx/-/styled-jsx-5.1.1.tgz#839a1c3aaacc4e735fed0781b8619ea5d0009d1f" + integrity sha512-pW7uC1l4mBZ8ugbiZrcIsiIvVx1UmTfw7UkC3Um2tmfUq9Bhk8IiyEIPl6F8agHgjzku6j0xQEZbfA5uSgSaCw== + dependencies: + client-only "0.0.1" supports-color@^5.3.0: version "5.5.0" @@ -6494,11 +6490,6 @@ uri-js@^4.2.2: dependencies: punycode "^2.1.0" -use-sync-external-store@1.2.0: - version "1.2.0" - resolved "https://registry.yarnpkg.com/use-sync-external-store/-/use-sync-external-store-1.2.0.tgz#7dbefd6ef3fe4e767a0cf5d7287aacfb5846928a" - integrity sha512-eEgnFxGQ1Ife9bzYs6VLi8/4X6CObHMw9Qr9tPY43iKwsPw8xE8+EFsf/2cFZ5S3esXgpWgtSCtLNS41F+sKPA== - util-deprecate@^1.0.2: version "1.0.2" resolved "https://registry.yarnpkg.com/util-deprecate/-/util-deprecate-1.0.2.tgz#450d4dc9fa70de732762fbd2d4a28981419a0ccf" @@ -6684,6 +6675,11 @@ yaml@^1.10.0, yaml@^1.10.2: resolved "https://registry.yarnpkg.com/yaml/-/yaml-1.10.2.tgz#2301c5ffbf12b467de8da2333a459e29e7920e4b" integrity sha512-r3vXyErRCYJ7wg28yvBY5VSoAF8ZvlcW9/BwUzEtUsjvX/DKs24dIkuwjtuprwJJHsbyUbLApepYTR1BN4uHrg== +zod@3.21.4: + version "3.21.4" + resolved "https://registry.yarnpkg.com/zod/-/zod-3.21.4.tgz#10882231d992519f0a10b5dd58a38c9dabbb64db" + integrity sha512-m46AKbrzKVzOzs/DZgVnG5H55N1sv1M8qZU3A8RIKbs3mrACDNeIOeilDymVb2HdmP8uwshOCF4uJ8uM9rCqJw== + zwitch@^2.0.0: version "2.0.2" resolved "https://registry.yarnpkg.com/zwitch/-/zwitch-2.0.2.tgz#91f8d0e901ffa3d66599756dde7f57b17c95dce1" From 398ace5b5e36535be19e89edd8c4a20db8a3e042 Mon Sep 17 00:00:00 2001 From: Viacheslav Makarov <9768704+mekarthedev@users.noreply.github.com> Date: Tue, 23 May 2023 16:01:09 +0200 Subject: [PATCH 18/83] Add missing 'it' (#6061) --- src/content/reference/react/useEffect.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/reference/react/useEffect.md b/src/content/reference/react/useEffect.md index dd84fd2ea..8d04f205c 100644 --- a/src/content/reference/react/useEffect.md +++ b/src/content/reference/react/useEffect.md @@ -1089,7 +1089,7 @@ function ChatRoom({ roomId }) { } ``` -**To remove a dependency, you need to ["prove" to the linter *doesn't need* to be a dependency.](/learn/removing-effect-dependencies#removing-unnecessary-dependencies)** For example, you can move `serverUrl` out of your component to prove that it's not reactive and won't change on re-renders: +**To remove a dependency, you need to ["prove" to the linter that it *doesn't need* to be a dependency.](/learn/removing-effect-dependencies#removing-unnecessary-dependencies)** For example, you can move `serverUrl` out of your component to prove that it's not reactive and won't change on re-renders: ```js {1,8} const serverUrl = 'https://localhost:1234'; // Not a reactive value anymore From 09185bcea9c7880763a458e9a68e67e454109791 Mon Sep 17 00:00:00 2001 From: Soichiro Miki Date: Tue, 23 May 2023 23:16:39 +0900 Subject: [PATCH 19/83] Fix a wrong explanation in "Manipulating the DOM with Refs" (#6055) * Fix manipulating-the-dom-with-refs * Update manipulating-the-dom-with-refs.md --------- Co-authored-by: dan --- src/content/learn/manipulating-the-dom-with-refs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/learn/manipulating-the-dom-with-refs.md b/src/content/learn/manipulating-the-dom-with-refs.md index b5c193763..3e91a7694 100644 --- a/src/content/learn/manipulating-the-dom-with-refs.md +++ b/src/content/learn/manipulating-the-dom-with-refs.md @@ -31,7 +31,7 @@ Then, use it to declare a ref inside your component: const myRef = useRef(null); ``` -Finally, pass it to the DOM node as the `ref` attribute: +Finally, pass your ref as the `ref` attribute to the JSX tag for which you want to get the DOM node: ```js
From 3364c93feb358a7d1ac2e8d8b0468c3e32214062 Mon Sep 17 00:00:00 2001 From: Tunzeki Date: Wed, 24 May 2023 00:04:02 +0100 Subject: [PATCH 20/83] Fix typo: change "intermedinate" to "indeterminate" (#6062) --- src/content/reference/react-dom/components/progress.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/reference/react-dom/components/progress.md b/src/content/reference/react-dom/components/progress.md index fd6c96a1e..b783a102d 100644 --- a/src/content/reference/react-dom/components/progress.md +++ b/src/content/reference/react-dom/components/progress.md @@ -35,7 +35,7 @@ To display a progress indicator, render the [built-in browser ``](http Additionally, `` supports these props: * [`max`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/progress#attr-max): A number. Specifies the maximum `value`. Defaults to `1`. -* [`value`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/progress#attr-value): A number between `0` and `max`, or `null` for intermedinate progress. Specifies how much was done. +* [`value`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/progress#attr-value): A number between `0` and `max`, or `null` for indeterminate progress. Specifies how much was done. --- From ad4f5c7c9555f65d6b889e85427ba3fdfa4e7159 Mon Sep 17 00:00:00 2001 From: Serhii Palamarchuk Date: Tue, 30 May 2023 19:57:57 +0300 Subject: [PATCH 21/83] Update NextJs link (#6053) --- .../reference/react-dom/server/renderToPipeableStream.md | 2 +- .../reference/react-dom/server/renderToReadableStream.md | 2 +- src/content/reference/react/Suspense.md | 2 +- src/content/reference/react/useDeferredValue.md | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/src/content/reference/react-dom/server/renderToPipeableStream.md b/src/content/reference/react-dom/server/renderToPipeableStream.md index dee690372..6a9021e02 100644 --- a/src/content/reference/react-dom/server/renderToPipeableStream.md +++ b/src/content/reference/react-dom/server/renderToPipeableStream.md @@ -286,7 +286,7 @@ Streaming does not need to wait for React itself to load in the browser, or for **Only Suspense-enabled data sources will activate the Suspense component.** They include: -- Data fetching with Suspense-enabled frameworks like [Relay](https://relay.dev/docs/guided-tour/rendering/loading-states/) and [Next.js](https://nextjs.org/docs/advanced-features/react-18) +- Data fetching with Suspense-enabled frameworks like [Relay](https://relay.dev/docs/guided-tour/rendering/loading-states/) and [Next.js](https://nextjs.org/docs/getting-started/react-essentials) - Lazy-loading component code with [`lazy`](/reference/react/lazy) Suspense **does not** detect when data is fetched inside an Effect or event handler. diff --git a/src/content/reference/react-dom/server/renderToReadableStream.md b/src/content/reference/react-dom/server/renderToReadableStream.md index d6d5b3264..8ef42aa71 100644 --- a/src/content/reference/react-dom/server/renderToReadableStream.md +++ b/src/content/reference/react-dom/server/renderToReadableStream.md @@ -285,7 +285,7 @@ Streaming does not need to wait for React itself to load in the browser, or for **Only Suspense-enabled data sources will activate the Suspense component.** They include: -- Data fetching with Suspense-enabled frameworks like [Relay](https://relay.dev/docs/guided-tour/rendering/loading-states/) and [Next.js](https://nextjs.org/docs/advanced-features/react-18) +- Data fetching with Suspense-enabled frameworks like [Relay](https://relay.dev/docs/guided-tour/rendering/loading-states/) and [Next.js](https://nextjs.org/docs/getting-started/react-essentials) - Lazy-loading component code with [`lazy`](/reference/react/lazy) Suspense **does not** detect when data is fetched inside an Effect or event handler. diff --git a/src/content/reference/react/Suspense.md b/src/content/reference/react/Suspense.md index f24c98c7d..27add6035 100644 --- a/src/content/reference/react/Suspense.md +++ b/src/content/reference/react/Suspense.md @@ -252,7 +252,7 @@ async function getAlbums() { **Only Suspense-enabled data sources will activate the Suspense component.** They include: -- Data fetching with Suspense-enabled frameworks like [Relay](https://relay.dev/docs/guided-tour/rendering/loading-states/) and [Next.js](https://nextjs.org/docs/advanced-features/react-18) +- Data fetching with Suspense-enabled frameworks like [Relay](https://relay.dev/docs/guided-tour/rendering/loading-states/) and [Next.js](https://nextjs.org/docs/getting-started/react-essentials) - Lazy-loading component code with [`lazy`](/reference/react/lazy) Suspense **does not** detect when data is fetched inside an Effect or event handler. diff --git a/src/content/reference/react/useDeferredValue.md b/src/content/reference/react/useDeferredValue.md index 3f2a8a5d9..f25054542 100644 --- a/src/content/reference/react/useDeferredValue.md +++ b/src/content/reference/react/useDeferredValue.md @@ -84,7 +84,7 @@ During updates, the deferred value will "lag behin This example assumes you use one of Suspense-enabled data sources: -- Data fetching with Suspense-enabled frameworks like [Relay](https://relay.dev/docs/guided-tour/rendering/loading-states/) and [Next.js](https://nextjs.org/docs/advanced-features/react-18) +- Data fetching with Suspense-enabled frameworks like [Relay](https://relay.dev/docs/guided-tour/rendering/loading-states/) and [Next.js](https://nextjs.org/docs/getting-started/react-essentials) - Lazy-loading component code with [`lazy`](/reference/react/lazy) [Learn more about Suspense and its limitations.](/reference/react/Suspense) From 4184c0f5608ef80d6cec4e1c42dfa9c6f3c9ad92 Mon Sep 17 00:00:00 2001 From: J <124119483+escwxyz@users.noreply.github.com> Date: Wed, 31 May 2023 16:15:21 +0200 Subject: [PATCH 22/83] Fix a missing word in useLayoutEffect (#6078) --- src/content/reference/react/useLayoutEffect.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/reference/react/useLayoutEffect.md b/src/content/reference/react/useLayoutEffect.md index d30ebbd16..5af3ec5a6 100644 --- a/src/content/reference/react/useLayoutEffect.md +++ b/src/content/reference/react/useLayoutEffect.md @@ -26,7 +26,7 @@ useLayoutEffect(setup, dependencies?) ### `useLayoutEffect(setup, dependencies?)` {/*useinsertioneffect*/} -Call `useLayoutEffect` perform the layout measurements before the browser repaints the screen: +Call `useLayoutEffect` to perform the layout measurements before the browser repaints the screen: ```js import { useState, useRef, useLayoutEffect } from 'react'; From ca93140eb98a7ff4364a719075fccea980c55b55 Mon Sep 17 00:00:00 2001 From: Ahmed Abdelbaset Date: Fri, 2 Jun 2023 14:42:16 +0300 Subject: [PATCH 23/83] Fix option's mdn link (#6080) --- src/content/reference/react-dom/components/option.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/reference/react-dom/components/option.md b/src/content/reference/react-dom/components/option.md index 8d930523f..84725854c 100644 --- a/src/content/reference/react-dom/components/option.md +++ b/src/content/reference/react-dom/components/option.md @@ -23,7 +23,7 @@ The [built-in browser `
-
+
{message}
From 03c2e965c3bbe6046d571c1f566e38cf06917cc5 Mon Sep 17 00:00:00 2001 From: Ricky Date: Wed, 9 Aug 2023 22:46:03 -0400 Subject: [PATCH 43/83] Fix recipe titles (#6209) --- src/content/reference/react/forwardRef.md | 2 +- src/content/reference/react/useContext.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/content/reference/react/forwardRef.md b/src/content/reference/react/forwardRef.md index 739c94ae2..10c2ad03d 100644 --- a/src/content/reference/react/forwardRef.md +++ b/src/content/reference/react/forwardRef.md @@ -135,7 +135,7 @@ This `Form` component [passes a ref](/reference/react/useRef#manipulating-the-do Keep in mind that exposing a ref to the DOM node inside your component makes it harder to change your component's internals later. You will typically expose DOM nodes from reusable low-level components like buttons or text inputs, but you won't do it for application-level components like an avatar or a comment. - + #### Focusing a text input {/*focusing-a-text-input*/} diff --git a/src/content/reference/react/useContext.md b/src/content/reference/react/useContext.md index 2b8f0605c..ed231c394 100644 --- a/src/content/reference/react/useContext.md +++ b/src/content/reference/react/useContext.md @@ -1078,7 +1078,7 @@ You can override the context for a part of the tree by wrapping that part in a p You can nest and override providers as many times as you need. - + #### Overriding a theme {/*overriding-a-theme*/} From fcc639b062fca15574ec0f09dc37ba5bc63fac53 Mon Sep 17 00:00:00 2001 From: Natsuo Kawai Date: Fri, 11 Aug 2023 05:49:36 +0900 Subject: [PATCH 44/83] Fix IDs specified in the MDN page URLs (#6176) --- .../react-dom/components/progress.md | 4 ++-- .../reference/react-dom/components/select.md | 16 ++++++------- .../react-dom/components/textarea.md | 24 +++++++++---------- 3 files changed, 22 insertions(+), 22 deletions(-) diff --git a/src/content/reference/react-dom/components/progress.md b/src/content/reference/react-dom/components/progress.md index b783a102d..9a8d60ab0 100644 --- a/src/content/reference/react-dom/components/progress.md +++ b/src/content/reference/react-dom/components/progress.md @@ -34,8 +34,8 @@ To display a progress indicator, render the [built-in browser ``](http Additionally, `` supports these props: -* [`max`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/progress#attr-max): A number. Specifies the maximum `value`. Defaults to `1`. -* [`value`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/progress#attr-value): A number between `0` and `max`, or `null` for indeterminate progress. Specifies how much was done. +* [`max`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/progress#max): A number. Specifies the maximum `value`. Defaults to `1`. +* [`value`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/progress#value): A number between `0` and `max`, or `null` for indeterminate progress. Specifies how much was done. --- diff --git a/src/content/reference/react-dom/components/select.md b/src/content/reference/react-dom/components/select.md index 93ff56ac5..46710908c 100644 --- a/src/content/reference/react-dom/components/select.md +++ b/src/content/reference/react-dom/components/select.md @@ -50,21 +50,21 @@ If your `` props are relevant both for uncontrolled and controlled select boxes: -* [`autoComplete`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/select#attr-autocomplete): A string. Specifies one of the possible [autocomplete behaviors.](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/autocomplete#values) -* [`autoFocus`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/select#attr-autofocus): A boolean. If `true`, React will focus the element on mount. +* [`autoComplete`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/select#autocomplete): A string. Specifies one of the possible [autocomplete behaviors.](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/autocomplete#values) +* [`autoFocus`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/select#autofocus): A boolean. If `true`, React will focus the element on mount. * `children`: `