Suspense fallback behavior change
Suspense fallback={undefined} now behaves the same as fallback={null} and is not ignored in React 18.
React · API reference · all subjects
advanced topics
20 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.
Concurrent React - rendering is interruptible
Concurrent React enables rendering to be interruptible. React may start rendering an update, pause in the middle, then continue later, or even abandon an in-progress render altogether. React guarantees the UI will appear consistent even if a render is interrupted by waiting to perform DOM mutations until the end, once the entire tree has been evaluated. This allows React to prepare new screens in the background without blocking the main thread.
Suspense with concurrent rendering
Suspense in React 18 works best when combined with the transition API. If you suspend during a transition, React will prevent already-visible content from being replaced by a fallback. Instead, React will delay the render until enough data has loaded to prevent a bad loading state.
New rendering behavior in React 18 is opt-in
The new concurrent rendering behavior in React 18 is only enabled in the parts of your app that use new features. Existing components work without changes when upgraded to React 18 if they do not use concurrent features.
Layout Effects with Suspense changes
When a tree re-suspends and reverts to a fallback in React 18, React now cleans up layout effects and re-creates them when the content inside the Suspense boundary is shown again. This fixes issues preventing component libraries from correctly measuring layout when used with Suspense.
React 18 browser requirements
React 18 depends on modern browser features including Promise, Symbol, and Object.assign. If supporting older browsers like Internet Explorer that lack these features or have non-compliant implementations, include a global polyfill in the bundled application.
act warnings are opt-in in React 18
In React 18, warnings about act are now opt-in for testing. They can be useful for unit tests but are unnecessary for end-to-end tests. This is controlled through the globalThis.IS_REACT_ACT_ENVIRONMENT flag.
globalThis.IS_REACT_ACT_ENVIRONMENT for testing
When using createRoot in tests, set globalThis.IS_REACT_ACT_ENVIRONMENT = true in your test setup file to configure the testing environment. This tells React it's running in a unit test-like environment and allows React to log helpful warnings if you forget to wrap updates with act.
Suspense tree consistency in React 18
If a component suspends before it's fully added to the tree in React 18, React will not add it in an incomplete state or fire its effects. Instead, React throws away the new tree completely, waits for the asynchronous operation to finish, then retries rendering from scratch, rendering the retry attempt concurrently without blocking the browser.
Internet Explorer support dropped in React 18
React 18 drops support for Internet Explorer. This is because new features in React 18 are built using modern browser features such as microtasks which cannot be adequately polyfilled in IE. If you need to support Internet Explorer, stay with React 17.
Target audience for Canary releases
Most people using React outside a curated setup like a framework should continue using Stable releases. Framework authors are the primary target for Canary adoption, as they can bundle a pinned Canary version of React and update it at their own pace, allowing them to ship individual completed React features and bugfixes earlier than the global React release schedule.
React Canary release channel purpose and support level
React Canaries are an officially supported release channel that lets the community adopt individual new React features before they are released in a stable version. Unlike the Experimental channel, Canaries only include features that are reasonably believed to be ready for adoption. Because Canaries are officially supported, regressions are treated with similar urgency to bugs in stable releases.
React feature development stages
React features typically go through five development stages: (1) initial version is developed with experimental_ or unstable_ prefix, available only in experimental channel; (2) teams at Meta test and provide feedback; (3) when stable, prefix is removed and feature is available on main branch that Meta products use; (4) an RFC is posted when building confidence in the direction; (5) documentation is written and feature is released in stable React release.
Why minor releases cannot always deliver new features
New features sometimes are interconnected with other features still being actively iterated on. They cannot be released separately because implementations are related and they affect the same packages like react and react-dom. Releasing them separately would require major version releases per semver, which is not feasible during active iteration.
Canary releases vs Experimental releases
Experimental releases can undergo significant breaking changes on their way to stabilization or can be removed entirely, making them unsuitable for production use. Canaries are recommended for production use in curated setups like frameworks because they represent the closest code to what Meta runs internally and are relatively stable. Both require pinning the exact version, but Canaries will have breaking changes announced on the React blog.
Canary release announcement policy
Breaking changes and significant new features are announced as they land in Canary releases, not only at the end of the release cycle like stable releases. This includes documentation marking APIs that are only available in Canaries with a special note on documentation pages. Blog posts with codemods and migration instructions are written when breaking changes are merged.
Canary versions must be pinned
When adopting Canary releases, the exact version of the Canary must always be pinned. Canaries are pre-releases that may still include breaking changes, so manual version pinning is required.
Stable React releases unchanged
No changes are being introduced to stable React releases. React continues to follow semver for every Stable release as always.
Library testing against Canary releases
Library authors are encouraged to run tests against both the latest Stable and latest Canary versions of React, though testing every single Canary release is not expected. If behavior changes are observed that were not announced, bugs should be filed in the React repository so regressions can be diagnosed early.
React 19 improves Suspense fallback timing
In React 19, when a component suspends, React immediately commits the fallback of the nearest Suspense boundary without waiting for the entire sibling tree to render. After the fallback commits, React schedules another render for the suspended siblings to pre-warm lazy requests.