For over a year, the React team has been working to implement asynchronous rendering. Last month during his talk at JSConf Iceland, Dan unveiled some of the exciting new possibilities async rendering unlocks. Now we’d like to share with you some of the lessons we’ve learned while working on these features, and some recipes to help prepare your components for async rendering when it launches.
\nOne of the biggest lessons we’ve learned is that some of our legacy component lifecycles tend to encourage unsafe coding practices. They are:
\ncomponentWillMountcomponentWillReceivePropscomponentWillUpdateThese lifecycle methods have often been misunderstood and subtly misused; furthermore, we anticipate that their potential misuse may be more problematic with async rendering. Because of this, we will be adding an “UNSAFE_” prefix to these lifecycles in an upcoming release. (Here, “unsafe” refers not to security but instead conveys that code using these lifecycles will be more likely to have bugs in future versions of React, especially once async rendering is enabled.)
\nReact follows semantic versioning, so this change will be gradual. Our current plan is:
\nUNSAFE_componentWillMount, UNSAFE_componentWillReceiveProps, and UNSAFE_componentWillUpdate. (Both the old lifecycle names and the new aliases will work in this release.)componentWillMount, componentWillReceiveProps, and componentWillUpdate. (Both the old lifecycle names and the new aliases will work in this release, but the old names will log a DEV-mode warning.)componentWillMount, componentWillReceiveProps, and componentWillUpdate . (Only the new “UNSAFE_” lifecycle names will work from this point forward.)Note that if you’re a React application developer, you don’t have to do anything about the legacy methods yet. The primary purpose of the upcoming version 16.3 release is to enable open source project maintainers to update their libraries in advance of any deprecation warnings. Those warnings will not be enabled until a future 16.x release.
\nWe maintain over 50,000 React components at Facebook, and we don’t plan to rewrite them all immediately. We understand that migrations take time. We will take the gradual migration path along with everyone in the React community.
\nIf you don’t have the time to migrate or test these components, we recommend running a “codemod” script that renames them automatically:
\ncd your_project\nnpx react-codemod rename-unsafe-lifecyclesLearn more about this codemod on the 16.9.0 release post.
\nIf you’d like to start using the new component APIs introduced in React 16.3 (or if you’re a maintainer looking to update your library in advance) here are a few examples that we hope will help you to start thinking about components a bit differently. Over time, we plan to add additional “recipes” to our documentation that show how to perform common tasks in a way that avoids the problematic lifecycles.
\nBefore we begin, here’s a quick overview of the lifecycle changes planned for version 16.3:
\nUNSAFE_componentWillMount, UNSAFE_componentWillReceiveProps, and UNSAFE_componentWillUpdate. (Both the old lifecycle names and the new aliases will be supported.)getDerivedStateFromProps and getSnapshotBeforeUpdate.getDerivedStateFromProps class Example extends React.Component {\n static getDerivedStateFromProps(props, state) {\n // ...\n }\n}The new static getDerivedStateFromProps lifecycle is invoked after a component is instantiated as well as before it is re-rendered. It can return an object to update state, or null to indicate that the new props do not require any state updates.
Together with componentDidUpdate, this new lifecycle should cover all use cases for the legacy componentWillReceiveProps.
\n\nNote:
\nBoth the older
\ncomponentWillReceivePropsand the newgetDerivedStateFromPropsmethods add significant complexity to components. This often leads to bugs. Consider simpler alternatives to derived state to make components predictable and maintainable.
getSnapshotBeforeUpdate class Example extends React.Component {\n getSnapshotBeforeUpdate(prevProps, prevState) {\n // ...\n }\n}The new getSnapshotBeforeUpdate lifecycle is called right before mutations are made (e.g. before the DOM is updated). The return value for this lifecycle will be passed as the third parameter to componentDidUpdate. (This lifecycle isn’t often needed, but can be useful in cases like manually preserving scroll position during rerenders.)
Together with componentDidUpdate, this new lifecycle should cover all use cases for the legacy componentWillUpdate.
You can find their type signatures in this gist.
\nWe’ll look at examples of how both of these lifecycles can be used below.
\nstate based on props\n\nNote
\nFor brevity, the examples below are written using the experimental class properties transform, but the same migration strategies apply without it.
\n
This example shows a component with setState calls inside of componentWillMount:\n
// Before\nclass ExampleComponent extends React.Component {\n state = {};\n\n componentWillMount() { this.setState({ currentColor: this.props.defaultColor, palette: 'rgb', }); }}The simplest refactor for this type of component is to move state initialization to the constructor or to a property initializer, like so:\n
// After\nclass ExampleComponent extends React.Component {\n state = { currentColor: this.props.defaultColor, palette: 'rgb', };}Here is an example of a component that uses componentWillMount to fetch external data:\n
// Before\nclass ExampleComponent extends React.Component {\n state = {\n externalData: null,\n };\n\n componentWillMount() { this._asyncRequest = loadMyAsyncData().then( externalData => { this._asyncRequest = null; this.setState({externalData}); } ); }\n componentWillUnmount() {\n if (this._asyncRequest) {\n this._asyncRequest.cancel();\n }\n }\n\n render() {\n if (this.state.externalData === null) {\n // Render loading state ...\n } else {\n // Render real UI ...\n }\n }\n}The above code is problematic for both server rendering (where the external data won’t be used) and the upcoming async rendering mode (where the request might be initiated multiple times).
\nThe recommended upgrade path for most use cases is to move data-fetching into componentDidMount:\n
// After\nclass ExampleComponent extends React.Component {\n state = {\n externalData: null,\n };\n\n componentDidMount() { this._asyncRequest = loadMyAsyncData().then( externalData => { this._asyncRequest = null; this.setState({externalData}); } ); }\n componentWillUnmount() {\n if (this._asyncRequest) {\n this._asyncRequest.cancel();\n }\n }\n\n render() {\n if (this.state.externalData === null) {\n // Render loading state ...\n } else {\n // Render real UI ...\n }\n }\n}There is a common misconception that fetching in componentWillMount lets you avoid the first empty rendering state. In practice this was never true because React has always executed render immediately after componentWillMount. If the data is not available by the time componentWillMount fires, the first render will still show a loading state regardless of where you initiate the fetch. This is why moving the fetch to componentDidMount has no perceptible effect in the vast majority of cases.
\n\nNote
\nSome advanced use-cases (e.g. libraries like Relay) may want to experiment with eagerly prefetching async data. An example of how this can be done is available here.
\nIn the longer term, the canonical way to fetch data in React components will likely be based on the “suspense” API introduced at JSConf Iceland. Both simple data fetching solutions and libraries like Apollo and Relay will be able to use it under the hood. It is significantly less verbose than either of the above solutions, but will not be finalized in time for the 16.3 release.
\nWhen supporting server rendering, it’s currently necessary to provide the data synchronously –
\ncomponentWillMountwas often used for this purpose but the constructor can be used as a replacement. The upcoming suspense APIs will make async data fetching cleanly possible for both client and server rendering.
Here is an example of a component that subscribes to an external event dispatcher when mounting:\n
// Before\nclass ExampleComponent extends React.Component {\n componentWillMount() { this.setState({ subscribedValue: this.props.dataSource.value, }); // This is not safe; it can leak! this.props.dataSource.subscribe( this.handleSubscriptionChange ); }\n componentWillUnmount() {\n this.props.dataSource.unsubscribe(\n this.handleSubscriptionChange\n );\n }\n\n handleSubscriptionChange = dataSource => {\n this.setState({\n subscribedValue: dataSource.value,\n });\n };\n}Unfortunately, this can cause memory leaks for server rendering (where componentWillUnmount will never be called) and async rendering (where rendering might be interrupted before it completes, causing componentWillUnmount not to be called).
People often assume that componentWillMount and componentWillUnmount are always paired, but that is not guaranteed. Only once componentDidMount has been called does React guarantee that componentWillUnmount will later be called for clean up.
For this reason, the recommended way to add listeners/subscriptions is to use the componentDidMount lifecycle:\n
// After\nclass ExampleComponent extends React.Component {\n state = { subscribedValue: this.props.dataSource.value, }; componentDidMount() { // Event listeners are only safe to add after mount, // So they won't leak if mount is interrupted or errors. this.props.dataSource.subscribe( this.handleSubscriptionChange ); // External values could change between render and mount, // In some cases it may be important to handle this case. if ( this.state.subscribedValue !== this.props.dataSource.value ) { this.setState({ subscribedValue: this.props.dataSource.value, }); } }\n componentWillUnmount() {\n this.props.dataSource.unsubscribe(\n this.handleSubscriptionChange\n );\n }\n\n handleSubscriptionChange = dataSource => {\n this.setState({\n subscribedValue: dataSource.value,\n });\n };\n}Sometimes it is important to update subscriptions in response to property changes. If you’re using a library like Redux or MobX, the library’s container component should handle this for you. For application authors, we’ve created a small library, create-subscription, to help with this. We’ll publish it along with React 16.3.
Rather than passing a subscribable dataSource prop as we did in the example above, we could use create-subscription to pass in the subscribed value:
import {createSubscription} from 'create-subscription';\n\nconst Subscription = createSubscription({\n getCurrentValue(sourceProp) {\n // Return the current value of the subscription (sourceProp).\n return sourceProp.value;\n },\n\n subscribe(sourceProp, callback) {\n function handleSubscriptionChange() {\n callback(sourceProp.value);\n }\n\n // Subscribe (e.g. add an event listener) to the subscription (sourceProp).\n // Call callback(newValue) whenever a subscription changes.\n sourceProp.subscribe(handleSubscriptionChange);\n\n // Return an unsubscribe method.\n return function unsubscribe() {\n sourceProp.unsubscribe(handleSubscriptionChange);\n };\n },\n});\n\n// Rather than passing the subscribable source to our ExampleComponent,\n// We could just pass the subscribed value directly:\n<Subscription source={dataSource}>\n {value => <ExampleComponent subscribedValue={value} />}\n</Subscription>;\n\nNote
\nLibraries like Relay/Apollo should manage subscriptions manually with the same techniques as
\ncreate-subscriptionuses under the hood (as referenced here) in a way that is most optimized for their library usage.
state based on props \n\nNote:
\nBoth the older
\ncomponentWillReceivePropsand the newgetDerivedStateFromPropsmethods add significant complexity to components. This often leads to bugs. Consider simpler alternatives to derived state to make components predictable and maintainable.
Here is an example of a component that uses the legacy componentWillReceiveProps lifecycle to update state based on new props values:\n
// Before\nclass ExampleComponent extends React.Component {\n state = {\n isScrollingDown: false,\n };\n\n componentWillReceiveProps(nextProps) { if (this.props.currentRow !== nextProps.currentRow) { this.setState({ isScrollingDown: nextProps.currentRow > this.props.currentRow, }); } }}Although the above code is not problematic in itself, the componentWillReceiveProps lifecycle is often mis-used in ways that do present problems. Because of this, the method will be deprecated.
As of version 16.3, the recommended way to update state in response to props changes is with the new static getDerivedStateFromProps lifecycle. It is called when a component is created and each time it re-renders due to changes to props or state:\n
// After\nclass ExampleComponent extends React.Component {\n // Initialize state in constructor,\n // Or with a property initializer.\n state = { isScrollingDown: false, lastRow: null, };\n static getDerivedStateFromProps(props, state) { if (props.currentRow !== state.lastRow) { return { isScrollingDown: props.currentRow > state.lastRow, lastRow: props.currentRow, }; }\n // Return null to indicate no change to state.\n return null;\n }\n}You may notice in the example above that props.currentRow is mirrored in state (as state.lastRow). This enables getDerivedStateFromProps to access the previous props value in the same way as is done in componentWillReceiveProps.
You may wonder why we don’t just pass previous props as a parameter to getDerivedStateFromProps. We considered this option when designing the API, but ultimately decided against it for two reasons:
prevProps parameter would be null the first time getDerivedStateFromProps was called (after instantiation), requiring an if-not-null check to be added any time prevProps was accessed.props object in memory.)\n\nNote
\nIf you’re writing a shared component, the
\nreact-lifecycles-compatpolyfill enables the newgetDerivedStateFromPropslifecycle to be used with older versions of React as well. Learn more about how to use it below.
Here is an example of a component that calls an external function when its internal state changes:\n
// Before\nclass ExampleComponent extends React.Component {\n componentWillUpdate(nextProps, nextState) { if ( this.state.someStatefulValue !== nextState.someStatefulValue ) { nextProps.onChange(nextState.someStatefulValue); } }}Sometimes people use componentWillUpdate out of a misplaced fear that by the time componentDidUpdate fires, it is “too late” to update the state of other components. This is not the case. React ensures that any setState calls that happen during componentDidMount and componentDidUpdate are flushed before the user sees the updated UI. In general, it is better to avoid cascading updates like this, but in some cases they are necessary (for example, if you need to position a tooltip after measuring the rendered DOM element).
Either way, it is unsafe to use componentWillUpdate for this purpose in async mode, because the external callback might get called multiple times for a single update. Instead, the componentDidUpdate lifecycle should be used since it is guaranteed to be invoked only once per update:\n
// After\nclass ExampleComponent extends React.Component {\n componentDidUpdate(prevProps, prevState) { if ( this.state.someStatefulValue !== prevState.someStatefulValue ) { this.props.onChange(this.state.someStatefulValue); } }}Similar to the example above, sometimes components have side effects when props change.
// Before\nclass ExampleComponent extends React.Component {\n componentWillReceiveProps(nextProps) { if (this.props.isVisible !== nextProps.isVisible) { logVisibleChange(nextProps.isVisible); } }}Like componentWillUpdate, componentWillReceiveProps might get called multiple times for a single update. For this reason it is important to avoid putting side effects in this method. Instead, componentDidUpdate should be used since it is guaranteed to be invoked only once per update:
// After\nclass ExampleComponent extends React.Component {\n componentDidUpdate(prevProps, prevState) { if (this.props.isVisible !== prevProps.isVisible) { logVisibleChange(this.props.isVisible); } }}props change Here is an example of a component that fetches external data based on props values:\n
// Before\nclass ExampleComponent extends React.Component {\n state = {\n externalData: null,\n };\n\n componentDidMount() {\n this._loadAsyncData(this.props.id);\n }\n\n componentWillReceiveProps(nextProps) { if (nextProps.id !== this.props.id) { this.setState({externalData: null}); this._loadAsyncData(nextProps.id); } }\n componentWillUnmount() {\n if (this._asyncRequest) {\n this._asyncRequest.cancel();\n }\n }\n\n render() {\n if (this.state.externalData === null) {\n // Render loading state ...\n } else {\n // Render real UI ...\n }\n }\n\n _loadAsyncData(id) {\n this._asyncRequest = loadMyAsyncData(id).then(\n externalData => {\n this._asyncRequest = null;\n this.setState({externalData});\n }\n );\n }\n}The recommended upgrade path for this component is to move data updates into componentDidUpdate. You can also use the new getDerivedStateFromProps lifecycle to clear stale data before rendering the new props:\n
// After\nclass ExampleComponent extends React.Component {\n state = {\n externalData: null,\n };\n\n static getDerivedStateFromProps(props, state) { // Store prevId in state so we can compare when props change. // Clear out previously-loaded data (so we don't render stale stuff). if (props.id !== state.prevId) { return { externalData: null, prevId: props.id, }; } // No state update necessary return null; }\n componentDidMount() {\n this._loadAsyncData(this.props.id);\n }\n\n componentDidUpdate(prevProps, prevState) { if (this.state.externalData === null) { this._loadAsyncData(this.props.id); } }\n componentWillUnmount() {\n if (this._asyncRequest) {\n this._asyncRequest.cancel();\n }\n }\n\n render() {\n if (this.state.externalData === null) {\n // Render loading state ...\n } else {\n // Render real UI ...\n }\n }\n\n _loadAsyncData(id) {\n this._asyncRequest = loadMyAsyncData(id).then(\n externalData => {\n this._asyncRequest = null;\n this.setState({externalData});\n }\n );\n }\n}\n\nNote
\nIf you’re using an HTTP library that supports cancellation, like axios, then it’s simple to cancel an in-progress request when unmounting. For native Promises, you can use an approach like the one shown here.
\n
Here is an example of a component that reads a property from the DOM before an update in order to maintain scroll position within a list:\n
class ScrollingList extends React.Component {\n listRef = null;\n previousScrollOffset = null;\n\n componentWillUpdate(nextProps, nextState) { // Are we adding new items to the list? // Capture the scroll position so we can adjust scroll later. if (this.props.list.length < nextProps.list.length) { this.previousScrollOffset = this.listRef.scrollHeight - this.listRef.scrollTop; } }\n componentDidUpdate(prevProps, prevState) { // If previousScrollOffset is set, we've just added new items. // Adjust scroll so these new items don't push the old ones out of view. if (this.previousScrollOffset !== null) { this.listRef.scrollTop = this.listRef.scrollHeight - this.previousScrollOffset; this.previousScrollOffset = null; } }\n render() {\n return (\n <div ref={this.setListRef}>\n {/* ...contents... */}\n </div>\n );\n }\n\n setListRef = ref => {\n this.listRef = ref;\n };\n}In the above example, componentWillUpdate is used to read the DOM property. However with async rendering, there may be delays between “render” phase lifecycles (like componentWillUpdate and render) and “commit” phase lifecycles (like componentDidUpdate). If the user does something like resize the window during this time, the scrollHeight value read from componentWillUpdate will be stale.
The solution to this problem is to use the new “commit” phase lifecycle, getSnapshotBeforeUpdate. This method gets called immediately before mutations are made (e.g. before the DOM is updated). It can return a value for React to pass as a parameter to componentDidUpdate, which gets called immediately after mutations.
The two lifecycles can be used together like this:
\nclass ScrollingList extends React.Component {\n listRef = null;\n\n getSnapshotBeforeUpdate(prevProps, prevState) { // Are we adding new items to the list? // Capture the scroll position so we can adjust scroll later. if (prevProps.list.length < this.props.list.length) { return ( this.listRef.scrollHeight - this.listRef.scrollTop ); } return null; }\n componentDidUpdate(prevProps, prevState, snapshot) { // If we have a snapshot value, we've just added new items. // Adjust scroll so these new items don't push the old ones out of view. // (snapshot here is the value returned from getSnapshotBeforeUpdate) if (snapshot !== null) { this.listRef.scrollTop = this.listRef.scrollHeight - snapshot; } }\n\n render() {\n return (\n <div ref={this.setListRef}>\n {/* ...contents... */}\n </div>\n );\n }\n\n setListRef = ref => {\n this.listRef = ref;\n };\n}\n\nNote
\nIf you’re writing a shared component, the
\nreact-lifecycles-compatpolyfill enables the newgetSnapshotBeforeUpdatelifecycle to be used with older versions of React as well. Learn more about how to use it below.
While we tried to cover the most common use cases in this post, we recognize that we might have missed some of them. If you are using componentWillMount, componentWillUpdate, or componentWillReceiveProps in ways that aren’t covered by this blog post, and aren’t sure how to migrate off these legacy lifecycles, please file a new issue against our documentation with your code examples and as much background information as you can provide. We will update this document with new alternative patterns as they come up.
Open source maintainers might be wondering what these changes mean for shared components. If you implement the above suggestions, what happens with components that depend on the new static getDerivedStateFromProps lifecycle? Do you also have to release a new major version and drop compatibility for React 16.2 and older?
Fortunately, you do not!
\nWhen React 16.3 is published, we’ll also publish a new npm package, react-lifecycles-compat. This package polyfills components so that the new getDerivedStateFromProps and getSnapshotBeforeUpdate lifecycles will also work with older versions of React (0.14.9+).
To use this polyfill, first add it as a dependency to your library:
\n# Yarn\nyarn add react-lifecycles-compat\n\n# NPM\nnpm install react-lifecycles-compat --saveNext, update your components to use the new lifecycles (as described above).
\nLastly, use the polyfill to make your component backwards compatible with older versions of React:\n
import React from 'react';\nimport {polyfill} from 'react-lifecycles-compat';\nclass ExampleComponent extends React.Component {\n static getDerivedStateFromProps(props, state) { // Your state update logic here ...\n }\n}\n\n// Polyfill your component to work with older versions of React:\npolyfill(ExampleComponent);\nexport default ExampleComponent;