Update on Async Rendering
reactjs.org
reactjs.org
Wow, I try to use those as little as possible because there's always a bit of a smell, but I suspect there's a lot of code out there that will be getting a second look now. Kudos to the React team for explaining the rationale and migration path(s) in detail. React has consistently made me write better code, however begrudgingly.
Now my react components are a lot simpler and I don't try anything fancy. The parents tend to handle the data fetching and they pass it down to the children components which are often stateless components. So I only use constructor(props) and render() plus custom functions. It keeps it cleaner but I also have more components as a result. Some of which do very little.
So I agree, those functions smell and looked more useful upon first glance than they actually were.
componentDidMount will fire only on the client and componentWillMount on client and server.
Since the server rendered stuff wasn't interactive I could only do a subset of the things the client allowed, so I would do these in componentWillMount and the rest in componentDidMount only on the client.
`componentWillMount` is technically equivalent to the constructor so there's nothing you could do on the server you couldn't do in the constructor instead.
https://reactjs.org/blog/2018/03/27/update-on-async-renderin...
I guess there are legitimate uses for them, but almost invariably any component I see that uses them turns out to be a buggy POS.
yarn add react@next react-dom@next
getSnapshotBeforeUpdate, getDerivedStateFromProps
> These lifecycle methods have often been misunderstood and subtly misused; furthermore, we anticipate that their potential misuse may be more problematic with async rendering.
I hate it when library authors blame users (consuming developers in this case) for their blunders. Almost all lifecycle methods in React are confusing and contrived. The state mechanisms are becoming so convoluted (and overly generalized), no wonder we're ending up with gobbledygook like "getSnapshotBeforeUpdate(...)."
It's also pretty funny (or sad) to see no mention of SSR. Just a few months ago I spent literally weeks trying to figure out how to do server-side rendering with React. I ended up populating data via componentWillMount on the back-end. Terrible solution, but hey, it's the only one React has. Now, they suggest moving data-population in componentDidMount.. but guess what?
This will not work on the server-side because technically components never mount when doing SSR.
I’m sorry the post came across this way. We didn’t intend to blame the users. The component API was virtually unchanged for five years, and when it was originally designed, we didn’t anticipate how it would be used, so the hooks were pretty low level and matched how React worked internally. These days we have a better idea of where we want to take React (I hope that my talk[1] may inspire you even though you already formed a negative opinion). The work we're doing now is just to fix the mistakes we made in the past with a gradual migration path.
>no wonder we're ending up with gobbledygook like "getSnapshotBeforeUpdate(...)."
I totally see what you mean but this particular lifecycle is for a very rare use case. If you have better suggestions for naming it please let us know—we have an open RFC process and you are welcome to participate there.[2] We didn’t separate it on a whim—it is essential to have a pure lifecycle like this to implement some use cases (like autoscrolling to new data) with asynchronous rendering[1].
>I ended up populating data via componentWillMount on the back-end. Terrible solution, but hey, it's the only one React has
You're right—but this solution doesn't solve async data fetching. It only works when the data is synchronously available, and per the post, in that case you can already use the constructor.[3]
>This will not work on the server-side because technically components never mount when doing SSR.
I think you might have missed this part of the post:
>In 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.
The mentioned “suspense” API is both much less verbose and actually was designed with server rendering in mind. It would let us fetch data on the server and on the client and suspend rendering until the data is ready (and show a placeholder if it takes too long).
The lifecycle changes in these blog posts are exactly the kind of work we need to do to make APIs like Suspense possible. Again, I encourage you to watch my talk[1], the second half of which demonstrates this API.
I hope this clarifies our position a bit, and I’m sorry if it seemed like we don’t care about our users. It took us about a month to write this blog post, and we know it still doesn’t address all use cases. We’ll take your feedback in mind next time we amend it. Thanks!
[1]: https://reactjs.org/blog/2018/03/01/sneak-peek-beyond-react-...
[2]: https://github.com/reactjs/rfcs/pull/33
[3]: https://reactjs.org/blog/2018/03/27/update-on-async-renderin...
> I totally see what you mean but this particular lifecycle is for a very rare use case.
It's not that rare. Consider a route change where some state needs to be preserved or, like the article mentions, a scroll position change (or reset!).
> You're right—but this solution doesn't solve async data fetching. It only works when the data is synchronously available, and per the post, in that case you can already use the constructor.[3]
I just want to point out how fundamentally flawed this is. The constructor is meant to initialize internal and initial state of objects. Making a data/network request in the constructor is beyond bizarre. In fact, the general consensus was that doing that sort of thing in the constructor is kind of an antipattern[1].
> The mentioned “suspense” API is both much less verbose and actually was designed with server rendering in mind. It would let us fetch data on the server and on the client and suspend rendering until the data is ready (and show a placeholder if it takes too long).
I'll have to check out suspense, but I feel that it's yet another API that reinvents the wheel. We'll see.
[1] https://discuss.reactjs.org/t/constructor-vs-componentwillmo...
Note that he said synchronous data fetching, ie a local cache. If you are querying a local cache, this enables you to grab data before the first render (saving a re-render) which is more obviously beneficial on low-power, slow-to-render devices.
It CAN also be used to initiate a network request, but this is discouraged because it can fire multiple times: meaning you should only do this if the endpoint is idempotent and you can live with excess requests. It may also complicate testing.
Bit OT, but I generally think "that's an anti-pattern" criticism isn't a great contribution unless you're specifying what the problem is.
> Bit OT, but I generally think "that's an anti-pattern" criticism isn't a great contribution unless you're specifying what the problem is.
I thought I was pretty clear: putting that kind of thing in the constructor is terrible practice and goes against common sense.
[1] https://stackoverflow.com/questions/14569499/javascript-mock...
I elaborated here: https://news.ycombinator.com/item?id=16696836
Why would there be "no local cache" in the context of SSR?
>I thought I was pretty clear: putting that kind of thing in the constructor is terrible practice and goes against common sense.
Those are adjectives, the parent asked for technical arguments.
Because there's no browser?
In my anecdotal experience this code is still pretty rare (compared to overall number of components). You don't need this hook to reset scroll position (`componentDidUpdate` alone is sufficient) or maintain it (browser does this automatically if the inserted DOM height is enough to cover it).
The use case for `getSnapshotBeforeUpdate` refers to cases where you have a list that needs to track its current position during offscreen insertions (for example, new items loaded above in the feed) or a list that “catches up” with new content (for example, a message thread that auto-scrolls to the last message unless you’re in the middle of a conversation).
>The constructor is meant to initialize internal and initial state of objects. Making a data/network request in the constructor is beyond bizarre.
I am not suggesting to do network requests in it. Please see the link I pointed to: it shows initializing initial state. Not data fetching.
To be clear: today in React there is no way to asynchronously fetch data on the server. It’s just not supported (and we’re aware it’s an unfortunate limitation). So if the data is already available synchronously (which in your case it seems to be because you said you were able to use `componentWillMount` for this which is also synchronous on the server), then you can synchronously read it in the constructor. If it’s not available synchronously, then there’s nothing `componentWillMount` gives you anyway.
In either case, this limitation is exactly what motivates our work on React Suspense (which will support waiting for data both on the server and on the client). But to support this API, we need to make component compatible with async rendering first. Which is what this blog post is all about.
>I'll have to check out suspense, but I feel that it's yet another API that reinvents the wheel. We'll see.
You’re welcome to start watching the RFC repository and comment when we post more technical details about it. We think it adds a capability that’s always been missing in React (pausing rendering while keeping the screen consistent) and I hope you’ll find it useful.
What we've done for the past few years is trigger async fetches in componentWillMount on the server and perform multiple renderToString.
This requires some instrumentation so you can monitor that all the data has loaded and your tree is fully rendered.
Removing componentWillMount will force us to rewrite everything to the suspense API. I hope that transition won't cause too many headaches.
The downside of this is that the cost of rendering is multiplied. We know it’s an existing workaround but it’s not a good long term solution. We want to enable something better.
>Removing componentWillMount will force us to rewrite everything to the suspense API.
This is not accurate. The blog post states that `UNSAFE_componentWillMount` is here to stay so you can keep using that until we have a first-class data fetching solution that works both on the client and the server. You can also use the constructor for this (it’s technically equivalent to `componentWillMount`).
While it contradicts what I said earlier (avoid side effects in constructor) you’re already using a hack (rendering twice) and I’d argue this is no worse as a temporary solution. Don’t forget that `componentWillMount` is equivalent to the constructor for all intents and purposes, and only exists because it predates ES6 classes (and the ability to define a constructor). So you were already doing side effects in what is effectively a constructor.
Still, the upcoming Suspense API mentioned in the blog post is the intended long term solution to this. It will work both on the client and the server, and it will allow you to remove the double rendering hack. But to prepare for Suspense, we need to make components compatible with async rendering (which is what the blog post is all about).
We added a section to the blog post which I hope clarified it:
>When supporting server rendering, it’s currently necessary to provide the data synchronously – componentWillMount was 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.
So you can keep using `UNSAFE_componentWillMount` or constructor for now, and migrate to Suspense when it’s ready (and render your app in a single pass).
As a former Adobe Flex dev I had to maintain mountains of scream inducing code I had to maintain that was littered with callLaters - the clearest sign the other dev didn't understand the component lifecycle.
You can't blame the library authors for that.
On the other hand, it looks like we're streamlining some verbosity. I just hope we can be okay with the right balance and we don't end up with a really terse looking language.
Hope this is clearer now!
What about the syntax do you find confusing? The rest is all just ES6 + class properties.
static getDerivedStateFromProps(nextProps, prevState)
getDerivedStateFromProps(nextProps)
Even on an old machine I view bundle times of more than 30 seconds (without minification) as suspicious.
Browserify does it much more quickly.
Edit: I should say bundler != tranpiler. A bundler may or may not be implemented as a compiler. In the end it's just fancy concatenation and code generation, whereas a transpiler (going from one language to another) requires parsing to an AST
Transpilers are just a word invented to mean compiling one high level language into another.
The thing is, compilers already to that. The "level" of the language is irrelevant, the fundamental concepts are the same.
So compiler works.
It's been used this way since at least 1980 (eg: in 86-DOS there was TRANS.COM)
But there's nothing about webpack that requires an AST, it can use things that do tho.
They can use transpilers (ie, in webpack with babel-loader). But they aren't them.
Yeah I mean possibly, but I'm a programmer, not a javascript tool yak shaver. I want to get work done not learn the ins and outs of "webpack".
Of other tools get me their more quickly and simply then I'm going to use them.
Moreover, the full build times are, at least in my experience with webpack starter packs for side projects and much larger webpack builds at work, only a cost you pay when deploying or setting up a dev environment for the first time. My local dev environments recompile only the parts of the codebase that they need to, and that usually happens quickly enough that it’s ready by the time I go to my browser and refresh.
Current react ecosystem broadly speakings splits on state management solutions in two styles: 1. Single Observable-like source of truth (redux store) 2. Multi-Observables (relay, appolo, mobx)
It will be interesting to see if `create-subscription` catches on, and whether library authors will start exporting subscriptions as public apis.
[1] https://www.npmjs.com/package/create-subscription
[2] https://github.com/acdlite/recompose/blob/master/docs/API.md...
and its going as soon as V17? Too early.
For example load something from network, which goes into redux, redux triggers a props update, so then I do something because for example now redux state has changed to say "loaded === true"
Is this not the correct function to handle changes in props?
If you are updating the state of that component, that's exactly what the new getDerivedStateFromProps is designed for.
If you are doing something else (esp. fetching other data or some other side effect), componentDidUpdate is likely the best place (it receives prevProps as an argument, so you can compare old and new).
Manually copying things from Redux into local state from `componentWillReceiveProps` (or even with new `getDerivedStateFromProps`) seems unnecessary to me. There are exceptions like rare cases where you want to have a “draft” of some state that can later be “reverted”. But in general you wouldn't want to “sync” state from one source to another.
"What do I do in componentWillReceiveProps?" It's a good question. Looking through the code I see alot of cases in which I am mapping new props to state, sometimes transforming received network data that is stored in redux, sometimes making a barrier to redirect to a different page if for example some condition has changed.
Perhaps these things are relics from before I really came to understand Redux - maybe in most cases I can just directly use props rather than having an intermediate setting of state.
That's a side effect. Move that to `componentDidUpdate`: https://reactjs.org/blog/2018/03/27/update-on-async-renderin...
>mapping new props to state
As I noted in https://news.ycombinator.com/item?id=16711813, usually it's not necessary (and complicated your code for nor benefit). For rare cases when it's useful, migrate to `getDerivedStateFromProps`: https://reactjs.org/blog/2018/03/27/update-on-async-renderin...
We are trying to strike a balance between supporting huge legacy apps- (something Facebook has to do for itself too)- and encouraging safe/bug-free coding practices for future apps.
1: https://github.com/reactjs/rfcs/blob/master/text/0006-static...
It lets you define a promise-returning data loader function for any component at any depth in the tree, which will run synchronously on the server and asynchronously on the client.
All you have to do is wrap your app in a provider, and add a single extra line of code to the server (since the sync server rendering relies on running the render once, waiting, then running again once all data is loaded for every component in the tree). You can find much more detail and examples in the blogpost linked from the github repo.
I'm really excited about async data loading coming to 'native' React, I essentially wrote react-frontload as a polyfill for this feature and hopefully my library won't be necessary any more once it's released. But for now, and in the future for projects that won't be able to update to the latest React, there it is. I've been pretty happy using it in production, and I hope it's useful for others too!
In essence, React has a new primitive where calling setState will try to render the tree, but only flush changes to the DOM once all the components in the tree have finished loading. If you call setState again during this process (the app is still usable while waiting), and changes are to be made on the same portion of the tree that's currently loading async data, then React will simply dismiss the old tree from ever rendering - fixing race conditions in a natural/clever way.
The client side thing of implementing async loading with a loading prop and componentDidMount obviously has to be done 'manually', this is straightforward and not something I'd expect React or even a library to solve - what react-frontload does though is gets the same component to also synchronously load that same data (using the same function) on server render. This is much more fiddly and is way too much boilerplate to write manually for each component, not to mention that you need some global context to tie all the promises together. That's the problem that react-frontload solves - the client side loader thing is up to you to implement, even with react-frontload.
What I'm hoping is that it may be possible to go back to writing this stuff manually on certain components, because it'll be simple enough with Suspense - or at least just make the implementation of react-frontload much simpler and carry on using it as syntax sugar (it's quite nice to just define an async data loading function via a HOC, for instance - you obviously wouldn't get that having to hand code lifecycle methods for each component).
>The client side thing of implementing async loading with a loading prop and componentDidMount obviously has to be done 'manually', this is straightforward and not something I'd expect React or even a library to solve
The problem Suspense is solving on the client is not straightforward. But you'll need to see my demo (second part of this talk[1]). It's very hard to talk about in abstract without seeing it.
The big difference Suspense brings is the ability to wait with the whole state transition until all leaves are ready. Think transitioning between pages (that need data) is as easy as updating state in the parent, and React takes care of “waiting” for the page to be ready before displaying it (or falling back to a placeholder).
>This is much more fiddly and is way too much boilerplate to write manually for each component, not to mention that you need some global context to tie all the promises together
Suspense takes care of that, you don’t need to manually collect Promises.
[1]: https://reactjs.org/blog/2018/03/01/sneak-peek-beyond-react-...
Now you've got me thinking, and you're right. Even in a client-only case, the simple spinner-until-data-loaded pattern works for a solo component just fine, but doesn't at all account for waiting for children, etc, without implicit dependencies between parent and child. If you've got stuff like that going on, then yes this is a pretty complex problem.
It does definitely seem like Suspense is going to remove most of the complexity involved in the 'synchronous' server render problem, especially with regards to manual promise collection. This is awesome work :-)
I love Redux but I find myself using it less than I want to because so much stuff has to be put in place any time I want to store some stuff.
I didn't really understand how React worked underneath and I thought these functions would be helpful. But they weren't...
• Initializing Flux stores in componentWillMount. It's often unclear whether this is an actual problem or just a potential one (eg if the store or its dependencies change in the future). Because of this uncertainty, it should be avoided.
• Adding event listeners/subscriptions in componentWillMount and removing them in componentWillUnmount. This causes leaks if the initial render is interrupted (or errors) before completion.
• Non-idempotent external function calls during componentWillMount, componentWillUpdate, componentWillReceiveProps, or render (eg registering callbacks that may be invoked multiple times, initializing or configuring shared controllers in such a way as to trigger invariants, etc.)
Edit: For formatting
This frees up React to not hold into the whole previous props object in some cases in future versions.
It’s a bit more verbose but it also solves the problem of prevProps being null on first render (and thus forcing you to write an extra check every time you use this method).
Copying the URL to the state will work, although it's a bit more verbose.
> 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:
> * A 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.
> * Not passing the previous props to this function is a step toward freeing up memory in future versions of React. (If React does not need to pass previous props to lifecycles, then it does not need to keep the previous props object in memory.)
1: https://reactjs.org/blog/2018/03/27/update-on-async-renderin...
16.3 does have some goodies though- new context API, forwardRef, etc.
edit: Ooops, I thought the commenter was referring to shouldcomponentupdate. Sorry for the confusion, please downvote this out of the discussion!
It definitely has an intangible value.
It then uses that information to implement shouldComponentUpdate for you. Each render call refreshes the data use by shouldComponentUpdate.
It gives you 100% percise updating of react components based on state, for free.
1. A single “async component” is useless because the power of async rendering is in letting React coordinate the work of the whole tree. As long as just one leaf isn’t async-compatible, the whole tree isn’t.
2. In practice most components already are async-compatible. So we don’t want to hold off progress by forcing people to explicitly specify it. Instead the plan is to outlaw patterns that we know won’t work.
Hope this makes sense.
BTW, I've watched your jsconf, great presentation, can't wait to use all those goodies (also love HN for a chance of response straight from react core team :)
We'll offer a <StrictMode> component in React 16.3 that warns about some unsafe patterns (like legacy lifecycles and a few other issues). Later on we'll provide more testing tools for libraries.
We used it internally (at Facebook) several weeks ago to update ~14,000 components that used the unsafe lifecycles.
Update:
I took a look at their work on fibers. It looks like they are manually deciding on what is or is not enough computation to perform in a fiber. This is fine, but it will require some careful attention by the react team.
It would be neat if they could use web workers for some of this.
Could be a good idea to try draw some diagrams too =)
https://mobile.twitter.com/acdlite/status/977291318324948992 https://mobile.twitter.com/acdlite/status/978412930973687808
Will put them in some future blog post.
An official life cycle flow would be awesome too.
In the past, when teaching other developers, I just throw a dart at one of the many google image search results that try show the flow.
Quoting from that page:
> Therefore it is important that we don’t just upgrade our own codebases but that we bring our whole community with us. We take the upgrade path very seriously - for everyone.
> If we’re not careful, we can hit a cliff where nobody upgrades. This has happened to many software project ecosystems in the past.
> Therefore, we’re committed to making it easy for most components and libraries built on top of React to be compatible with two major versions at the same time.
I'm not sure if I'm reading them and the diagrams in that page correctly, but looks like the deprecation should happen at 17 and removal at 18 according to it?
16.3 is including dep warnings and tips to upgrade, check.
> We will continue to release codemods for common patterns to make automatic upgrades of your codebase easier.
Probably will be there closer to 17 release.
> Once we’ve reached the end of life for a particular major version, we’ll release a new major version where all deprecated APIs have been remove
Once 16.x end of life is reached, the next major version, 17, will remove the deprecated APIs, check.
They are literally following exactly what they said.
Yes, there will also be a codemod for the "UNSAFE_" rename.
And the codemod has already been released: https://github.com/reactjs/react-codemod#rename-unsafe-lifec...
We've used it internally (at Facebook) to update ~14,000 components already, so it's well tested.
Java is leaking on the client side ...
They are descriptive function names, that's all.
"derived state from props" 4 words.
"snapshot before update" 3 words.
If you get an allergic reaction from that it's just you.
After seeing thousands of React components and responding to thousands of issue reports, we know which patterns often get people in trouble. Some of these patterns indicated bad design on our part, and we want to fix those issues.
We are adding safer alternatives for these use cases that don’t have those pitfalls. Importantly, we want to clearly communicate that these existing methods cause problems and these problems will become more noticeable in future versions of React that will support asynchronous rendering.
I gave a talk about what “asynchronous rendering” means for React, and about exciting new long-requested features it enables.[1] I encourage you to watch it if you’re curious about our motivations. These methods are incompatible with it, hence they’re “unsafe”. Since the risk of them being unsafe grows with time, we decided it’s worth adding a prefix to call them out in the product code.
We’re trying to do best by our community and I’m sorry if we’re falling short of that. We set up an RFC repository[2] a few months ago so you’re welcome to give us feedback on the future changes.
[1]: https://reactjs.org/blog/2018/03/01/sneak-peek-beyond-react-...
However both Facebook and large products at other companies have too much code that depends on those lifecycles. Potentially thousands of components. So it’s infeasible to completely deprecate them. At least not within a time frame of a year.
This is why we’re still leaving the “unsafe” aliases in React 17 so that people can opt out of async rendering and keep using those while they’re not ready to migrate.
Since we need some version of the hooks to stay, we need to clearly differentiate them so that new code doesn’t use them. Hence the prefix.
And we provided a codemod to help with the "huge legacy apps": https://github.com/reactjs/react-codemod#rename-unsafe-lifec...
We've run it internally already to update ~14,000 components.