`, React Native `
`) are *hidden by default*, but this filter can be disabled:
-## How do I get the old version back?
+## How do I get the old version back? {#how-do-i-get-the-old-version-back}
If you are working with React Native version 60 (or older) you can install the previous release of DevTools from NPM:
@@ -70,7 +70,7 @@ yarn build:extension
# Follow the on-screen instructions to complete installation
```
-## Thank you!
+## Thank you! {#thank-you}
We'd like to thank everyone who tested the early release of DevTools version 4.
Your feedback helped improve this initial release significantly.
diff --git a/content/blog/2019-10-22-react-release-channels.md b/content/blog/2019-10-22-react-release-channels.md
new file mode 100644
index 000000000..f841c5abe
--- /dev/null
+++ b/content/blog/2019-10-22-react-release-channels.md
@@ -0,0 +1,102 @@
+---
+title: "Preparing for the Future with React Prereleases"
+author: [acdlite]
+---
+
+To share upcoming changes with our partners in the React ecosystem, we're establishing official prerelease channels. We hope this process will help us make changes to React with confidence, and give developers the opportunity to try out experimental features.
+
+> This post will be most relevant to developers who work on frameworks, libraries, or developer tooling. Developers who use React primarily to build user-facing applications should not need to worry about our prerelease channels.
+
+React relies on a thriving open source community to file bug reports, open pull requests, and [submit RFCs](https://github.com/reactjs/rfcs). To encourage feedback, we sometimes share special builds of React that include unreleased features.
+
+Because the source of truth for React is our [public GitHub repository](https://github.com/facebook/react), it's always been possible to build a copy of React that includes the latest changes. However it's much easier for developers to install React from npm, so we occasionally publish prerelease builds to the npm registry. A recent example is the 16.7 alpha, which included an early version of the Hooks API.
+
+We would like to make it even easier for developers to test prerelease builds of React, so we're formalizing our process with three separate release channels.
+
+## Release Channels
+
+> The information in this post is also available on our [Release Channels](/docs/release-channels.html) page. We will update that document whenever there are changes to our release process.
+
+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 master 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 master 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](/docs/faq-versioning.html). Prereleases (those in the Next and Experimental channels) have versions generated from a hash of their contents, e.g. `0.0.0-1022ee0ec` for Next and `0.0.0-experimental-1022ee0ec` 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.
+
+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).
+
+### Latest Channel
+
+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. Learn more about our commitment to stability and incremental migration in our [versioning policy](/docs/faq-versioning.html).
+
+### Next Channel
+
+The Next channel is a prerelease channel that tracks the master 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 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.
+
+**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, e.g. `0.0.0-1022ee0ec`.
+
+#### Using the Next Channel for Integration Testing
+
+The Next 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:
+
+ ```
+ npm update react@next react-dom@next
+ ```
+
+ Or yarn:
+
+ ```
+ yarn upgrade react@next react-dom@next
+ ```
+- 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.
+
+### Experimental Channel
+
+Like Next, the Experimental channel is a prerelease channel that tracks the master branch of the React repository. Unlike Next, 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.
+
+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.
+
+Releases in Experimental are published with the `experimental` tag on npm. Versions are generated from a hash of the build's contents, e.g. `0.0.0-experimental-1022ee0ec`.
+
+#### What Goes Into an Experimental Release?
+
+Experimental features are ones that are not ready to be released to the wider public, and may change drastically before they are finalized. Some experiments may never be finalized -- the reason we have experiments is to test the viability of proposed changes.
+
+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.**
+
+#### 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 Stable.
+
+If a feature is not documented, they may be accompanied by an [RFC](https://github.com/reactjs/rfcs).
+
+We will post to the React blog when we're ready to announce new experiments, but that doesn't mean we will publicize every experiment.
+
+You can always refer to our public GitHub repository's [history](https://github.com/facebook/react/commits/master) for a comprehensive list of changes.
diff --git a/content/community/conferences.md b/content/community/conferences.md
index 77ccf89d2..a067a93d9 100644
--- a/content/community/conferences.md
+++ b/content/community/conferences.md
@@ -17,21 +17,6 @@ November 30, 2019 in Lagos, Nigeria
[Website](https://reactsummit2019.splashthat.com) -[Twitter](https://twitter.com/react_summit)
-### React Conf 2019 {#react-conf-2019}
-October 24-25, 2019 in Henderson, Nevada USA
-
-[Website](https://conf.reactjs.org/) - [Twitter](https://twitter.com/reactjs)
-
-### React Advanced 2019 {#react-advanced-2019}
-October 25, 2019 in London, UK
-
-[Website](https://reactadvanced.com) - [Twitter](http://twitter.com/reactadvanced) - [Facebook](https://www.facebook.com/ReactAdvanced) - [Videos](https://youtube.com/c/ReactConferences)
-
-### React Conf Brasil 2019 {#react-conf-2019}
-October 19, 2019 in São Paulo, BR
-
-[Website](https://reactconf.com.br/) - [Twitter](https://twitter.com/reactconfbr) - [Facebook](https://www.facebook.com/ReactAdvanced) - [Slack](https://react.now.sh/)
-
### React Day Berlin 2019 {#react-day-berlin-2019}
December 6, 2019 in Berlin, Germany
@@ -47,7 +32,12 @@ April 15-17, 2020 in Amsterdam, The Netherlands
[Website](https://reactsummit.com) - [Twitter](https://twitter.com/reactamsterdam) - [Facebook](https://www.facebook.com/reactamsterdam) - [Videos](https://youtube.com/c/ReactConferences)
-### Render-Atlanta 2020 {#render-atlanta-2020}
+### App.js Conf 2020 {#appjsonf2020}
+April 23 - 24, 2020 in Kraków, Poland
+
+[Website](http://appjs.co/react) - [Twitter](https://twitter.com/appjsconf)
+
+### render(ATL) 2020 {#render-atlanta-2020}
May 4-6, 2020. Atlanta, GA, USA.
[Website](https://renderatl.com) - [Twitter](https://twitter.com/renderATL) - [Instagram](https://www.instagram.com/renderatl/) - [Facebook](https://www.facebook.com/renderatl/)
@@ -67,7 +57,7 @@ June 15, 2020. Tel Aviv, Israel.
[Website](https://react-next.com/) - [Twitter](https://twitter.com/reactnext) - [Facebook](https://www.facebook.com/ReactNext2016/)
-### React Week NY 2020 {#react-week-NY-2020}
+### React Week NY 2020 {#react-week-ny-2020}
July 17, 2020. New York City, USA.
[Website](https://reactweek.nyc/) - [Twitter](https://twitter.com/reactweek) - [Facebook](https://www.facebook.com/reactweek)
@@ -452,3 +442,18 @@ September 26-28, 2019 in Alicante, Spain
[Website](http://reactalicante.es/) - [Twitter](https://twitter.com/reactalicante) - [Facebook](https://www.facebook.com/ReactAlicante)
+### React Conf 2019 {#react-conf-2019}
+October 24-25, 2019 in Henderson, Nevada USA
+
+[Website](https://conf.reactjs.org/) - [Twitter](https://twitter.com/reactjs)
+
+### React Advanced 2019 {#react-advanced-2019}
+October 25, 2019 in London, UK
+
+[Website](https://reactadvanced.com) - [Twitter](http://twitter.com/reactadvanced) - [Facebook](https://www.facebook.com/ReactAdvanced) - [Videos](https://youtube.com/c/ReactConferences)
+
+### React Conf Brasil 2019 {#react-conf-2019}
+October 19, 2019 in São Paulo, BR
+
+[Website](https://reactconf.com.br/) - [Twitter](https://twitter.com/reactconfbr) - [Facebook](https://www.facebook.com/ReactAdvanced) - [Slack](https://react.now.sh/)
+
diff --git a/content/community/examples.md b/content/community/examples.md
index 55541310b..d330ef0bf 100644
--- a/content/community/examples.md
+++ b/content/community/examples.md
@@ -25,3 +25,5 @@ There are many example projects created by the React community. Feel free to add
* **[Speedy math](https://github.com/pankajladhar/speedy-math)** An application which allows kids to practice basic Mathematics i.e Addition, Subtraction, Multiply, Comparison. It is a PWA (Progressive web app) with offline support and install as App features.
* **[Unit Converter](https://github.com/KarthikeyanRanasthala/react-unit-converter)** Minimal Yet Responsive Unit Converter Built With React, Material-UI & Convert-Units.
* **[BMI Calculator](https://github.com/GermaVinsmoke/bmi-calculator)** A React Hooks app for calculating BMI
+* **[ReactJS Hangman Game](https://github.com/vetrivelcsamy/reactjs-hangman)** ReactJS Hangman Game Find a Programming Language.
+* **[Radix Converter](https://github.com/kumom/radix-converter)** A small tool that converts numbers in radix 2 to 36 with arbitrary precision.
diff --git a/content/community/meetups.md b/content/community/meetups.md
index 78bcf1dd6..f12847f74 100644
--- a/content/community/meetups.md
+++ b/content/community/meetups.md
@@ -50,6 +50,7 @@ Do you have a local React.js meetup? Add it here! (Please keep the list alphabet
* [React.JS Girls London](https://www.meetup.com/ReactJS-Girls-London/)
## France {#france}
+* [Nantes](https://www.meetup.com/React-Nantes/)
* [Lille](https://www.meetup.com/ReactBeerLille/)
* [Paris](https://www.meetup.com/ReactJS-Paris/)
diff --git a/content/community/tools-starter-kits.md b/content/community/tools-starter-kits.md
index bfd3b89fc..47d64b841 100644
--- a/content/community/tools-starter-kits.md
+++ b/content/community/tools-starter-kits.md
@@ -36,4 +36,6 @@ Ready to grow boilerplate with react-router, redux, saga, webpack 3, jest w/ cov
* **[EDGE Platform](https://github.com/sebastian-software/edge)** Universal React/SSR + Apollo GraphQL + JS/CSS Code Splitting + Fine-Tuned Webpack + Localization/Internationalization. Most things are external dependencies. Boilerplate available.
* **[bae](https://github.com/siddharthkp/bae)** Zero config toolkit. SSR (with data fetching) + routing + streaming + styling (with styled-components) + HMR out of the box.
* **[breko-hub](https://github.com/tomatau/breko-hub)** A production ready boilerplate for universal react applications. Complete with code splitting, server render (using koa), redux, sagas, debugging, hot-reloading (live updates on the server), css-modules, scss, super fast integration tests and unit tests. There's also a big focus on clean code and smaller files.
- * **[appseed](https://github.com/rosoftdeveloper/appseed)** A production ready boilerplate for UI-Ready react applications. The frontend can be bundled with various backends: Flask, Laravel, Express.
+ * **[appseed](https://github.com/rosoftdeveloper/appseed)** A production ready boilerplate for UI-Ready react applications. The frontend can be bundled with various backends: Flask, Laravel, Express.
+ * **[Crisp React](https://github.com/winwiz1/crisp-react)** A boilerplate for React + Express integration in TypeScript. Written for performance and debugging convenience. Supports multiple SPAs. Production ready.
+
diff --git a/content/community/tools-ui-components.md b/content/community/tools-ui-components.md
index 7b0e59ce9..23644f8b5 100644
--- a/content/community/tools-ui-components.md
+++ b/content/community/tools-ui-components.md
@@ -71,6 +71,7 @@ permalink: community/ui-components.html
* **[valuelink](https://github.com/Volicon/valuelink):** Full-featured two-way data binding and forms validation with extended React links.
* **[video-react](https://github.com/video-react/video-react)**: A web video player built for the HTML5 world using React library.
* **[Winterfell](https://github.com/andrewhathaway/Winterfell):** Generate complex, validated and extendable JSON-based forms in React
+* **[wix-style-react](https://github.com/wix/wix-style-react):** Common React UI components for all Wix verticals developing in React
## Fee Based Components {#fee-based-components}
diff --git a/content/docs/code-splitting.md b/content/docs/code-splitting.md
index 8954d2e47..bec2d0a88 100644
--- a/content/docs/code-splitting.md
+++ b/content/docs/code-splitting.md
@@ -106,7 +106,7 @@ Create React App を使用している場合はすでに設定がされている
> 補足:
>
-> `React.lazy` と Suspense はまだサーバーサイドレンダリングには使用できません。サーバーサイドでレンダリングされたアプリでコード分割をしたい場合には、[Loadable Components](https://github.com/smooth-code/loadable-components) の使用をおすすめします。こちらは[サーバーサイドレンダリングでのバンドル分割のための素晴らしいガイド](https://github.com/smooth-code/loadable-components/blob/master/packages/server/README.md)も提供していくれているので、参考にしてみてください。
+> `React.lazy` と Suspense はまだサーバーサイドレンダリングには使用できません。サーバーサイドでレンダリングされたアプリでコード分割をしたい場合には、[Loadable Components](https://github.com/smooth-code/loadable-components) の使用をおすすめします。こちらは[サーバーサイドレンダリングでのバンドル分割のための素晴らしいガイド](https://www.smooth-code.com/open-source/loadable-components/docs/server-side-rendering/)も提供していくれているので、参考にしてみてください。
`React.lazy` 関数を使用すると、動的インポートを通常のコンポーネントとしてレンダリングすることができます。
diff --git a/content/docs/concurrent-mode-adoption.md b/content/docs/concurrent-mode-adoption.md
new file mode 100644
index 000000000..972635ca0
--- /dev/null
+++ b/content/docs/concurrent-mode-adoption.md
@@ -0,0 +1,130 @@
+---
+id: concurrent-mode-adoption
+title: Adopting Concurrent Mode (Experimental)
+permalink: docs/concurrent-mode-adoption.html
+prev: concurrent-mode-patterns.html
+next: concurrent-mode-reference.html
+---
+
+>Caution:
+>
+>This page describes **experimental features that are not yet available in a stable release**. Don't rely on experimental builds of React in production apps. These features may change significantly and without a warning before they become a part of React.
+>
+>This documentation is aimed at early adopters and people who are curious. If you're new to React, don't worry about these features -- you don't need to learn them right now.
+
+- [Installation](#installation)
+ - [Who Is This Experimental Release For?](#who-is-this-experimental-release-for)
+ - [Enabling Concurrent Mode](#enabling-concurrent-mode)
+- [What to Expect](#what-to-expect)
+ - [Migration Step: Blocking Mode](#migration-step-blocking-mode)
+ - [Why So Many Modes?](#why-so-many-modes)
+ - [Feature Comparison](#feature-comparison)
+
+## Installation {#installation}
+
+Concurrent Mode is only available in the [experimental builds](/blog/2019/10/22/react-release-channels.html#experimental-channel) of React. To install them, run:
+
+```
+npm install react@experimental react-dom@experimental
+```
+
+**There are no semantic versioning guarantees for the experimental builds.**
+APIs may be added, changed, or removed with any `@experimental` release.
+
+**Experimental releases will have frequent breaking changes.**
+
+You can try these builds on personal projects or in a branch, but we don't recommend running them in production. At Facebook, we *do* run them in production, but that's because we're also there to fix bugs when something breaks. You've been warned!
+
+### Who Is This Experimental Release For? {#who-is-this-experimental-release-for}
+
+This release is primarily aimed at early adopters, library authors, and curious people.
+
+We're using this code in production (and it works for us) but there are still some bugs, missing features, and gaps in the documentation. We'd like to hear more about what breaks in Concurrent Mode so we can better prepare it for an official stable release in the future.
+
+### Enabling Concurrent Mode {#enabling-concurrent-mode}
+
+Normally, when we add features to React, you can start using them immediately. Fragments, Context, and even Hooks are examples of such features. You can use in new code without making any changes to the existing code.
+
+Concurrent Mode is different. It introduces semantic changes to how React works. Otherwise, the [new features](/docs/concurrent-mode-patterns.html) enabled by it *wouldn't be possible*. This is why they're grouped into a new "mode" rather than released one by one in isolation.
+
+You can't opt into Concurrent Mode on a per-subtree basis. Instead, to opt in, you have to do it in the place where today you call `ReactDOM.render()`.
+
+**This will enable Concurrent Mode for the whole `
+
+| |Legacy Mode |Blocking Mode |Concurrent Mode |
+|--- |--- |--- |--- |
+|String Refs |✅ |🚫** |🚫** |
+|Legacy Context |✅ |🚫** |🚫** |
+|findDOMNode |✅ |🚫** |🚫** |
+|Suspense |✅ |✅ |✅ |
+|SuspenseList |🚫 |✅ |✅ |
+|Suspense SSR + Hydration |🚫 |✅ |✅ |
+|Progressive Hydration |🚫 |✅ |✅ |
+|Selective Hydration |🚫 |🚫 |✅ |
+|Cooperative Multitasking |🚫 |🚫 |✅ |
+|Automatic batching of multiple setStates |🚫* |✅ |✅ |
+|Priority-based Rendering |🚫 |🚫 |✅ |
+|Interruptible Prerendering |🚫 |🚫 |✅ |
+|useTransition |🚫 |🚫 |✅ |
+|useDeferredValue |🚫 |🚫 |✅ |
+|Suspense Reveal "Train" |🚫 |🚫 |✅ |
+
+
+
+\*: Legacy mode has automatic batching in React-managed events but it's limited to one browser task. Non-React events must opt-in using `unstable_batchedUpdates`. In Blocking Mode and Concurrent Mode, all `setState`s are batched by default.
+
+\*\*: Warns in development.
diff --git a/content/docs/concurrent-mode-intro.md b/content/docs/concurrent-mode-intro.md
new file mode 100644
index 000000000..dba52653b
--- /dev/null
+++ b/content/docs/concurrent-mode-intro.md
@@ -0,0 +1,89 @@
+---
+id: concurrent-mode-intro
+title: Introducing Concurrent Mode (Experimental)
+permalink: docs/concurrent-mode-intro.html
+next: concurrent-mode-suspense.html
+---
+
+>Caution:
+>
+>This page describes **experimental features that are [not yet available](/docs/concurrent-mode-adoption.html) in a stable release**. Don't rely on experimental builds of React in production apps. These features may change significantly and without a warning before they become a part of React.
+>
+>This documentation is aimed at early adopters and people who are curious. If you're new to React, don't worry about these features -- you don't need to learn them right now.
+
+This page provides a theoretical overview of Concurrent Mode. **For a more practical introduction, you might want to check out the next sections:**
+
+* [Suspense for Data Fetching](/docs/concurrent-mode-suspense.html) describes a new mechanism for fetching data in React components.
+* [Concurrent UI Patterns](/docs/concurrent-mode-patterns.html) shows some UI patterns made possible by Concurrent Mode and Suspense.
+* [Adopting Concurrent Mode](/docs/concurrent-mode-adoption.html) explains how you can try Concurrent Mode in your project.
+* [Concurrent Mode API Reference](/docs/concurrent-mode-reference.html) documents the new APIs available in experimental builds.
+
+## What Is Concurrent Mode? {#what-is-concurrent-mode}
+
+Concurrent Mode is a set of new features that help React apps stay responsive and gracefully adjust to the user's device capabilities and network speed.
+
+These features are still experimental and are subject to change. They are not yet a part of a stable React release, but you can try them in an experimental build.
+
+## Blocking vs Interruptible Rendering {#blocking-vs-interruptible-rendering}
+
+**To explain Concurrent Mode, we'll use version control as a metaphor.** If you work on a team, you probably use a version control system like Git and work on branches. When a branch is ready, you can merge your work into master so that other people can pull it.
+
+Before version control existed, the development workflow was very different. There was no concept of branches. If you wanted to edit some files, you had to tell everyone not to touch those files until you've finished your work. You couldn't even start working on them concurrently with that person — you were literally *blocked* by them.
+
+This illustrates how UI libraries, including React, typically work today. Once they start rendering an update, including creating new DOM nodes and running the code inside components, they can't interrupt this work. We'll call this approach "blocking rendering".
+
+In Concurrent Mode, rendering is not blocking. It is interruptible. This improves the user experience. It also unlocks new features that weren't possible before. Before we look at concrete examples in the [next](/docs/concurrent-mode-suspense.html) [chapters](/docs/concurrent-mode-patterns.html), we'll do a high-level overview of new features.
+
+### Interruptible Rendering {#interruptible-rendering}
+
+Consider a filterable product list. Have you ever typed into a list filter and felt that it stutters on every key press? Some of the work to update the product list might be unavoidable, such as creating new DOM nodes or the browser performing layout. However, *when* and *how* we perform that work plays a big role.
+
+A common way to work around the stutter is to "debounce" the input. When debouncing, we only update the list *after* the user stops typing. However, it can be frustrating that the UI doesn't update while we're typing. As an alternative, we could "throttle" the input, and update the list with a certain maximum frequency. But then on lower-powered devices we'd still end up with stutter. Both debouncing and throttling create a suboptimal user experience.
+
+The reason for the stutter is simple: once rendering begins, it can't be interrupted. So the browser can't update the text input right after the key press. No matter how good a UI library (such as React) might look on a benchmark, if it uses blocking rendering, a certain amount of work in your components will always cause stutter. And, often, there is no easy fix.
+
+**Concurrent Mode fixes this fundamental limitation by making rendering interruptible.** This means when the user presses another key, React doesn't need to block the browser from updating the text input. Instead, it can let the browser paint an update to the input, and then continue rendering the updated list *in memory*. When the rendering is finished, React updates the DOM, and changes are reflected on the screen.
+
+Conceptually, you can think of this as React preparing every update "on a branch". Just like you can abandon work in branches or switch between them, React in Concurrent Mode can interrupt an ongoing update to do something more important, and then come back to what it was doing earlier. This technique might also remind you of [double buffering](https://wiki.osdev.org/Double_Buffering) in video games.
+
+Concurrent Mode techniques reduce the need for debouncing and throttling in UI. Because rendering is interruptible, React doesn't need to artificially *delay* work to avoid stutter. It can start rendering right away, but interrupt this work when needed to keep the app responsive.
+
+### Intentional Loading Sequences {#intentional-loading-sequences}
+
+We've said before that Concurrent Mode is like React working "on a branch". Branches are useful not only for short-term fixes, but also for long-running features. Sometimes you might work on a feature, but it could take weeks before it's in a "good enough state" to merge into master. This side of our version control metaphor applies to rendering too.
+
+Imagine we're navigating between two screens in an app. Sometimes, we might not have enough code and data loaded to show a "good enough" loading state to the user on the new screen. Transitioning to an empty screen or a large spinner can be a jarring experience. However, it's also common that the necessary code and data doesn't take too long to fetch. **Wouldn't it be nicer if React could stay on the old screen for a little longer, and "skip" the "bad loading state" before showing the new screen?**
+
+While this is possible today, it can be difficult to orchestrate. In Concurrent Mode, this feature is built-in. React starts preparing the new screen in memory first — or, as our metaphor goes, "on a different branch". So React can wait before updating the DOM so that more content can load. In Concurrent Mode, we can tell React to keep showing the old screen, fully interactive, with an inline loading indicator. And when the new screen is ready, React can take us to it.
+
+### Concurrency {#concurrency}
+
+Let's recap the two examples above and see how Concurrent Mode unifies them. **In Concurrent Mode, React can work on several state updates *concurrently*** — just like branches let different team members work independently:
+
+* For CPU-bound updates (such as creating DOM nodes and running component code), concurrency means that a more urgent update can "interrupt" rendering that has already started.
+* For IO-bound updates (such as fetching code or data from the network), concurrency means that React can start rendering in memory even before all the data arrives, and skip showing jarring empty loading states.
+
+Importantly, the way you *use* React is the same. Concepts like components, props, and state fundamentally work the same way. When you want to update the screen, you set the state.
+
+React uses a heuristic to decide how "urgent" an update is, and lets you adjust it with a few lines of code so that you can achieve the desired user experience for every interaction.
+
+## Putting Research into Production {#putting-research-into-production}
+
+There is a common theme around Concurrent Mode features. **Its mission is to help integrate the findings from the Human-Computer Interaction research into real UIs.**
+
+For example, research shows that displaying too many intermediate loading states when transitioning between screens makes a transition feel *slower*. This is why Concurrent Mode shows new loading states on a fixed "schedule" to avoid jarring and too frequent updates.
+
+Similarly, we know from research that interactions like hover and text input need to be handled within a very short period of time, while clicks and page transitions can wait a little longer without feeling laggy. The different "priorities" that Concurrent Mode uses internally roughly correspond to the interaction categories in the human perception research.
+
+Teams with a strong focus on user experience sometimes solve similar problems with one-off solutions. However, those solutions rarely survive for a long time, as they're hard to maintain. With Concurrent Mode, our goal is to bake the UI research findings into the abstraction itself, and provide idiomatic ways to use them. As a UI library, React is well-positioned to do that.
+
+## Next Steps {#next-steps}
+
+Now you know what Concurrent Mode is all about!
+
+On the next pages, you'll learn more details about specific topics:
+
+* [Suspense for Data Fetching](/docs/concurrent-mode-suspense.html) describes a new mechanism for fetching data in React components.
+* [Concurrent UI Patterns](/docs/concurrent-mode-patterns.html) shows some UI patterns made possible by Concurrent Mode and Suspense.
+* [Adopting Concurrent Mode](/docs/concurrent-mode-adoption.html) explains how you can try Concurrent Mode in your project.
+* [Concurrent Mode API Reference](/docs/concurrent-mode-reference.html) documents the new APIs available in experimental builds.
diff --git a/content/docs/concurrent-mode-patterns.md b/content/docs/concurrent-mode-patterns.md
new file mode 100644
index 000000000..21b7b2bff
--- /dev/null
+++ b/content/docs/concurrent-mode-patterns.md
@@ -0,0 +1,926 @@
+---
+id: concurrent-mode-patterns
+title: Concurrent UI Patterns (Experimental)
+permalink: docs/concurrent-mode-patterns.html
+prev: concurrent-mode-suspense.html
+next: concurrent-mode-adoption.html
+---
+
+>Caution:
+>
+>This page describes **experimental features that are [not yet available](/docs/concurrent-mode-adoption.html) in a stable release**. Don't rely on experimental builds of React in production apps. These features may change significantly and without a warning before they become a part of React.
+>
+>This documentation is aimed at early adopters and people who are curious. If you're new to React, don't worry about these features -- you don't need to learn them right now.
+
+Usually, when we update the state, we expect to see changes on the screen immediately. This makes sense because we want to keep our app responsive to user input. However, there are cases where we might prefer to **defer an update from appearing on the screen**.
+
+For example, if we switch from one page to another, and none of the code or data for the next screen has loaded yet, it might be frustrating to immediately see a blank page with a loading indicator. We might prefer to stay longer on the previous screen. Implementing this pattern has historically been difficult in React. Concurrent Mode offers a new set of tools to do that.
+
+- [Transitions](#transitions)
+ - [Wrapping setState in a Transition](#wrapping-setstate-in-a-transition)
+ - [Adding a Pending Indicator](#adding-a-pending-indicator)
+ - [Reviewing the Changes](#reviewing-the-changes)
+ - [Where Does the Update Happen?](#where-does-the-update-happen)
+ - [Transitions Are Everywhere](#transitions-are-everywhere)
+ - [Baking Transitions Into the Design System](#baking-transitions-into-the-design-system)
+- [The Three Steps](#the-three-steps)
+ - [Default: Receded → Skeleton → Complete](#default-receded-skeleton-complete)
+ - [Preferred: Pending → Skeleton → Complete](#preferred-pending-skeleton-complete)
+ - [Wrap Lazy Features in ``](#wrap-lazy-features-in-suspense)
+ - [Suspense Reveal “Train”](#suspense-reveal-train)
+ - [Delaying a Pending Indicator](#delaying-a-pending-indicator)
+ - [Recap](#recap)
+- [Other Patterns](#other-patterns)
+ - [Splitting High and Low Priority State](#splitting-high-and-low-priority-state)
+ - [Deferring a Value](#deferring-a-value)
+ - [SuspenseList](#suspenselist)
+- [Next Steps](#next-steps)
+
+## Transitions {#transitions}
+
+Let's revisit [this demo](https://codesandbox.io/s/infallible-feather-xjtbu) from the previous page about [Suspense for Data Fetching](/docs/concurrent-mode-suspense.html).
+
+When we click the "Next" button to switch the active profile, the existing page data immediately disappears, and we see the loading indicator for the whole page again. We can call this an "undesirable" loading state. **It would be nice if we could "skip" it and wait for some content to load before transitioning to the new screen.**
+
+React offers a new built-in `useTransition()` Hook to help with this.
+
+We can use it in three steps.
+
+First, we'll make sure that we're actually using Concurrent Mode. We'll talk more about [adopting Concurrent Mode](/docs/concurrent-mode-adoption.html) later, but for now it's sufficient to know that we need to use `ReactDOM.createRoot()` rather than `ReactDOM.render()` for this feature to work:
+
+```js
+const rootElement = document.getElementById("root");
+// Opt into Concurrent Mode
+ReactDOM.createRoot(rootElement).render( {
+ const nextUserId = getNextId(resource.userId);
+ setResource(fetchProfileData(nextUserId));
+ }}
+>
+```
+
+ We'll wrap that state update into `startTransition`. That's how we tell React **we don't mind React delaying that state update** if it leads to an undesirable loading state:
+
+```js{3,6}
+ {
+ startTransition(() => {
+ const nextUserId = getNextId(resource.userId);
+ setResource(fetchProfileData(nextUserId));
+ });
+ }}
+>
+```
+
+**[Try it on CodeSandbox](https://codesandbox.io/s/musing-driscoll-6nkie)**
+
+Press "Next" a few times. Notice it already feels very different. **Instead of immediately seeing an empty screen on click, we now keep seeing the previous page for a while.** When the data has loaded, React transitions us to the new screen.
+
+If we make our API responses take 5 seconds, [we can confirm](https://codesandbox.io/s/relaxed-greider-suewh) that now React "gives up" and transitions anyway to the next screen after 3 seconds. This is because we passed `{timeoutMs: 3000}` to `useTransition()`. For example, if we passed `{timeoutMs: 60000}` instead, it would wait a whole minute.
+
+### Adding a Pending Indicator {#adding-a-pending-indicator}
+
+There's still something that feels broken about [our last example](https://codesandbox.io/s/musing-driscoll-6nkie). Sure, it's nice not to see a "bad" loading state. **But having no indication of progress at all feels even worse!** When we click "Next", nothing happens and it feels like the app is broken.
+
+Our `useTransition()` call returns two values: `startTransition` and `isPending`.
+
+```js
+ const [startTransition, isPending] = useTransition({ timeoutMs: 3000 });
+```
+
+We've already used `startTransition` to wrap the state update. Now we're going to use `isPending` too. React gives this boolean to us so we can tell whether **we're currently waiting for this transition to finish**. We'll use it to indicate that something is happening:
+
+```js{4,14}
+return (
+ <>
+ {
+ startTransition(() => {
+ const nextUserId = getNextId(resource.userId);
+ setResource(fetchProfileData(nextUserId));
+ });
+ }}
+ >
+ Next
+
+ {isPending ? " Loading..." : null}
+ {
+ startTransition(() => {
+ const nextUserId = getNextId(resource.userId);
+ setResource(fetchProfileData(nextUserId));
+ });
+ }}
+ >
+ Next
+
+ {isPending ? " Loading..." : null}
+ ` rendering?
+
+Clearly, both "versions" of `` exist at the same time. We know the old one exists because we see it on the screen and even display a progress indicator on it. And we know the new version also exists *somewhere*, because it's the one that we're waiting for!
+
+**But how can two versions of the same component exist at the same time?**
+
+This gets at the root of what Concurrent Mode is. We've [previously said](/docs/concurrent-mode-intro.html#intentional-loading-sequences) it's a bit like React working on state update on a "branch". Another way we can conceptualize is that wrapping a state update in `startTransition` begins rendering it *"in a different universe"*, much like in science fiction movies. We don't "see" that universe directly -- but we can get a signal from it that tells us something is happening (`isPending`). When the update is ready, our "universes" merge back together, and we see the result on the screen!
+
+Play a bit more with the [demo](https://codesandbox.io/s/jovial-lalande-26yep), and try to imagine it happening.
+
+Of course, two versions of the tree rendering *at the same time* is an illusion, just like the idea that all programs run on your computer at the same time is an illusion. An operating system switches between different applications very fast. Similarly, React can switch between the version of the tree you see on the screen and the version that it's "preparing" to show next.
+
+An API like `useTransition` lets you focus on the desired user experience, and not think about the mechanics of how it's implemented. Still, it can be a helpful metaphor to imagine that updates wrapped in `startTransition` happen "on a branch" or "in a different world".
+
+### Transitions Are Everywhere {#transitions-are-everywhere}
+
+As we learned from the [Suspense walkthrough](/docs/concurrent-mode-suspense.html), any component can "suspend" any time if some data it needs is not ready yet. We can strategically place `` boundaries in different parts of the tree to handle this, but it won't always be enough.
+
+Let's get back to our [first Suspense demo](https://codesandbox.io/s/frosty-hermann-bztrp) where there was just one profile. Currently, it fetches the data only once. We'll add a "Refresh" button to check for server updates.
+
+Our first attempt might look like this:
+
+```js{6-8,13-15}
+const initialResource = fetchUserAndPosts();
+
+function ProfilePage() {
+ const [resource, setResource] = useState(initialResource);
+
+ function handleRefreshClick() {
+ setResource(fetchUserAndPosts());
+ }
+
+ return (
+ Loading profile...}>
+
+ Refresh
+
+ Loading posts...}>
+
+
+ );
+}
+```
+
+**[Try it on CodeSandbox](https://codesandbox.io/s/boring-shadow-100tf)**
+
+In this example, we start data fetching at the load *and* every time you press "Refresh". We put the result of calling `fetchUserAndPosts()` into state so that components below can start reading the new data from the request we just kicked off.
+
+We can see in [this example](https://codesandbox.io/s/boring-shadow-100tf) that pressing "Refresh" works. The `` and `` components receive a new `resource` prop that represents the fresh data, they "suspend" because we don't have a response yet, and we see the fallbacks. When the response loads, we can see the updated posts (our fake API adds them every 3 seconds).
+
+However, the experience feels really jarring. We were browsing a page, but it got replaced by a loading state right as we were interacting with it. It's disorienting. **Just like before, to avoid showing an undesirable loading state, we can wrap the state update in a transition:**
+
+```js{2-5,9-11,21}
+function ProfilePage() {
+ const [startTransition, isPending] = useTransition({
+ // Wait 10 seconds before fallback
+ timeoutMs: 10000
+ });
+ const [resource, setResource] = useState(initialResource);
+
+ function handleRefreshClick() {
+ startTransition(() => {
+ setResource(fetchProfileData());
+ });
+ }
+
+ return (
+ Loading profile...}>
+
+ {isPending ? "Refreshing..." : "Refresh"}
+
+ Loading posts...}>
+
+
+ );
+}
+```
+
+**[Try it on CodeSandbox](https://codesandbox.io/s/sleepy-field-mohzb)**
+
+This feels a lot better! Clicking "Refresh" doesn't pull us away from the page we're browsing anymore. We see something is loading "inline", and when the data is ready, it's displayed.
+
+### Baking Transitions Into the Design System {#baking-transitions-into-the-design-system}
+
+We can now see that the need for `useTransition` is *very* common. Pretty much any button click or interaction that can lead to a component suspending needs to be wrapped in `useTransition` to avoid accidentally hiding something the user is interacting with.
+
+This can lead to a lot of repetitive code across components. This is why **we generally recommend to bake `useTransition` into the *design system* components of your app**. For example, we can extract the transition logic into our own `` component:
+
+```js{7-9,20,24}
+function Button({ children, onClick }) {
+ const [startTransition, isPending] = useTransition({
+ timeoutMs: 10000
+ });
+
+ function handleClick() {
+ startTransition(() => {
+ onClick();
+ });
+ }
+
+ const spinner = (
+ // ...
+ );
+
+ return (
+ <>
+
+ {children}
+
+ {isPending ? spinner : null}
+
+ );
+}
+```
+
+**[Try it on CodeSandbox](https://codesandbox.io/s/modest-ritchie-iufrh)**
+
+Note that the button doesn't care *what* state we're updating. It's wrapping *any* state updates that happen during its `onClick` handler into a transition. Now that our `` takes care of setting up the transition, the `` component doesn't need to set up its own:
+
+```js{4-6,11-13}
+function ProfilePage() {
+ const [resource, setResource] = useState(initialResource);
+
+ function handleRefreshClick() {
+ setResource(fetchProfileData());
+ }
+
+ return (
+ Loading profile...}>
+
+ Refresh
+
+ Loading posts...}>
+
+
+ );
+}
+```
+
+**[Try it on CodeSandbox](https://codesandbox.io/s/modest-ritchie-iufrh)**
+
+When a button gets clicked, it starts a transition and calls `props.onClick()` inside of it -- which triggers `handleRefreshClick` in the `` component. We start fetching the fresh data, but it doesn't trigger a fallback because we're inside a transition, and the 10 second timeout specified in the `useTransition` call hasn't passed yet. While a transition is pending, the button displays an inline loading indicator.
+
+We can see now how Concurrent Mode helps us achieve a good user experience without sacrificing isolation and modularity of components. React coordinates the transition.
+
+## The Three Steps {#the-three-steps}
+
+By now we have discussed all of the different visual states that an update may go through. In this section, we will give them names and talk about the progression between them.
+
+Loading the app... ` fallback.
+* **Skeleton:** You will see the `` component with `Loading posts... ` inside.
+* **Complete:** You will see the `` component with no fallbacks inside. Everything was fetched.
+
+How do we separate the Receded and the Skeleton states? The difference between them is that the **Receded** state feels like "taking a step back" to the user, while the **Skeleton** state feels like "taking a step forward" in our progress to show more content.
+
+In this example, we started our journey on the ``:
+
+```js
+
+ {/* previous screen */}
+
+```
+
+After the click, React started rendering the next screen:
+
+```js
+
+ {/* next screen */}
+
+
+
+
+
+```
+
+Both `` and `` need data to render, so they suspend:
+
+```js{4,6}
+
+ {/* next screen */}
+
+ Loading posts...}>
+
+
+
+```
+
+When a component suspends, React needs to show the closest fallback. But the closest fallback to `` is at the top level:
+
+```js{2,3,7}
+
+ Loading the app...
+}>
+ {/* next screen */}
+
+
+
+
+
+```
+
+This is why when we click the button, it feels like we've "taken a step back". The `` boundary which was previously showing useful content (`Loading the app... `). We call that a **Receded** state.
+
+As we load more data, React will retry rendering, and `` can render successfully. Finally, we're in the **Skeleton** state. We see the new page with missing parts:
+
+```js{6,7,9}
+
+ {/* next screen */}
+
+
+ Loading posts...
+ }>
+
+
+
+```
+
+Eventually, they load too, and we get to the **Complete** state.
+
+This scenario (Receded → Skeleton → Complete) is the default one. However, the Receded state is not very pleasant because it "hides" existing information. This is why React lets us opt into a different sequence (**Pending** → Skeleton → Complete) with `useTransition`.
+
+### Preferred: Pending → Skeleton → Complete {#preferred-pending-skeleton-complete}
+
+When we `useTransition`, React will let us "stay" on the previous screen -- and show a progress indicator there. We call that a **Pending** state. It feels much better than the Receded state because none of our existing content disappears, and the page stays interactive.
+
+You can compare these two examples to feel the difference:
+
+* Default: [Receded → Skeleton → Complete](https://codesandbox.io/s/prod-grass-g1lh5)
+* **Preferred: [Pending → Skeleton → Complete](https://codesandbox.io/s/focused-snow-xbkvl)**
+
+The only difference between these two examples is that the first uses regular ``s, but the second one uses our custom `` component with `useTransition`.
+
+### Wrap Lazy Features in `` {#wrap-lazy-features-in-suspense}
+
+Open [this example](https://codesandbox.io/s/nameless-butterfly-fkw5q). When you press a button, you'll see the Pending state for a second before moving on. This transition feels nice and fluid.
+
+We will now add a brand new feature to the profile page -- a list of fun facts about a person:
+
+```js{8,13-25}
+function ProfilePage({ resource }) {
+ return (
+ <>
+ Loading posts...}>
+
+ Fun Facts
+
+ {trivia.map(fact => (
+ {fact.text}
+ ))}
+
+
+ );
+}
+```
+
+**[Try it on CodeSandbox](https://codesandbox.io/s/focused-mountain-uhkzg)**
+
+If you press "Open Profile" now, you can tell something is wrong. It takes whole seven seconds to make the transition now! This is because our trivia API is too slow. Let's say we can't make the API faster. How can we improve the user experience with this constraint?
+
+If we don't want to stay in the Pending state for too long, our first instinct might be to set `timeoutMs` in `useTransition` to something smaller, like `3000`. You can try this [here](https://codesandbox.io/s/practical-kowalevski-kpjg4). This lets us escape the prolonged Pending state, but we still don't have anything useful to show!
+
+There is a simpler way to solve this. **Instead of making the transition shorter, we can "disconnect" the slow component from the transition** by wrapping it into ``:
+
+```js{8,10}
+function ProfilePage({ resource }) {
+ return (
+ <>
+ Loading posts...}>
+
+ Loading fun facts...}>
+
+
+ );
+}
+```
+
+**[Try it on CodeSandbox](https://codesandbox.io/s/condescending-shape-s6694)**
+
+This reveals an important insight. React always prefers to go to the Skeleton state as soon as possible. Even if we use transitions with long timeouts everywhere, React will not stay in the Pending state for longer than necessary to avoid the Receded state.
+
+**If some feature isn't a vital part of the next screen, wrap it in `` and let it load lazily.** This ensures we can show the rest of the content as soon as possible. Conversely, if a screen is *not worth showing* without some component, such as `` in our example, do *not* wrap it in ``. Then the transitions will "wait" for it to be ready.
+
+### Suspense Reveal "Train" {#suspense-reveal-train}
+
+When we're already on the next screen, sometimes the data needed to "unlock" different `` boundaries arrives in quick succession. For example, two different responses might arrive after 1000ms and 1050ms, respectively. If you've already waited for a second, waiting another 50ms is not going to be perceptible. This is why React reveals `` boundaries on a schedule, like a "train" that arrives periodically. This trades a small delay for reducing the layout thrashing and the number of visual changes presented to the user.
+
+You can see a demo of this [here](https://codesandbox.io/s/admiring-mendeleev-y54mk). The "posts" and "fun facts" responses come within 100ms of each other. But React coalesces them and "reveals" their Suspense boundaries together.
+
+### Delaying a Pending Indicator {#delaying-a-pending-indicator}
+
+Our `Button` component will immediately show the Pending state indicator on click:
+
+```js{2,13}
+function Button({ children, onClick }) {
+ const [startTransition, isPending] = useTransition({
+ timeoutMs: 10000
+ });
+
+ // ...
+
+ return (
+ <>
+
+ {children}
+
+ {isPending ? spinner : null}
+
+ );
+}
+```
+
+**[Try it on CodeSandbox](https://codesandbox.io/s/floral-thunder-iy826)**
+
+This signals to the user that some work is happening. However, if the transition is relatively short (less than 500ms), it might be too distracting and make the transition itself feel *slower*.
+
+One possible solution to this is to *delay the spinner itself* from displaying:
+
+```css
+.DelayedSpinner {
+ animation: 0s linear 0.5s forwards makeVisible;
+ visibility: hidden;
+}
+
+@keyframes makeVisible {
+ to {
+ visibility: visible;
+ }
+}
+```
+
+```js{2-4,10}
+const spinner = (
+
+ {/* ... */}
+
+);
+
+return (
+ <>
+ {children}
+ {isPending ? spinner : null}
+
+);
+```
+
+**[Try it on CodeSandbox](https://codesandbox.io/s/gallant-spence-l6wbk)**
+
+With this change, even though we're in the Pending state, we don't display any indication to the user until 500ms has passed. This may not seem like much of an improvement when the API responses are slow. But compare how it feels [before](https://codesandbox.io/s/thirsty-liskov-1ygph) and [after](https://codesandbox.io/s/hardcore-http-s18xr) when the API call is fast. Even though the rest of the code hasn't changed, suppressing a "too fast" loading state improves the perceived performance by not calling attention to the delay.
+
+### Recap {#recap}
+
+The most important things we learned so far are:
+
+* By default, our loading sequence is Receded → Skeleton → Complete.
+* The Receded state doesn't feel very nice because it hides existing content.
+* With `useTransition`, we can opt into showing a Pending state first instead. This will keep us on the previous screen while the next screen is being prepared.
+* If we don't want some component to delay the transition, we can wrap it in its own `` boundary.
+* Instead of doing `useTransition` in every other component, we can build it into our design system.
+
+## Other Patterns {#other-patterns}
+
+Transitions are probably the most common Concurrent Mode pattern you'll encounter, but there are a few more patterns you might find useful.
+
+### Splitting High and Low Priority State {#splitting-high-and-low-priority-state}
+
+When you design React components, it is usually best to find the "minimal representation" of state. For example, instead of keeping `firstName`, `lastName`, and `fullName` in state, it's usually better keep only `firstName` and `lastName`, and then calculate `fullName` during rendering. This lets us avoid mistakes where we update one state but forget the other state.
+
+However, in Concurrent Mode there are cases where you might *want* to "duplicate" some data in different state variables. Consider this tiny translation app:
+
+```js
+const initialQuery = "Hello, world";
+const initialResource = fetchTranslation(initialQuery);
+
+function App() {
+ const [query, setQuery] = useState(initialQuery);
+ const [resource, setResource] = useState(initialResource);
+
+ function handleChange(e) {
+ const value = e.target.value;
+ setQuery(value);
+ setResource(fetchTranslation(value));
+ }
+
+ return (
+ <>
+ Loading...}>
+
+
+ );
+}
+
+function Translation({ resource }) {
+ return (
+
+ {resource.read()}
+
+ );
+}
+```
+
+**[Try it on CodeSandbox](https://codesandbox.io/s/brave-villani-ypxvf)**
+
+Notice how when you type into the input, the `` component suspends, and we see the `Loading...
` fallback until we get fresh results. This is not ideal. It would be better if we could see the *previous* translation for a bit while we're fetching the next one.
+
+In fact, if we open the console, we'll see a warning:
+
+```
+Warning: App triggered a user-blocking update that suspended.
+
+The fix is to split the update into multiple parts: a user-blocking update to provide immediate feedback, and another update that triggers the bulk of the changes.
+
+Refer to the documentation for useTransition to learn how to implement this pattern.
+```
+
+As we mentioned earlier, if some state update causes a component to suspend, that state update should be wrapped in a transition. Let's add `useTransition` to our component:
+
+```js{4-6,10,13}
+function App() {
+ const [query, setQuery] = useState(initialQuery);
+ const [resource, setResource] = useState(initialResource);
+ const [startTransition, isPending] = useTransition({
+ timeoutMs: 5000
+ });
+
+ function handleChange(e) {
+ const value = e.target.value;
+ startTransition(() => {
+ setQuery(value);
+ setResource(fetchTranslation(value));
+ });
+ }
+
+ // ...
+
+}
+```
+
+**[Try it on CodeSandbox](https://codesandbox.io/s/zen-keldysh-rifos)**
+
+Try typing into the input now. Something's wrong! The input is updating very slowly.
+
+We've fixed the first problem (suspending outside of a transition). But now because of the transition, our state doesn't update immediately, and it can't "drive" a controlled input!
+
+The answer to this problem **is to split the state in two parts:** a "high priority" part that updates immediately, and a "low priority" part that may wait for a transition.
+
+In our example, we already have two state variables. The input text is in `query`, and we read the translation from `resource`. We want changes to the `query` state to happen immediately, but changes to the `resource` (i.e. fetching a new translation) should trigger a transition.
+
+So the correct fix is to put `setQuery` (which doesn't suspend) *outside* the transition, but `setResource` (which will suspend) *inside* of it.
+
+```js{4,5}
+function handleChange(e) {
+ const value = e.target.value;
+
+ // Outside the transition (urgent)
+ setQuery(value);
+
+ startTransition(() => {
+ // Inside the transition (may be delayed)
+ setResource(fetchTranslation(value));
+ });
+}
+```
+
+**[Try it on CodeSandbox](https://codesandbox.io/s/lively-smoke-fdf93)**
+
+With this change, it works as expected. We can type into the input immediately, and the translation later "catches up" to what we have typed.
+
+### Deferring a Value {#deferring-a-value}
+
+By default, React always renders a consistent UI. Consider code like this:
+
+```js
+<>
+ Loading profile...}>
+ Loading posts...}>
+
+
+ );
+}
+
+function ProfileTimeline({ isStale, resource }) {
+ const posts = resource.posts.read();
+ return (
+
+ {posts.map(post => (
+ {post.text}
+ ))}
+
+ );
+}
+```
+
+**[Try it on CodeSandbox](https://codesandbox.io/s/vigorous-keller-3ed2b)**
+
+The tradeoff we're making here is that `` will be inconsistent with other components and potentially show an older item. Click "Next" a few times, and you'll notice it. But thanks to that, we were able to cut down the transition time from 1000ms to 300ms.
+
+Whether or not it's an appropriate tradeoff depends on the situation. But it's a handy tool, especially when the content doesn't change very visible between items, and the user might not even realize they were looking at a stale version for a second.
+
+It's worth noting that `useDeferredValue` is not *only* useful for data fetching. It also helps when an expensive component tree causes an interaction (e.g. typing in an input) to be sluggish. Just like we can "defer" a value that takes too long to fetch (and show its old value despite others components updating), we can do this with trees that take too long to render.
+
+For example, consider a filterable list like this:
+
+```js
+function App() {
+ const [text, setText] = useState("hello");
+
+ function handleChange(e) {
+ setText(e.target.value);
+ }
+
+ return (
+
+
+ Type into the input:{" "}
+
+ ...
+
+ );
+}
+```
+
+**[Try it on CodeSandbox](https://codesandbox.io/s/pensive-shirley-wkp46)**
+
+In this example, **every item in `` has an artificial slowdown -- each of them blocks the thread for a few milliseconds**. We'd never do this in a real app, but this helps us simulate what can happen in a deep component tree with no single obvious place to optimize.
+
+We can see how typing in the input causes stutter. Now let's add `useDeferredValue`:
+
+```js{3-5,18}
+function App() {
+ const [text, setText] = useState("hello");
+ const deferredText = useDeferredValue(text, {
+ timeoutMs: 5000
+ });
+
+ function handleChange(e) {
+ setText(e.target.value);
+ }
+
+ return (
+
+
+ Type into the input:{" "}
+
+ ...
+
+ );
+}
+```
+
+**[Try it on CodeSandbox](https://codesandbox.io/s/infallible-dewdney-9fkv9)**
+
+Now typing has a lot less stutter -- although we pay for this by showing the results with a lag.
+
+How is this different from debouncing? Our example has a fixed artificial delay (3ms for every one of 80 items), so there is always a delay, no matter how fast our computer is. However, the `useDeferredValue` value only "lags behind" if the rendering takes a while. There is no minimal lag imposed by React. With a more realistic workload, you can expect the lag to adjust to the user’s device. On fast machines, the lag would be smaller or non-existent, and on slow machines, it would be more noticeable. In both cases, the app would remain responsive. That’s the advantage of this mechanism over debouncing or throttling, which always impose a minimal delay and can't avoid blocking the thread while rendering.
+
+Even though there is an improvement in responsiveness, this example isn't as compelling yet because Concurrent Mode is missing some crucial optimizations for this use case. Still, it is interesting to see that features like `useDeferredValue` (or `useTransition`) are useful regardless of whether we're waiting for network or for computational work to finish.
+
+### SuspenseList {#suspenselist}
+
+`` is the last pattern that's related to orchestrating loading states.
+
+Consider this example:
+
+```js{5-10}
+function ProfilePage({ resource }) {
+ return (
+ <>
+ Loading posts...}>
+
+ Loading fun facts...}>
+
+
+ );
+}
+```
+
+**[Try it on CodeSandbox](https://codesandbox.io/s/proud-tree-exg5t)**
+
+The API call duration in this example is randomized. If you keep refreshing it, you will notice that sometimes the posts arrive first, and sometimes the "fun facts" arrive first.
+
+This presents a problem. If the response for fun facts arrives first, we'll see the fun facts below the `Loading posts... ` fallback for posts. We might start reading them, but then the *posts* response will come back, and shift all the facts down. This is jarring.
+
+One way we could fix it is by putting them both in a single boundary:
+
+```js
+Loading posts and fun facts...}>
+
+```
+
+**[Try it on CodeSandbox](https://codesandbox.io/s/currying-violet-5jsiy)**
+
+The problem with this is that now we *always* wait for both of them to be fetched. However, if it's the *posts* that came back first, there's no reason to delay showing them. When fun facts load later, they won't shift the layout because they're already below the posts.
+
+Other approaches to this, such as composing Promises in a special way, are increasingly difficult to pull off when the loading states are located in different components down the tree.
+
+To solve this, we will import `SuspenseList`:
+
+```js
+import { SuspenseList } from 'react';
+```
+
+`` coordinates the "reveal order" of the closest `` nodes below it:
+
+```js{3,11}
+function ProfilePage({ resource }) {
+ return (
+
+ Loading posts...}>
+
+ Loading fun facts...}>
+
+
+ );
+}
+```
+
+**[Try it on CodeSandbox](https://codesandbox.io/s/black-wind-byilt)**
+
+The `revealOrder="forwards"` option means that the closest `` nodes inside this list **will only "reveal" their content in the order they appear in the tree -- even if the data for them arrives in a different order**. `` has other interesting modes: try changing `"forwards"` to `"backwards"` or `"together"` and see what happens.
+
+You can control how many loading states are visible at once with the `tail` prop. If we specify `tail="collapsed"`, we'll see *at most one* fallback at the time. You can play with it [here](https://codesandbox.io/s/adoring-almeida-1zzjh).
+
+Keep in mind that `` is composable, like anything in React. For example, you can create a grid by putting several `` rows inside a `` table.
+
+## Next Steps {#next-steps}
+
+Concurrent Mode offers a powerful UI programming model and a set of new composable primitives to help you orchestrate delightful user experiences.
+
+It's a result of several years of research and development, but it's not finished. In the section on [adopting Concurrent Mode](/docs/concurrent-mode-adoption.html), we'll describe how you can try it and what you can expect.
diff --git a/content/docs/concurrent-mode-reference.md b/content/docs/concurrent-mode-reference.md
new file mode 100644
index 000000000..81f333811
--- /dev/null
+++ b/content/docs/concurrent-mode-reference.md
@@ -0,0 +1,203 @@
+---
+id: concurrent-mode-reference
+title: Concurrent Mode API Reference (Experimental)
+permalink: docs/concurrent-mode-reference.html
+prev: concurrent-mode-adoption.html
+---
+
+>Caution:
+>
+>This page describes **experimental features that are [not yet available](/docs/concurrent-mode-adoption.html) in a stable release**. Don't rely on experimental builds of React in production apps. These features may change significantly and without a warning before they become a part of React.
+>
+>This documentation is aimed at early adopters and people who are curious. If you're new to React, don't worry about these features -- you don't need to learn them right now.
+
+This page is an API reference for the React [Concurrent Mode](/docs/concurrent-mode-intro.html). If you're looking for a guided introduction instead, check out [Concurrent UI Patterns](/docs/concurrent-mode-patterns.html).
+
+**Note: This is a Community Preview and not the final stable version. There will likely be future changes to these APIs. Use at your own risk!**
+
+- [Enabling Concurrent Mode](#concurrent-mode)
+ - [`createRoot`](#createroot)
+ - [`createBlockingRoot`](#createblockingroot)
+- [Suspense](#suspense)
+ - [`Suspense`](#suspensecomponent)
+ - [`SuspenseList`](#suspenselist)
+ - [`useTransition`](#usetransition)
+ - [`useDeferredValue`](#usedeferredvalue)
+
+## Enabling Concurrent Mode {#concurrent-mode}
+
+### `createRoot` {#createroot}
+
+```js
+ReactDOM.createRoot(rootNode).render(Loading...}>
+
+```
+
+`Suspense` lets your components "wait" for something before they can render, showing a fallback while waiting.
+
+In this example, `ProfileDetails` is waiting for an asynchronous API call to fetch some data. While we wait for `ProfileDetails` and `ProfilePhoto`, we will show the `Loading...` fallback instead. It is important to note that until all children inside `` has loaded, we will continue to show the fallback.
+
+`Suspense` takes two props:
+* **fallback** takes a loading indicator. The fallback is shown until all of the children of the `Suspense` component have finished rendering.
+* **unstable_avoidThisFallback** takes a boolean. It tells React whether to "skip" revealing this boundary during the initial load. This API will likely be removed in a future release.
+
+### `` {#suspenselist}
+
+```js
+
+
+
+
+
+
+
+ ...
+
+```
+
+`SuspenseList` helps coordinate many components that can suspend by orchestrating the order in which these components are revealed to the user.
+
+When multiple components need to fetch data, this data may arrive in an unpredictable order. However, if you wrap these items in a `SuspenseList`, React will not show an item in the list until previous items have been displayed (this behavior is adjustable).
+
+`SuspenseList` takes two props:
+* **revealOrder (forwards, backwards, together)** defines the order in which the `SuspenseList` children should be revealed.
+ * `together` reveals *all* of them when they're ready instead of one by one.
+* **tail (collapsed, hidden)** dictates how unloaded items in a `SuspenseList` is shown.
+ * By default, `SuspenseList` will show all fallbacks in the list.
+ * `collapsed` shows only the next fallback in the list.
+ * `hidden` doesn't show any unloaded items.
+
+Note that `SuspenseList` only operates on the closest `Suspense` and `SuspenseList` components below it. It does not search for boundaries deeper than one level. However, it is possible to nest multiple `SuspenseList` components in each other to build grids.
+
+### `useTransition` {#usetransition}
+
+```js
+const SUSPENSE_CONFIG = { timeoutMs: 2000 };
+
+const [startTransition, isPending] = useTransition(SUSPENSE_CONFIG);
+```
+
+`useTransition` allows components to avoid undesirable loading states by waiting for content to load before **transitioning to the next screen**. It also allows components to defer slower, data fetching updates until subsequent renders so that more crucial updates can be rendered immediately.
+
+The `useTransition` hook returns two values in an array.
+* `startTransition` is a function that takes a callback. We can use it to tell React which state we want to defer.
+* `isPending` is a boolean. It's React's way of informing us whether we're waiting for the transition to finish.
+
+**If some state update causes a component to suspend, that state update should be wrapped in a transition.**
+
+```js
+const SUSPENSE_CONFIG = {timeoutMs: 2000 };
+
+function App() {
+ const [resource, setResource] = useState(initialResource);
+ const [startTransition, isPending] = useTransition(SUSPENSE_CONFIG);
+ return (
+ <>
+ {
+ startTransition(() => {
+ const nextUserId = getNextId(resource.userId);
+ setResource(fetchProfileData(nextUserId));
+ });
+ }}
+ >
+ Next
+
+ {isPending ? " Loading..." : null}
+
+
+ );
+}
+```
+
+In this code, we've wrapped our data fetching with `startTransition`. This allows us to start fetching the profile data right away, while deferring the render of the next profile page and its associated `Spinner` for 2 seconds (the time shown in `timeoutMs`).
+
+The `isPending` boolean lets React know that our component is transitioning, so we are able to let the user know this by showing some loading text on the previous profile page.
+
+**For an in-depth look at transitions, you can read [Concurrent UI Patterns](/docs/concurrent-mode-patterns.html#transitions).**
+
+#### useTransition Config {#usetransition-config}
+
+```js
+const SUSPENSE_CONFIG = { timeoutMs: 2000 };
+```
+
+`useTransition` accepts an **optional Suspense Config** with a `timeoutMs`. This timeout (in milliseconds) tells React how long to wait before showing the next state (the new Profile Page in the above example).
+
+**Note: We recommend that you share Suspense Config between different modules.**
+
+
+### `useDeferredValue` {#usedeferredvalue}
+
+```js
+const deferredValue = useDeferredValue(value, { timeoutMs: 2000 });
+```
+
+Returns a deferred version of the value that may "lag behind" it for at most `timeoutMs`.
+
+This is commonly used to keep the interface responsive when you have something that renders immediately based on user input and something that needs to wait for a data fetch.
+
+A good example of this is a text input.
+
+```js
+function App() {
+ const [text, setText] = useState("hello");
+ const deferredText = useDeferredValue(text, {timeoutMs: 2000 });
+
+ return (
+
+ {/* Keep passing the current text to the input */}
+
+ );
+ }
+```
+
+This allows us to start showing the new text for the `input` immediately, which allows the webpage to feel responsive. Meanwhile, `MySlowList` "lag behind" for up to 2 seconds according to the `timeoutMs` before updating, allowing it to render with the current text in the background.
+
+**For an in-depth look at deferring values, you can read [Concurrent UI Patterns](/docs/concurrent-mode-patterns.html#deferring-a-value).**
+
+#### useDeferredValue Config {#usedeferredvalue-config}
+
+```js
+const SUSPENSE_CONFIG = { timeoutMs: 2000 };
+```
+
+`useDeferredValue` accepts an **optional Suspense Config** with a `timeoutMs`. This timeout (in milliseconds) tells React how long the deferred value is allowed to lag behind.
+
+React will always try to use a shorter lag when network and device allows it.
diff --git a/content/docs/concurrent-mode-suspense.md b/content/docs/concurrent-mode-suspense.md
new file mode 100644
index 000000000..6c1beea32
--- /dev/null
+++ b/content/docs/concurrent-mode-suspense.md
@@ -0,0 +1,675 @@
+---
+id: concurrent-mode-suspense
+title: Suspense for Data Fetching (Experimental)
+permalink: docs/concurrent-mode-suspense.html
+prev: concurrent-mode-intro.html
+next: concurrent-mode-patterns.html
+---
+
+>Caution:
+>
+>This page describes **experimental features that are [not yet available](/docs/concurrent-mode-adoption.html) in a stable release**. Don't rely on experimental builds of React in production apps. These features may change significantly and without a warning before they become a part of React.
+>
+>This documentation is aimed at early adopters and people who are curious. If you're new to React, don't worry about these features -- you don't need to learn them right now.
+
+
+React 16.6 added a `` component that lets you "wait" for some code to load and declaratively specify a loading state (like a spinner) while we're waiting:
+
+```jsx
+const ProfilePage = React.lazy(() => import('./ProfilePage')); // Lazy-loaded
+
+// Show a spinner while the profile is loading
+
+```
+
+Suspense for Data Fetching is a new feature that lets you also use `` to **declaratively "wait" for anything else, including data.** This page focuses on the data fetching use case, but it can also wait for images, scripts, or other asynchronous work.
+
+- [What Is Suspense, Exactly?](#what-is-suspense-exactly)
+ - [What Suspense Is Not](#what-suspense-is-not)
+ - [What Suspense Lets You Do](#what-suspense-lets-you-do)
+- [Using Suspense in Practice](#using-suspense-in-practice)
+ - [What If I Don’t Use Relay?](#what-if-i-dont-use-relay)
+ - [For Library Authors](#for-library-authors)
+- [Traditional Approaches vs Suspense](#traditional-approaches-vs-suspense)
+ - [Approach 1: Fetch-on-Render (not using Suspense)](#approach-1-fetch-on-render-not-using-suspense)
+ - [Approach 2: Fetch-Then-Render (not using Suspense)](#approach-2-fetch-then-render-not-using-suspense)
+ - [Approach 3: Render-as-You-Fetch (using Suspense)](#approach-3-render-as-you-fetch-using-suspense)
+ - [We’re Still Figuring This Out](#were-still-figuring-this-out)
+- [Suspense and Race Conditions](#suspense-and-race-conditions)
+ - [Race Conditions with useEffect](#race-conditions-with-useeffect)
+ - [Race Conditions with componentDidUpdate](#race-conditions-with-componentdidupdate)
+ - [The Problem](#the-problem)
+ - [Solving Race Conditions with Suspense](#solving-race-conditions-with-suspense)
+- [Handling Errors](#handling-errors)
+- [Next Steps](#next-steps)
+
+## What Is Suspense, Exactly? {#what-is-suspense-exactly}
+
+Suspense lets your components "wait" for something before they can render. In [this example](https://codesandbox.io/s/frosty-hermann-bztrp), two components wait for an asynchronous API call to fetch some data:
+
+```js
+const resource = fetchProfileData();
+
+function ProfilePage() {
+ return (
+ Loading profile...}>
+ Loading posts...}>
+
+
+ );
+}
+
+function ProfileDetails() {
+ // Try to read user info, although it might not have loaded yet
+ const user = resource.user.read();
+ return {user.name} ;
+}
+
+function ProfileTimeline() {
+ // Try to read posts, although they might not have loaded yet
+ const posts = resource.posts.read();
+ return (
+
+ {posts.map(post => (
+ {post.text}
+ ))}
+
+ );
+}
+```
+
+**[Try it on CodeSandbox](https://codesandbox.io/s/frosty-hermann-bztrp)**
+
+This demo is a teaser. Don't worry if it doesn't quite make sense yet. We'll talk more about how it works below. Keep in mind that Suspense is more of a *mechanism*, and particular APIs like `fetchProfileData()` or `resource.posts.read()` in the above example are not very important. If you're curious, you can find their definitions right in the [demo sandbox](https://codesandbox.io/s/frosty-hermann-bztrp).
+
+Suspense is not a data fetching library. It's a **mechanism for data fetching libraries** to communicate to React that *the data a component is reading is not ready yet*. React can then wait for it to be ready and update the UI. At Facebook, we use Relay and its [new Suspense integration](https://relay.dev/docs/en/experimental/a-guided-tour-of-relay#loading-states-with-suspense). We expect that other libraries like Apollo can provide similar integrations.
+
+In the long term, we intend Suspense to become the primary way to read asynchronous data from components -- no matter where that data is coming from.
+
+### What Suspense Is Not {#what-suspense-is-not}
+
+Suspense is significantly different from existing approaches to these problems, so reading about it for the first time often leads to misconceptions. Let's clarify the most common ones:
+
+ * **It is not a data fetching implementation.** It does not assume that you use GraphQL, REST, or any other particular data format, library, transport, or protocol.
+
+ * **It is not a ready-to-use client.** You can't "replace" `fetch` or Relay with Suspense. But you can use a library that's integrated with Suspense (for example, [new Relay APIs](https://relay.dev/docs/en/experimental/api-reference)).
+
+ * **It does not couple data fetching to the view layer.** It helps orchestrate displaying the loading states in your UI, but it doesn't tie your network logic to React components.
+
+### What Suspense Lets You Do {#what-suspense-lets-you-do}
+
+So what's the point of Suspense? There's a few ways we can answer this:
+
+* **It lets data fetching libraries deeply integrate with React.** If a data fetching library implements Suspense support, using it from React components feels very natural.
+
+* **It lets you orchestrate intentionally designed loading states.** It doesn't say _how_ the data is fetched, but it lets you closely control the visual loading sequence of your app.
+
+* **It helps you avoid race conditions.** Even with `await`, asynchronous code is often error-prone. Suspense feels more like reading data *synchronously* — as if it was already loaded.
+
+## Using Suspense in Practice {#using-suspense-in-practice}
+
+At Facebook, so far we have only used the Relay integration with Suspense in production. **If you're looking for a practical guide to get started today, [check out the Relay Guide](https://relay.dev/docs/en/experimental/a-guided-tour-of-relay)!** It demonstrates patterns that have already worked well for us in production.
+
+**The code demos on this page use a "fake" API implementation rather than Relay.** This makes them easier to understand if you're not familiar with GraphQL, but they won't tell you the "right way" to build an app with Suspense. This page is more conceptual and is intended to help you see *why* Suspense works in a certain way, and which problems it solves.
+
+### What If I Don't Use Relay? {#what-if-i-dont-use-relay}
+
+If you don't use Relay today, you might have to wait before you can really try Suspense in your app. So far, it's the only implementation that we tested in production and are confident in.
+
+Over the next several months, many libraries will appear with different takes on Suspense APIs. **If you prefer to learn when things are more stable, you might prefer to ignore this work for now, and come back when the Suspense ecosystem is more mature.**
+
+You can also write your own integration for a data fetching library, if you'd like.
+
+### For Library Authors {#for-library-authors}
+
+We expect to see a lot of experimentation in the community with other libraries. There is one important thing to note for data fetching library authors.
+
+Although it's technically doable, Suspense is **not** currently intended as a way to start fetching data when a component renders. Rather, it lets components express that they're "waiting" for data that is *already being fetched*. Unless you have an idea for a solution that helps prevent waterfalls, we suggest to prefer APIs that favor or enforce fetching before render. The current documentation for [Relay Suspense API](https://relay.dev/docs/en/experimental/api-reference#usepreloadedquery) doesn't yet dive deep into preloading, but we plan to publish more about these techniques in the near future.
+
+Our messaging about this hasn't been very consistent in the past. Suspense for Data Fetching is still experimental, so you can expect our recommendations to change over time as we learn more from production usage and understand the problem space better.
+
+## Traditional Approaches vs Suspense {#traditional-approaches-vs-suspense}
+
+We could introduce Suspense without mentioning the popular data fetching approaches. However, this makes it more difficult to see which problems Suspense solves, why these problems are worth solving, and how Suspense is different from the existing solutions.
+
+Instead, we'll look at Suspense as a logical next step in a sequence of approaches:
+
+* **Fetch-on-render (for example, `fetch` in `useEffect`):** Start rendering components. Each of these components may trigger data fetching in their effects and lifecycle methods. This approach often leads to "waterfalls".
+* **Fetch-then-render (for example, Relay without Suspense):** Start fetching all the data for the next screen as early as possible. When the data is ready, render the new screen. We can't do anything until the data arrives.
+* **Render-as-you-fetch (for example, Relay with Suspense):** Start fetching all the required data for the next screen as early as possible, and start rendering the new screen *immediately — before we get a network response*. As data streams in, React retries rendering components that still need data until they're all ready.
+
+>Note
+>
+>This is a bit simplified, and in practice solutions tend to use a mix of different approaches. Still, we will look at them in isolation to better contrast their tradeoffs.
+
+To compare these approaches, we'll implement a profile page with each of them.
+
+### Approach 1: Fetch-on-Render (not using Suspense) {#approach-1-fetch-on-render-not-using-suspense}
+
+A common way to fetch data in React apps today is to use an effect:
+
+```js
+// In a function component:
+useEffect(() => {
+ fetchSomething();
+}, []);
+
+// Or, in a class component:
+componentDidMount() {
+ fetchSomething();
+}
+```
+
+We call this approach "fetch-on-render" because it doesn't start fetching until *after* the component has rendered on the screen. This leads to a problem known as a "waterfall".
+
+Consider these `` and `` components:
+
+```js{4-6,22-24}
+function ProfilePage() {
+ const [user, setUser] = useState(null);
+
+ useEffect(() => {
+ fetchUser().then(u => setUser(u));
+ }, []);
+
+ if (user === null) {
+ return Loading profile...
;
+ }
+ return (
+ <>
+ {user.name}
+ Loading posts... ;
+ }
+ return (
+
+ {posts.map(post => (
+ {post.text}
+ ))}
+
+ );
+}
+```
+
+**[Try it on CodeSandbox](https://codesandbox.io/s/fragrant-glade-8huj6)**
+
+If you run this code and watch the console logs, you'll notice the sequence is:
+
+1. We start fetching user details
+2. We wait...
+3. We finish fetching user details
+4. We start fetching posts
+5. We wait...
+6. We finish fetching posts
+
+If fetching user details takes three seconds, we'll only *start* fetching the posts after three seconds! That's a "waterfall": an unintentional *sequence* that should have been parallelized.
+
+Waterfalls are common in code that fetches data on render. They're possible to solve, but as the product grows, many people prefer to use a solution that guards against this problem.
+
+### Approach 2: Fetch-Then-Render (not using Suspense) {#approach-2-fetch-then-render-not-using-suspense}
+
+Libraries can prevent waterfalls by offering a more centralized way to do data fetching. For example, Relay solves this problem by moving the information about the data a component needs to statically analyzable *fragments*, which later get composed into a single query.
+
+On this page, we don't assume knowledge of Relay, so we won't be using it for this example. Instead, we'll write something similar manually by combining our data fetching methods:
+
+```js
+function fetchProfileData() {
+ return Promise.all([
+ fetchUser(),
+ fetchPosts()
+ ]).then(([user, posts]) => {
+ return {user, posts};
+ })
+}
+```
+
+In this example, `` waits for both requests but starts them in parallel:
+
+```js{1,2,8-13}
+// Kick off fetching as early as possible
+const promise = fetchProfileData();
+
+function ProfilePage() {
+ const [user, setUser] = useState(null);
+ const [posts, setPosts] = useState(null);
+
+ useEffect(() => {
+ promise.then(data => {
+ setUser(data.user);
+ setPosts(data.posts);
+ });
+ }, []);
+
+ if (user === null) {
+ return Loading profile...
;
+ }
+ return (
+ <>
+ {user.name}
+ Loading posts... ;
+ }
+ return (
+
+ {posts.map(post => (
+ {post.text}
+ ))}
+
+ );
+}
+```
+
+**[Try it on CodeSandbox](https://codesandbox.io/s/wandering-morning-ev6r0)**
+
+The event sequence now becomes like this:
+
+1. We start fetching user details
+2. We start fetching posts
+3. We wait...
+4. We finish fetching user details
+5. We finish fetching posts
+
+We've solved the previous network "waterfall", but accidentally introduced a different one. We wait for *all* data to come back with `Promise.all()` inside `fetchProfileData`, so now we can't render profile details until the posts have been fetched too. We have to wait for both.
+
+Of course, this is possible to fix in this particular example. We could remove the `Promise.all()` call, and wait for both Promises separately. However, this approach gets progressively more difficult as the complexity of our data and component tree grows. It's hard to write reliable components when arbitrary parts of the data tree may be missing or stale. So fetching all data for the new screen and *then* rendering is often a more practical option.
+
+### Approach 3: Render-as-You-Fetch (using Suspense) {#approach-3-render-as-you-fetch-using-suspense}
+
+In the previous approach, we fetched data before we called `setState`:
+
+1. Start fetching
+2. Finish fetching
+3. Start rendering
+
+With Suspense, we still start fetching first, but we flip the last two steps around:
+
+1. Start fetching
+2. **Start rendering**
+3. **Finish fetching**
+
+**With Suspense, we don't wait for the response to come back before we start rendering.** In fact, we start rendering *pretty much immediately* after kicking off the network request:
+
+```js{2,17,23}
+// This is not a Promise. It's a special object from our Suspense integration.
+const resource = fetchProfileData();
+
+function ProfilePage() {
+ return (
+ Loading profile...}>
+ Loading posts...}>
+
+
+ );
+}
+
+function ProfileDetails() {
+ // Try to read user info, although it might not have loaded yet
+ const user = resource.user.read();
+ return {user.name} ;
+}
+
+function ProfileTimeline() {
+ // Try to read posts, although they might not have loaded yet
+ const posts = resource.posts.read();
+ return (
+
+ {posts.map(post => (
+ {post.text}
+ ))}
+
+ );
+}
+```
+
+**[Try it on CodeSandbox](https://codesandbox.io/s/frosty-hermann-bztrp)**
+
+Here's what happens when we render `` on the screen:
+
+1. We've already kicked off the requests in `fetchProfileData()`. It gave us a special "resource" instead of a Promise. In a realistic example, it would be provided by our data library's Suspense integration, like Relay.
+2. React tries to render ``. It returns `` and `` as children.
+3. React tries to render ``. It calls `resource.user.read()`. None of the data is fetched yet, so this component "suspends". React skips over it, and tries rendering other components in the tree.
+4. React tries to render ``. It calls `resource.posts.read()`. Again, there's no data yet, so this component also "suspends". React skips over it too, and tries rendering other components in the tree.
+5. There's nothing left to try rendering. Because `` suspended, React shows the closest `` fallback above it in the tree: `Loading profile... `. We're done for now.
+
+This `resource` object represents the data that isn't there yet, but might eventually get loaded. When we call `read()`, we either get the data, or the component "suspends".
+
+**As more data streams in, React will retry rendering, and each time it might be able to progress "deeper".** When `resource.user` is fetched, the `` component will render successfully and we'll no longer need the `Loading profile... ` fallback. Eventually, we'll get all the data, and there will be no fallbacks on the screen.
+
+This has an interesting implication. Even if we use a GraphQL client that collects all data requirements in a single request, *streaming the response lets us show more content sooner*. Because we render-*as-we-fetch* (as opposed to *after* fetching), if `user` appear in the response earlier than `posts`, we'll be able to "unlock" the outer `` boundary before the response even finishes. We might have missed this earlier, but even the fetch-then-render solution contained a waterfall: between fetching and rendering. Suspense doesn't inherently suffer from this waterfall, and libraries like Relay take advantage of this.
+
+Note how we eliminated the `if (...)` "is loading" checks from our components. This doesn't only remove boilerplate code, but it also simplifies making quick design changes. For example, if we wanted profile details and posts to always "pop in" together, we could delete the `` boundary between them. Or we could make them independent from each other by giving each *its own* `` boundary. Suspense lets us change the granularity of our loading states and orchestrate their sequencing without invasive changes to our code.
+
+### We're Still Figuring This Out {#were-still-figuring-this-out}
+
+Suspense itself as a mechanism is flexible and doesn't have many constraints. Product code needs to be more constrained to ensure no waterfalls, but there are different ways to provide these guarantees. Some questions that we're currently exploring include:
+
+* Fetching early can be cumbersome to express. How do we make it easier to avoid waterfalls?
+* When we fetch data for a page, can the API encourage including data for instant transitions *from* it?
+* What is the lifetime of a response? Should caching be global or local? Who manages the cache?
+* Can Proxies help express lazy-loaded APIs without inserting `read()` calls everywhere?
+* What would the equivalent of composing GraphQL queries look like for arbitrary Suspense data?
+
+Relay has its own answers to some of these questions. There is certainly more than a single way to do it, and we're excited to see what new ideas the React community comes up with.
+
+## Suspense and Race Conditions {#suspense-and-race-conditions}
+
+Race conditions are bugs that happen due to incorrect assumptions about the order in which our code may run. Fetching data in the `useEffect` Hook or in class lifecycle methods like `componentDidUpdate` often leads to them. Suspense can help here, too — let's see how.
+
+To demonstrate the issue, we will add a top-level `` component that renders our `` with a button that lets us **switch between different profiles**:
+
+```js{9-11}
+function getNextId(id) {
+ // ...
+}
+
+function App() {
+ const [id, setId] = useState(0);
+ return (
+ <>
+ setId(getNextId(id))}>
+ Next
+
+ ` props to `fetchUser(id)` and `fetchPosts(id)`:
+
+```js{1,5,6,14,19,23,24}
+function ProfilePage({ id }) {
+ const [user, setUser] = useState(null);
+
+ useEffect(() => {
+ fetchUser(id).then(u => setUser(u));
+ }, [id]);
+
+ if (user === null) {
+ return Loading profile...
;
+ }
+ return (
+ <>
+ {user.name}
+ Loading posts... ;
+ }
+ return (
+
+ {posts.map(post => (
+ {post.text}
+ ))}
+
+ );
+}
+```
+
+**[Try it on CodeSandbox](https://codesandbox.io/s/nervous-glade-b5sel)**
+
+Note how we also changed the effect dependencies from `[]` to `[id]` — because we want the effect to re-run when the `id` changes. Otherwise, we wouldn't refetch new data.
+
+If we try this code, it might seem like it works at first. However, if we randomize the delay time in our "fake API" implementation and press the "Next" button fast enough, we'll see from the console logs that something is going very wrong. **Requests from the previous profiles may sometimes "come back" after we've already switched the profile to another ID -- and in that case they can overwrite the new state with a stale response for a different ID.**
+
+This problem is possible to fix (you could use the effect cleanup function to either ignore or cancel stale requests), but it's unintuitive and difficult to debug.
+
+### Race Conditions with `componentDidUpdate` {#race-conditions-with-componentdidupdate}
+
+One might think that this is a problem specific to `useEffect` or Hooks. Maybe if we port this code to classes or use convenient syntax like `async` / `await`, it will solve the problem?
+
+Let's try that:
+
+```js
+class ProfilePage extends React.Component {
+ state = {
+ user: null,
+ };
+ componentDidMount() {
+ this.fetchData(this.props.id);
+ }
+ componentDidUpdate(prevProps) {
+ if (prevProps.id !== this.props.id) {
+ this.fetchData(this.props.id);
+ }
+ }
+ async fetchData(id) {
+ const user = await fetchUser(id);
+ this.setState({ user });
+ }
+ render() {
+ const { id } = this.props;
+ const { user } = this.state;
+ if (user === null) {
+ return Loading profile...
;
+ }
+ return (
+ <>
+ {user.name}
+ Loading posts... ;
+ }
+ return (
+
+ {posts.map(post => (
+ {post.text}
+ ))}
+
+ );
+ }
+}
+```
+
+**[Try it on CodeSandbox](https://codesandbox.io/s/trusting-clarke-8twuq)**
+
+This code is deceptively easy to read.
+
+Unfortunately, neither using a class nor the `async` / `await` syntax helped us solve this problem. This version suffers from exactly the same race conditions, for the same reasons.
+
+### The Problem {#the-problem}
+
+React components have their own "lifecycle". They may receive props or update state at any point in time. However, each asynchronous request *also* has its own "lifecycle". It starts when we kick it off, and finishes when we get a response. The difficulty we're experiencing is "synchronizing" several processes in time that affect each other. This is hard to think about.
+
+### Solving Race Conditions with Suspense {#solving-race-conditions-with-suspense}
+
+Let's rewrite this example again, but using Suspense only:
+
+```js
+const initialResource = fetchProfileData(0);
+
+function App() {
+ const [resource, setResource] = useState(initialResource);
+ return (
+ <>
+ {
+ const nextUserId = getNextId(resource.userId);
+ setResource(fetchProfileData(nextUserId));
+ }}>
+ Next
+
+ Loading profile...}>
+ Loading posts...}>
+
+
+ );
+}
+
+function ProfileDetails({ resource }) {
+ const user = resource.user.read();
+ return {user.name} ;
+}
+
+function ProfileTimeline({ resource }) {
+ const posts = resource.posts.read();
+ return (
+
+ {posts.map(post => (
+ {post.text}
+ ))}
+
+ );
+}
+```
+
+**[Try it on CodeSandbox](https://codesandbox.io/s/infallible-feather-xjtbu)**
+
+In the previous Suspense example, we only had one `resource`, so we held it in a top-level variable. Now that we have multiple resources, we moved it to the ``'s component state:
+
+```js{4}
+const initialResource = fetchProfileData(0);
+
+function App() {
+ const [resource, setResource] = useState(initialResource);
+```
+
+When we click "Next", the `` component kicks off a request for the next profile, and passes *that* object down to the `` component:
+
+```js{4,8}
+ <>
+ {
+ const nextUserId = getNextId(resource.userId);
+ setResource(fetchProfileData(nextUserId));
+ }}>
+ Next
+
+ ` components.
+
+This code is very readable, but unlike the examples earlier, the Suspense version doesn't suffer from race conditions. You might be wondering why. The answer is that in the Suspense version, we don't have to think about *time* as much in our code. Our original code with race conditions needed to set the state *at the right moment later*, or otherwise it would be wrong. But with Suspense, we set the state *immediately* -- so it's harder to mess it up.
+
+## Handling Errors {#handling-errors}
+
+When we write code with Promises, we might use `catch()` to handle errors. How does this work with Suspense, given that we don't *wait* for Promises to start rendering?
+
+With Suspense, handling fetching errors works the same way as handling rendering errors -- you can render an [error boundary](/docs/error-boundaries.html) anywhere to "catch" errors in components below.
+
+First, we'll define an error boundary component to use across our project:
+
+```js
+// Error boundaries currently have to be classes.
+class ErrorBoundary extends React.Component {
+ state = { hasError: false, error: null };
+ static getDerivedStateFromError(error) {
+ return {
+ hasError: true,
+ error
+ };
+ }
+ render() {
+ if (this.state.hasError) {
+ return this.props.fallback;
+ }
+ return this.props.children;
+ }
+}
+```
+
+And then we can put it anywhere in the tree to catch errors:
+
+```js{5,9}
+function ProfilePage() {
+ return (
+ Loading profile...}>
+ Could not fetch posts.}>
+ Loading posts...}>
+
+
+
+ );
+}
+```
+
+**[Try it on CodeSandbox](https://codesandbox.io/s/adoring-goodall-8wbn7)**
+
+It would catch both rendering errors *and* errors from Suspense data fetching. We can have as many error boundaries as we like but it's best to [be intentional](https://aweary.dev/fault-tolerance-react/) about their placement.
+
+## Next Steps {#next-steps}
+
+We've now covered the basics of Suspense for Data Fetching! Importantly, we now better understand *why* Suspense works this way, and how it fits into the data fetching space.
+
+Suspense answers some questions, but it also poses new questions of its own:
+
+* If some component "suspends", does the app freeze? How to avoid this?
+* What if we want to show a spinner in a different place than "above" the component in a tree?
+* If we intentionally *want* to show an inconsistent UI for a small period time, can we do that?
+* Instead of showing a spinner, can we add a visual effect like "greying out" the current screen?
+* Why does our [last Suspense example](https://codesandbox.io/s/infallible-feather-xjtbu) log a warning when clicking the "Next" button?
+
+To answer these questions, we will refer to the next section on [Concurrent UI Patterns](/docs/concurrent-mode-patterns.html).
diff --git a/content/docs/faq-versioning.md b/content/docs/faq-versioning.md
index 0c4bebd1c..d60aed03e 100644
--- a/content/docs/faq-versioning.md
+++ b/content/docs/faq-versioning.md
@@ -18,6 +18,8 @@ React は[セマンティック バージョニング (semantic versioning; semv
マイナーリリースは、最も一般的なリリースです。
+> このバージョニングポリシーは Next と Experimental チャンネルのプレリリースビルドには適用されません。[プレリリースについての詳細](/docs/release-channels.html)
+
### 破壊的変更 {#breaking-changes}
破壊的変更は誰にとっても不便なので、私たちはメジャーリリースを最小限にするようにしています。例えば React 15 は 2016 年 4 月にリリースされており、React 16 は 2017 年の 9 月にリリースされています。そして React 17 は 2019 年までリリースが見込まれていません。
diff --git a/content/docs/nav.yml b/content/docs/nav.yml
index 76d25b489..2ad0c6129 100644
--- a/content/docs/nav.yml
+++ b/content/docs/nav.yml
@@ -8,6 +8,8 @@
title: 新しい React アプリを作る
- id: cdn-links
title: CDN リンク
+ - id: release-channels
+ title: Release Channels
- title: Main Concepts
isOrdered: true
items:
@@ -106,25 +108,25 @@
title: JavaScript 環境の要件
- id: glossary
title: React 用語集
-- title: Hooks (New)
+- title: Hooks
isOrdered: true
items:
- - id: hooks-intro
- title: フックの導入
- - id: hooks-overview
- title: フック早わかり
- - id: hooks-state
- title: ステートフックの利用法
- - id: hooks-effect
- title: 副作用フックの利用法
- - id: hooks-rules
- title: フックのルール
- - id: hooks-custom
- title: カスタムフックの作成
- - id: hooks-reference
- title: フック API リファレンス
- - id: hooks-faq
- title: フックに関するよくある質問
+ - id: hooks-intro
+ title: フックの導入
+ - id: hooks-overview
+ title: フック早わかり
+ - id: hooks-state
+ title: ステートフックの利用法
+ - id: hooks-effect
+ title: 副作用フックの利用法
+ - id: hooks-rules
+ title: フックのルール
+ - id: hooks-custom
+ title: カスタムフックの作成
+ - id: hooks-reference
+ title: フック API リファレンス
+ - id: hooks-faq
+ title: フックに関するよくある質問
- title: Testing
items:
- id: testing
@@ -133,16 +135,29 @@
title: テストのレシピ集
- id: testing-environments
title: Testing Environments
+- title: Concurrent Mode (Experimental)
+ isOrdered: true
+ items:
+ - id: concurrent-mode-intro
+ title: Introducing Concurrent Mode
+ - id: concurrent-mode-suspense
+ title: Suspense for Data Fetching
+ - id: concurrent-mode-patterns
+ title: Concurrent UI Patterns
+ - id: concurrent-mode-adoption
+ title: Adopting Concurrent Mode
+ - id: concurrent-mode-reference
+ title: Concurrent Mode API Reference
- title: Contributing
items:
- - id: how-to-contribute
- title: 貢献の方法
- - id: codebase-overview
- title: コードベースの概要
- - id: implementation-notes
- title: 実装に関するメモ
- - id: design-principles
- title: 設計原則
+ - id: how-to-contribute
+ title: 貢献の方法
+ - id: codebase-overview
+ title: コードベースの概要
+ - id: implementation-notes
+ title: 実装に関するメモ
+ - id: design-principles
+ title: 設計原則
- title: FAQ
items:
- id: faq-ajax
diff --git a/content/docs/reference-profiler.md b/content/docs/reference-profiler.md
index 58a9e41c9..cb64fef1a 100644
--- a/content/docs/reference-profiler.md
+++ b/content/docs/reference-profiler.md
@@ -16,7 +16,7 @@ Its purpose is to help identify parts of an application that are slow and may be
> To opt into production profiling, React provides a special production build with profiling enabled.
> Read more about how to use this build at [fb.me/react-profiling](https://fb.me/react-profiling)
-## Usage
+## Usage {#usage}
A `Profiler` can be added anywhere in a React tree to measure the cost of rendering that part of the tree.
It requires two props: an `id` (string) and an `onRender` callback (function) which React calls any time a component within the tree "commits" an update.
@@ -70,7 +70,7 @@ render(
>
> Although `Profiler` is a light-weight component, it should be used only when necessary; each use adds some CPU and memory overhead to an application.
-## `onRender` Callback
+## `onRender` Callback {#onrender-callback}
The `Profiler` requires an `onRender` function as a prop.
React calls this function any time a component within the profiled tree "commits" an update.
diff --git a/content/docs/release-channels.md b/content/docs/release-channels.md
new file mode 100644
index 000000000..e6e814f41
--- /dev/null
+++ b/content/docs/release-channels.md
@@ -0,0 +1,95 @@
+---
+id: release-channels
+title: Release Channels
+permalink: docs/release-channels.html
+layout: docs
+category: installation
+---
+
+React relies on a thriving open source community to file bug reports, open pull requests, and [submit RFCs](https://github.com/reactjs/rfcs). To encourage feedback we sometimes share special builds of React that include unreleased features.
+
+> This document will be most relevant to developers who work on frameworks, libraries, or developer tooling. Developers who use React primarily to build user-facing applications should not need to worry about our prerelease channels.
+
+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 master 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 master 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](/docs/faq-versioning.html). Prereleases (those in the Next and Experimental channels) have versions generated from a hash of their contents, e.g. `0.0.0-1022ee0ec` for Next and `0.0.0-experimental-1022ee0ec` 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.
+
+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).
+
+### Latest Channel
+
+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. Learn more about our commitment to stability and incremental migration in our [versioning policy](/docs/faq-versioning.html).
+
+### Next Channel
+
+The Next channel is a prerelease channel that tracks the master 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 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.
+
+**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, e.g. `0.0.0-1022ee0ec`.
+
+#### Using the Next Channel for Integration Testing
+
+The Next 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:
+
+ ```
+ npm update react@next react-dom@next
+ ```
+
+ Or yarn:
+
+ ```
+ yarn upgrade react@next react-dom@next
+ ```
+- 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.
+
+### Experimental Channel
+
+Like Next, the Experimental channel is a prerelease channel that tracks the master branch of the React repository. Unlike Next, 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.
+
+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.
+
+Releases in Experimental are published with the `experimental` tag on npm. Versions are generated from a hash of the build's contents, e.g. `0.0.0-experimental-1022ee0ec`.
+
+#### What Goes Into an Experimental Release?
+
+Experimental features are ones that are not ready to be released to the wider public, and may change drastically before they are finalized. Some experiments may never be finalized -- the reason we have experiments is to test the viability of proposed changes.
+
+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.**
+
+#### 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 Stable.
+
+If a feature is not documented, they may be accompanied by an [RFC](https://github.com/reactjs/rfcs).
+
+We will post to the [React blog](/blog) when we're ready to announce new experiments, but that doesn't mean we will publicize every experiment.
+
+You can always refer to our public GitHub repository's [history](https://github.com/facebook/react/commits/master) for a comprehensive list of changes.
diff --git a/content/images/docs/cm-steps-simple.png b/content/images/docs/cm-steps-simple.png
new file mode 100644
index 000000000..e5683f9e6
Binary files /dev/null and b/content/images/docs/cm-steps-simple.png differ
diff --git a/content/languages.yml b/content/languages.yml
index 499c8ea4a..1756ade25 100644
--- a/content/languages.yml
+++ b/content/languages.yml
@@ -26,7 +26,7 @@
- name: Catalan
translated_name: Català
code: ca
- status: 0
+ status: 1
- name: German
translated_name: Deutsch
code: de
diff --git a/static/_redirects b/static/_redirects
index 77b358127..3c683238d 100644
--- a/static/_redirects
+++ b/static/_redirects
@@ -1,5 +1,6 @@
/html-jsx.html https://magic.reactjs.net/htmltojsx.htm 301
/tips/controlled-input-null-value.html /docs/forms.html#controlled-input-null-value
+/concurrent /docs/concurrent-mode-intro.html
/hooks /docs/hooks-intro.html
/tutorial /tutorial/tutorial.html
/your-story https://www.surveymonkey.co.uk/r/MVQV2R9 301
\ No newline at end of file