An update on async rendering #596

bvaughn · 2018-02-06T21:28:24Z

Work in progress...

Formatted "update on async rendering"

TODO before merging

Add a note below the getSnapshotBeforeUpdate example stating explicitly whether the polyfill supports this method.
Update the "Open source project maintainers" section to list support for getSnapshotBeforeUpdate only if we agree to move forward with Polyfill for getSnapshotBeforeUpdate react-lifecycles-compat#1.

reactjs-bot · 2018-02-06T21:31:22Z

Deploy preview for reactjs ready!

Built with commit b824bd2

https://deploy-preview-596--reactjs.netlify.com

wbinnssmith

The usecase-oriented sections are so good! Maybe they could be a part of a "patterns" section -- or similar like the recipes you mention -- in the docs in the future. There's already a lot of good content in the quick start that could belong there too.

wbinnssmith · 2018-02-06T22:07:27Z

content/blog/2018-02-07-update-on-async-rendering.md

+* **16.4**: Enable deprecation warning for `componentWillMount`, `componentWillReceiveProps`, and `componentWillUpdate`. (Both the old lifecycle names and the new aliases will work in this release.)
+* **17.0**: Remove `componentWillMount`, `componentWillReceiveProps`, and `componentWillUpdate` . (Only the new "UNSAFE_" lifecycle names will work in this release.)
+
+In this post, we will explore some of the potential capabilities of async rendering, and we'll outline a migration plan for components that rely on the deprecated lifecycles.


should mention the codemod you added in reactjs/react-codemod#195! 😄

I was uncertain about this, but leaning toward mentioning the codemod along with the release of 16.4. My reasoning is that 16.4 will be when the deprecation warnings are enabled, and the codemod is really only a bandaid fix for those. This release (16.3) is more focused on maintainers who want to fix their projects in the "right" way going forward (which won't be using the codemod, but rather following the recipes). So I thought mentioning it might lead people down the wrong path potentially?

ah yeah I can totally see that. makes sense to me!

wbinnssmith · 2018-02-06T22:09:51Z

content/blog/2018-02-07-update-on-async-rendering.md

+
+We found that asynchronous rendering can help in several ways. For example:
+
+1. As users navigate within an app, newly displayed components often have asynchronous dependencies (including data, images, and code splitting). This can lead to a "cascade of spinners" as the data loads. We'd like to make it easier for product developers to express asynchronous dependencies of components- keeping the old UI "alive" for a certain period while the new UI is not "ready" yet. React could render this new UI in the background and provide a declarative way to show a spinner if it takes more than a second.


provide a declarative way to show a spinner if it takes more than a second.

maybe s/spinner/loading indicator?

wbinnssmith · 2018-02-06T22:11:22Z

content/blog/2018-02-07-update-on-async-rendering.md

+
+1. As users navigate within an app, newly displayed components often have asynchronous dependencies (including data, images, and code splitting). This can lead to a "cascade of spinners" as the data loads. We'd like to make it easier for product developers to express asynchronous dependencies of components- keeping the old UI "alive" for a certain period while the new UI is not "ready" yet. React could render this new UI in the background and provide a declarative way to show a spinner if it takes more than a second.
+2. Fast updates within a short timeframe often cause jank because React processes each update individually. We'd like to automatically "combine" updates within a few hundred milliseconds when possible so that there is less re-rendering.
+3. Some updates are inherently "less important" than others. For example, if you're writing a live-updating search filter input like [this](https://zeit.co/blog/domains-search-web#asynchronous-rendering), it is essential that the input is updated immediately (within a few milliseconds). Re-rendering the result list can be done later, and should not block the thread or cause stutter when typing. It would be nice if React had a way to mark the latter updates as having a "lower priority".


Some updates are inherently "less important" than others.

imo the quotation marks aren't really necessary, though they could be around important, as in less "important"

same re: "lower priority"

Maybe also worth adding

Note that even debouncing the input doesn’t help because if the rendering is synchronous, like in React today, a keystroke can’t interrupt the list rendering if it already started. Asynchronous rendering solves this by splitting rendering into small chunks that can be paused and later restarted.

wbinnssmith · 2018-02-06T22:16:53Z

content/blog/2018-02-07-update-on-async-rendering.md

+Here is an example of a component that subscribes to an external event dispatcher when mounting:
+`embed:update-on-async-rendering/adding-event-listeners-before.js`
+
+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).


this and the lifecycle method is being deprecated 😝

might be worth calling out that there's more symmetry between didMount and willUnmount both taking place while the component is mounted and refs and dom apis are available.

Yeah, I like this way of framing it. I'm a little unsure of the wording, but I'll take a stab at it.

gaearon · 2018-02-06T22:25:17Z

content/blog/2018-02-07-update-on-async-rendering.md

+
+We found that asynchronous rendering can help in several ways. For example:
+
+1. As users navigate within an app, newly displayed components often have asynchronous dependencies (including data, images, and code splitting). This can lead to a "cascade of spinners" as the data loads. We'd like to make it easier for product developers to express asynchronous dependencies of components- keeping the old UI "alive" for a certain period while the new UI is not "ready" yet. React could render this new UI in the background and provide a declarative way to show a spinner if it takes more than a second.


Maybe we can expand a bit. To clarify it’s not only perf oriented, and also why exactly the perf suffers

This leads to a lot of boilerplate code managing data fetching and displaying the loading states. It can also lead to a “cascade of spinners” as the data loads, causing DOM reflows and janky user experience.

gaearon · 2018-02-06T22:32:30Z

content/blog/2018-02-07-update-on-async-rendering.md

+
+## Updating class components
+
+#### If you're an application developer, **you don't have to do anything about the deprecated methods yet**. The primary purpose of this update (v16.3) is to enable OSS maintainers to update their libraries in advance of any deprecation warnings. Those warnings will be enabled with the next minor release, v16.4.


OSS is not universally understood

gaearon · 2018-02-06T23:39:08Z

content/blog/2018-02-07-update-on-async-rendering.md

+
+In this post, we will explore some of the potential capabilities of async rendering, and we'll outline a migration plan for components that rely on the deprecated lifecycles.
+
+## What can Asynchronous Rendering do?


How do you feel about removing capitalization here? I originally capitalized all words but if we don't do this for headers in general, let's just keep "asynchronous rendering" lowercase as well

Agreed. It's kind of arbitrary.

gaearon · 2018-02-06T23:40:45Z

content/blog/2018-02-07-update-on-async-rendering.md

+* `componentWillReceiveProps`
+* `componentWillUpdate`
+
+Because of this, we have decided to rename these lifecycles—(adding an "UNSAFE_" prefix)—in a future release. The plan for this is as follows:


Maybe instead of "The plan ...", "React follows semantic versioning, so the migration path is gradual:"

gaearon · 2018-02-06T23:42:00Z

content/blog/2018-02-07-update-on-async-rendering.md

+* **17.0**: Remove `componentWillMount`, `componentWillReceiveProps`, and `componentWillUpdate` . (Only the new "UNSAFE_" lifecycle names will work in this release.)
+
+In this post, we will explore some of the potential capabilities of async rendering, and we'll outline a migration plan for components that rely on the deprecated lifecycles.
+


Maybe "on the deprecated lifecycles" -> "on these legacy lifecycles". Since they're not technically deprecated yet. Also too many people read "deprecated" as "immediately removed" so I prefer other words when possible.

gaearon · 2018-02-06T23:45:08Z

content/blog/2018-02-07-update-on-async-rendering.md

+
+* **16.3**: Introduce aliases for the unsafe lifecycles, `UNSAFE_componentWillMount`, `UNSAFE_componentWillReceiveProps`, and `UNSAFE_componentWillUpdate`. (Both the old lifecycle names and the new aliases will work in this release.)
+* **16.4**: Enable deprecation warning for `componentWillMount`, `componentWillReceiveProps`, and `componentWillUpdate`. (Both the old lifecycle names and the new aliases will work in this release.)
+* **17.0**: Remove `componentWillMount`, `componentWillReceiveProps`, and `componentWillUpdate` . (Only the new "UNSAFE_" lifecycle names will work in this release.)


Is there any vague sense of timing we could give here?

I'm reluctant to make any predictions on timing.

I could say "within a week or two", "within a month or two", etc. if that would be helpful?

Eh, I guess not. I think the most valuable would be to say 17 is at least X months away but honestly I have no idea

gaearon · 2018-02-06T23:50:15Z

content/blog/2018-02-07-update-on-async-rendering.md

+* `componentWillReceiveProps`
+* `componentWillUpdate`
+
+Because of this, we have decided to rename these lifecycles—(adding an "UNSAFE_" prefix)—in a future release. The plan for this is as follows:


I'm not a native speaker but I find using both dashes and parens together a bit hard to scan. I think that, when possible, we should stick to simple sentence structures that are easily accessible to non-native speakers (note I break this rule way too often myself).

Here is one potential rewording:

Because of this, we are adding an “UNSAFE_” prefix to these lifecycles in a future release. [...]

This is helpful feedback to me. Thanks!

gaearon · 2018-02-07T00:18:29Z

content/blog/2018-02-07-update-on-async-rendering.md

+Here is an example of a component that subscribes to an external event dispatcher when mounting:
+`embed:update-on-async-rendering/adding-event-listeners-before.js`
+
+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).


Nice hammering of the point that most of these patterns are already SSR-unsafe 👍

gaearon · 2018-02-07T00:25:12Z

examples/update-on-async-rendering/updating-state-from-props-before.js

+        derivedData: computeDerivedState(
+          nextProps
+        ),
+      });


My overall feedback on these examples: I see what you are trying to do but I think their vagueness is more distracting than helping. I would vastly prefer a specific example (that also shows when I was supposed to use this pattern in the first place).

For example, before:

state = { isScrollingDown: false, }; componentWillReceiveProps(nextProps) { if (this.props.currentRow === nextProps.currentRow) { return; } this.setState({ isScrollingDown: nextProps.currentRow > this.props.currentRow }); }

After:

state = {}; static getDerivedStateFromProps(nextProps, prevState) { if (nextProps.currentRow === prevState.lastRow) { return null; } return { lastRow: nextProps.currentRow, isScrollingDown: nextProps.currentRow > prevState.lastRow }; }

Too vague. Gotcha. I like it.

gaearon · 2018-02-07T00:26:13Z

examples/update-on-async-rendering/updating-state-from-props-after.js

+        derivedData: computeDerivedState(
+          nextProps
+        ),
+        someMirroredValue:


I think especially here this is getting so abstract it's hard to see what's going on. (What is mirroring? what is derived? what you put where and why?)

gaearon · 2018-02-07T00:32:18Z

content/blog/2018-02-07-update-on-async-rendering.md

+
+This would not be safe to do 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:
+`embed:update-on-async-rendering/invoking-external-callbacks-after.js`
+


I'd add:

Sometimes people use componentWillUpdate out of a misplaced fear that by the time componentDidUpdate fires, it is "too late" to update 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 unavoidable (for example, if you need to position a tooltip after measuring the rendered DOM element).

I like this clarification.

Side note: I wonder how async will impact this. I think it will be important to at least have the option of doing a sync setState flush (for components like RV that require the ability to measure the DOM before doing a meaningful initial render).

I think the idea is that even in async, setState during commit is sync? At least that's how it works now AFAIK.

gaearon · 2018-02-07T00:38:06Z

content/blog/2018-02-07-update-on-async-rendering.md

+This would not be safe to do 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:
+`embed:update-on-async-rendering/invoking-external-callbacks-after.js`
+
+## Open source project maintainers


I'd add a section before this one. Something like

Other scenarios

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.

gaearon · 2018-02-07T08:05:55Z

content/blog/2018-02-07-update-on-async-rendering.md

+
+We found that asynchronous rendering can help in several ways. For example:
+
+1. As users navigate within an app, newly displayed components often have asynchronous dependencies (including data, images, and code splitting). This leads to a lot of boilerplate code managing data fetching and displaying the loading states. It can also lead to a "cascade of spinners" as the data loads, causing DOM reflows and janky user experience. We'd like to make it easier for product developers to express asynchronous dependencies of components- keeping the old UI "alive" for a certain period while the new UI is not "ready" yet. React could render this new UI in the background and provide a declarative way to show a loading indicator if it takes more than a second.


Nit: should - before "keeping" be an em dash?

Suggestion:

We'd like to make it easier for product developers to express asynchronous dependencies of components. React could keep the old UI "alive" and interactive for a certain period while the updated UI is not ready yet, and provide a declarative way to show a loading indicator if it takes more than a second.

Yes, probably. My Sublime font renders em dashes and hyphens the same, so I don't notice. I should probably fix this.

gaearon · 2018-02-07T08:13:08Z

examples/update-on-async-rendering/updating-state-from-props-after.js

+        isScrollingDown:
+          nextProps.currentRow >
+          prevState.lastRow,
+      };


Very aggressive line breaks make this hard to read. Could we increase the allowed width just a tiny bit?

Yeah, man I feel the same about this. I set the line widths I did for Prettier because of mobile layout, but it really makes the desktop layout suffer in cases like this.

I'll play with it a bit to see if I can't find a better solution (maybe smaller font on smaller screens to offset the extra characters a bit).

I think that's probably best done as a follow-up. Even though we don't have many examples, changing the Prettier width affects most of them (which also impacts their relative line highlights).

Maybe I can do it as a stacked PR, on top of this one.

Can't we apply this on master once, and later reapply on top of this PR?

Yeah I mean, I guess we could. It's probably fine though?

Whatever you prefer :-) I generally prefer doing unrelated changes separately so that they don't depend on each other. This way your final blog post PR won't have to touch every single example. But it's up to you really.

The Prettier change only took a minute to do. I just wanted to make sure we were both happy with the resulting impact on mobile. Since it impacted this PR's contents way more than master, I did it on top of this PR.

When I actually merge it, maybe I'll do it directly on master and rebase. I dunno. At the moment, I'm just concerned about getting the content of this PR right. 😄

gaearon · 2018-02-07T08:27:53Z

examples/update-on-async-rendering/initializing-state-before.js

+  // highlight-range{1-6}
+  componentWillMount() {
+    this.setState({
+      isScrollingDown: false,


I was using the relationship between props.isScrollingDown and props.currentRow in the other example specifically to explain what “derived state” means.

I think using the same names here makes that example less useful. This particular example also doesn’t quite make sense (why would the “last” row be equal to the current row in props?)

I propose each example be different and show a plausible pattern. For example this was one could just be

this.setState({ currentColor: this.props.defaultColor, palette: 'rgb' });

bvaughn · 2018-02-07T17:23:43Z

Merged PR #600 into this branch after rebasing both on master.

Edit: Looks like Netlify has a cashing issue with some of the examples in the latest deploy. Rebuilding (without cache) locally shows the correct, wider line widths.

Edit 2: Pushed an empty commit to restart Netlify and that fixed it.

gaearon · 2018-02-07T20:17:31Z

content/blog/2018-02-07-strict-mode.md

@@ -0,0 +1,69 @@
+---
+title: Strict mode


Nit: Strict Mode to be consistent with blog post title capitalization elsewhere

gaearon · 2018-03-24T17:28:01Z

content/blog/2018-03-15-update-on-async-rendering.md

+
+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](/blog/2018/03/01/sneak-peek-beyond-react-16.html). Now we'd like to share with you some of the lessons we've learned while working on this feature, and some suggestions we have for preparing your components to be ready for async rendering when it launches.
+
+One of the biggest lesson we've learned is that some of our legacy component lifecycles tend to encourage unsafe coding practices. They are:


I proof read this several times 😭

markerikson · 2018-03-24T17:49:47Z

content/blog/2018-03-15-update-on-async-rendering.md

@@ -35,9 +35,9 @@ Before we begin, here's a quick overview of the lifecycle changes planned for ve

 `embed:update-on-async-rendering/new-lifecycles-overview.js`

-The new static `getSnapshotBeforeUpdate` lifecycle is invoked after a component is instantiated as well as when it receives new props. It should return an object to update `state`, or `null` to indicate that the new `props` do not require any `state` updates.
+The new static `getSnapshotBeforeUpdate` lifecycle is invoked after a component is instantiated as well as when it receives new props. It can return an object to update `state`, or `null` to indicate that the new `props` do not require any `state` updates.


Real stupid question: shouldn't this line be getDerivedStateFromProps ?

Yes, thanks!

gaearon · 2018-03-24T18:13:01Z

Suggesting some structural tweaks to the first sections: bvaughn#6

gaearon · 2018-03-24T18:25:34Z

content/blog/2018-03-15-update-on-async-rendering.md

+`embed:update-on-async-rendering/adding-event-listeners-after.js`
+
+> Note
+>


Instead of these notes, should we just plug create-subscription and then show an equivalent example with it?

Yeah. I think that's a reasonable change.

I took a stab at this. Let me know what you think?

It's a little awkward since create-subscription won't be released to NPM (and thus won't have a README) until we publish 16.3- so I had to link to the GitHub folder.

I also know there's some concern about over-promoting this package, since there are better solutions for some cases.

Tweaks to async post

gaearon · 2018-03-25T01:42:17Z

content/blog/2018-03-15-update-on-async-rendering.md

+
+> Note
+>
+> Although the pattern above is slightly more verbose, it has an added benefit of deferring the subscription creation until after the component has rendered, reducing the amount of time in the critical render path. In the near future, React may include more tools to reduce code complexity for data fetching cases like this.


it has an added benefit of deferring the subscription creation until after the component has rendered, reducing the amount of time in the critical render path

I don't understand this setence. It seems to imply that componentDidMount doesn't block the initial render (which isn't true, and which I've observed to be a common misconception).

Hm. Yeah, that's a good point. I'm not sure why I added that note. 😄

gaearon · 2018-03-25T01:44:11Z

content/blog/2018-03-15-update-on-async-rendering.md

+Here is an example of a component that uses the legacy `componentWillReceiveProps` lifecycle to update `state` based on new `props` values:
+`embed:update-on-async-rendering/updating-state-from-props-before.js`
+
+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 has been deprecated.


It hasn't been deprecated yet.

gaearon · 2018-03-25T01:45:18Z

content/blog/2018-03-15-update-on-async-rendering.md

+
+> Note
+>
+> The [`react-lifecycles-compat`](https://github.com/reactjs/react-lifecycles-compat) polyfill enables this new lifecycle to be used with older versions of React as well. [Learn more about how to use it below.](http://localhost:8000/blog/2018/02/07/update-on-async-rendering.html#open-source-project-maintainers)


Maybe we could be more explicit in this note that this only applies to library authors. Even though we already said it at the top I still anticipate people thinking they need to apply polyfill() in the application code.

gaearon · 2018-03-27T18:20:21Z

content/blog/2018-03-27-update-on-async-rendering.md

@@ -23,7 +23,7 @@ These lifecycle methods have often been misunderstood and subtly misused; furthe

 **Note that if you're an 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.**

-At Facebook, we maintain over 50,000 React components, so we're in the same boat as you. We can't rewrite our apps so we will take the gradual migration path together with everyone in the React community.
+We maintain over 50,000 React components at Facebook, so we understand that migrations take time. We will take the gradual migration path together with everyone in the React community.


I think it's important to point out our migration path isn't "tell every product team to set everything aside and start fixing their components". People commonly assume that we have this kind of power at Facebook and that product teams just go ahead and spend months catching up with our recommendations (and a "small company wouldn't be able to do this"). So I would prefer if we were very clear in our wording that this is not the case.

Hm. Gotcha.

I don't think the previous wording, "we can't rewrite our apps", conveyed that. (It didn't really make sense to me.)

Sure—you're a native speaker so I was just trying to give you the context into what I was trying to express.

Sorry, I wasn't trying to criticize the wording or say it didn't sound native. I just don't think it conveyed the meaning you are wanting to convey.

How about:

We 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.

Nice, I like it

sophiebits

lgtm

sophiebits · 2018-03-27T20:43:16Z

content/blog/2018-03-27-update-on-async-rendering.md

+* `componentWillReceiveProps`
+* `componentWillUpdate`
+
+These 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.


Add:

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.

sophiebits · 2018-03-27T20:44:05Z

content/blog/2018-03-27-update-on-async-rendering.md

+[React follows semantic versioning](/blog/2016/02/19/new-versioning-scheme.html), so this change will be gradual. Our current plan is:
+
+* **16.3**: Introduce aliases for the unsafe lifecycles, `UNSAFE_componentWillMount`, `UNSAFE_componentWillReceiveProps`, and `UNSAFE_componentWillUpdate`. (Both the old lifecycle names and the new aliases will work in this release.)
+* **16.x**: Enable deprecation warning for `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.)


This might be clearer as "A future 16.x release after 16.3". I kinda read this as meaning that all 16.x are problematic.

sophiebits · 2018-03-27T20:46:51Z

examples/update-on-async-rendering/adding-event-listeners-create-subscription.js

+const Subscription = createSubscription({
+  getCurrentValue(sourceProp) {
+    // Return the current value of the subscription (sourceProp).
+    // highlight-next-line


IMO the highlighting in this code sample is distracting and I can't tell why some lines are highlighted and not others. I'd just drop all the highlights in this file especially since it isn't really a before/after and ~all the lines are significant.

Cool. I was on the fence about this to begin with.

sophiebits · 2018-03-27T20:48:08Z

examples/update-on-async-rendering/react-dom-properties-before-update-before.js

@@ -0,0 +1,36 @@
+class ScrollingList extends React.Component {
+  listRef = null;
+  prevScrollHeight = null;


nit: can we do previousScrollHeight?

sophiebits · 2018-03-27T20:49:08Z

examples/update-on-async-rendering/react-dom-properties-before-update-after.js

+
+  // highlight-range{1-8}
+  componentDidUpdate(prevProps, prevState, snapshot) {
+    // If we have a snapshot value, we've just added new items.


Maybe add a comment:

// snapshot here will be the value returned from getSnapshotBeforeUpdate.

sophiebits · 2018-03-27T20:50:36Z

content/blog/2018-03-27-update-on-async-rendering.md

+
+Fortunately, you do not!
+
+In support of version 16.3, we've also created a new NPM package, [`react-lifecycles-compat`](https://github.com/reactjs/react-lifecycles-compat). This package polyfills components so that the new `getDerivedStateFromProps` lifecycle will also work with older versions of React (0.14.9+).


Maybe: "When React 16.3 is published, we'll also publish a new npm package," since people aren't meant to use it yet?

(also npm should be lowercase https://css-tricks.com/start-sentence-npm/)

Oh. I didn't know that (NPM vs npm)

sophiebits · 2018-03-27T20:52:05Z

content/blog/2018-03-27-update-on-async-rendering.md

+For this reason, the recommended way to add listeners/subscriptions is to use the `componentDidMount` lifecycle:
+`embed:update-on-async-rendering/adding-event-listeners-after.js`
+
+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`](https://github.com/facebook/react/tree/master/packages/create-subscription), to help with this.


"For application authors, we'll created a small library [create-subscription] to help with this and will publish it with React 16.3."

sophiebits · 2018-03-27T20:54:00Z

content/blog/2018-03-27-update-on-async-rendering.md

+
+### New lifecycle: `getSnapshotBeforeUpdate`
+
+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`.


Maybe add: "This lifecycle method usually isn't necessary but is useful in cases like manually preserving scroll position during rerenders." (I'm worried that people will either overuse this or get confused because they can't imagine use cases; I think downplaying it slightly like this will help.)

bvaughn · 2018-03-27T21:06:48Z

Thanks Sophie!

bvaughn · 2018-03-27T21:34:39Z

A big thank you to everyone who proof read this and shared feedback! ❤️

feat: Sync with reactjs.org @ 4133943 Sync with reactjs.org @ 4133943

facebook-github-bot added the CLA Signed label Feb 6, 2018

bvaughn changed the title ~~[WIP] An update on async rendering~~ An update on async rendering Feb 6, 2018

wbinnssmith reviewed Feb 6, 2018

View reviewed changes

gaearon reviewed Feb 6, 2018

View reviewed changes

gaearon reviewed Feb 7, 2018

View reviewed changes

bvaughn mentioned this pull request Feb 7, 2018

Increase Prettier line-width for example JS #600

Closed

bvaughn added 13 commits February 7, 2018 09:21

Migrated async update from Quip to Markdown

544c0bc

Wordsmithing

e298b47

Split StrictMode into its own top level docs page

9ff0f12

Added string ref section to strict mode page

0674c34

Added TOC header links to Strict Mode page

cdb4b9e

Prettier

289a2da

Wording changes in response to PR feedback

99fedea

Removed some unnecessary parens

49464f7

Add Dan as an author to "Update on Async"

fe6b133

Wording improvements in response to Dan's feedback

1314117

Wordsmithing

f005c04

Prettier

06d5be4

Increased Prettier line-width for examples

3696388

bvaughn force-pushed the update-on-async-rendering branch from b8213fb to 3696388 Compare February 7, 2018 17:23

Trigger Netlify rebuild

ac23b1f

gaearon reviewed Feb 7, 2018

View reviewed changes

bvaughn added 2 commits February 7, 2018 12:22

Strict Mode blog title capitalization

5cae7c6

Minor wordsmithing

f70c0dd

gaearon reviewed Mar 24, 2018

View reviewed changes

Typofix

7425aed

markerikson reviewed Mar 24, 2018

View reviewed changes

bvaughn and others added 2 commits March 24, 2018 11:00

Typo

65b1496

Tweaks to async post

6eae811

Add a note about suspense

a2139de

gaearon reviewed Mar 24, 2018

View reviewed changes

bvaughn added 4 commits March 24, 2018 15:45

Merge pull request #6 from gaearon/tweaks-async-post

030980e

Tweaks to async post

Added a small TOC for examples

e110ac5

Imported theme style tweaks from PR 587

ce060eb

Added create-subscription example

e143823

gaearon reviewed Mar 25, 2018

View reviewed changes

bvaughn added 4 commits March 24, 2018 21:44

Tweaks

65eca09

Merge branch 'master' into update-on-async-rendering

a3ea63a

Renamed blog post

7ced9ce

Wordsmithing

7cf5b58

gaearon reviewed Mar 27, 2018

View reviewed changes

bvaughn added 2 commits March 27, 2018 12:51

Updated gradual migration note

9f72403

Changed wording about app developer to React app developer

712f4de

sophiebits approved these changes Mar 27, 2018

View reviewed changes

Changes in response to Sophie's feedback

4610392

Added getSnapshotBeforeUpdate to the polyfill notes

b824bd2

bvaughn merged commit 3832311 into reactjs:master Mar 27, 2018

bvaughn deleted the update-on-async-rendering branch March 27, 2018 21:34

BetterZxx pushed a commit to BetterZxx/react.dev that referenced this pull request Mar 21, 2023

Merge pull request reactjs#596 from reactjs/sync-4133943e

4791829

feat: Sync with reactjs.org @ 4133943 Sync with reactjs.org @ 4133943


		We found that asynchronous rendering can help in several ways. For example:

		1. As users navigate within an app, newly displayed components often have asynchronous dependencies (including data, images, and code splitting). This can lead to a "cascade of spinners" as the data loads. We'd like to make it easier for product developers to express asynchronous dependencies of components- keeping the old UI "alive" for a certain period while the new UI is not "ready" yet. React could render this new UI in the background and provide a declarative way to show a spinner if it takes more than a second.


		## Updating class components

		#### If you're an application developer, you don't have to do anything about the deprecated methods yet. The primary purpose of this update (v16.3) is to enable OSS maintainers to update their libraries in advance of any deprecation warnings. Those warnings will be enabled with the next minor release, v16.4.


		In this post, we will explore some of the potential capabilities of async rendering, and we'll outline a migration plan for components that rely on the deprecated lifecycles.

		## What can Asynchronous Rendering do?

		* 17.0: Remove `componentWillMount`, `componentWillReceiveProps`, and `componentWillUpdate` . (Only the new "UNSAFE_" lifecycle names will work in this release.)

		In this post, we will explore some of the potential capabilities of async rendering, and we'll outline a migration plan for components that rely on the deprecated lifecycles.


		This would not be safe to do 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:
		`embed:update-on-async-rendering/invoking-external-callbacks-after.js`


		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](/blog/2018/03/01/sneak-peek-beyond-react-16.html). Now we'd like to share with you some of the lessons we've learned while working on this feature, and some suggestions we have for preparing your components to be ready for async rendering when it launches.

		One of the biggest lesson we've learned is that some of our legacy component lifecycles tend to encourage unsafe coding practices. They are:


		Fortunately, you do not!

		In support of version 16.3, we've also created a new NPM package, [`react-lifecycles-compat`](https://github.com/reactjs/react-lifecycles-compat). This package polyfills components so that the new `getDerivedStateFromProps` lifecycle will also work with older versions of React (0.14.9+).


		### New lifecycle: `getSnapshotBeforeUpdate`

		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`.

An update on async rendering #596

An update on async rendering #596

Conversation

bvaughn commented Feb 6, 2018 • edited Loading

TODO before merging

reactjs-bot commented Feb 6, 2018 • edited Loading

wbinnssmith left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gaearon Feb 6, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gaearon Feb 6, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gaearon Feb 7, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Other scenarios

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bvaughn commented Feb 7, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gaearon commented Mar 24, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bvaughn Mar 24, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sophiebits left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bvaughn commented Feb 6, 2018 •

edited

Loading

reactjs-bot commented Feb 6, 2018 •

edited

Loading

gaearon Feb 6, 2018 •

edited

Loading

gaearon Feb 6, 2018 •

edited

Loading

gaearon Feb 7, 2018 •

edited

Loading

bvaughn commented Feb 7, 2018 •

edited

Loading

bvaughn Mar 24, 2018 •

edited

Loading