[steve_taylor]

These lifecycle changes make me nervous. We’re losing some important escape hatches to make way for async rendering which solves a problem that very few web apps have. To use an analogy, it’s like “unsafe” features being deprecated in C to make way for the next major release which will be more like Java. My first impression of this is that it’s the beginning of the end for React. People can still use old versions, but the reality is that they’ll have to stick with old versions of related libraries and they’ll have to shrinkwrap their node_modules because these drastic changes are being rolled out in minor version updates.

[danabramov]

>async rendering which solves a problem that very few web apps have.

From my experience of talking to React developers, data fetching is the most common problem people bump into with React apps. Async rendering is key to making data fetching easy and natural in React, and to providing a great user experience whether the user is on a fast or a slow network. Please watch the second part of my talk for a demo if you’re not convinced: https://reactjs.org/blog/2018/03/01/sneak-peek-beyond-react-...

>We’re losing some important escape hatches

We believe that the combination of new lifecycle hooks and the non-legacy old ones covers all use cases we are aware of (including escape hatches!). If we missed some use case you relied on, we are asking you to let us know: https://reactjs.org/blog/2018/03/27/update-on-async-renderin...

Escape hatches are core to React’s philosophy. To reiterate a point from the blog post, we have more than 50,000 React components at Facebook, and they aren’t going to rewrite themselves :-).

So we are committed to both supporting those lifecycles under `UNSAFE_` aliases (as mentioned in the blog post, they will continue working in React 17), and will provide async-safe hooks for use cases we might have missed (please report them!)

Thanks.

[steve_taylor]

I watched the video and I’ll keep an open mind.

I really hope you will hold off deprecation warnings until 17.0.0 instead of 16.x, even if that means you need one more major version than you had planned. Being on a team whose policy is to not shrinkwrap, so that we automatically get patches (not my policy, personally), at some point we’re going to start seeing all these deprecation warnings without having explicitly version-bumped React.

My overall concern is that we’re paying for the async renderer by moving to a higher level of abstraction for all class components. With Fiber, React is becoming a vastly different library. From the outside, having seen Fiber slated for release in 16.0.0 and, being pushed back to an unknown 16.x release, and then being pushed back to 17.0.0, it seems like you had not anticipated the extent to which the core React API had to be changed to enable the async renderer. It seemed simple enough in the beginning, but now we’re looking forward to losing what React once was so we can use a DOM renderer that will be optional anyway.

[brianvaughn]

> From the outside, having seen Fiber slated for release in 16.0.0 and, being pushed back to an unknown 16.x release, and then being pushed back to 17.0.0, it seems like you had not anticipated the extent to which the core React API had to be changed to enable the async renderer.

"fiber" was the code name for the rewrite that was released as version 16. Async rendering is a feature that we've been working on adding- (which the "fiber" rewrite was done to support). We've known that would take some time, mostly due to the fact that we want to gradually migrate old apps (as much as possible). :)

We're also working on other cool, related efforts- like a compiler (https://twitter.com/trueadm/status/944908776896978946) and proper built-in support for async-data, dubbed "suspense" (https://reactjs.org/blog/2018/03/01/sneak-peek-beyond-react-...).

[Vinnl]

> We're also working on other cool, related efforts- like a compiler (https://twitter.com/trueadm/status/944908776896978946)

That sounds like it could bring a lot of benefits. Would, and if so how, that affect people using TypeScript?

[brianvaughn]

I don't think we know enough about where compilation will end up to comment much. I wouldn't expect TypeScript to be negatively affected though (since it compiles to JavaScript). So far, the problems we're noticing are from certain coding patterns or practices within components. However we deal with these (whether we add new lifecycles or encourage alternate patterns, etc) it should hopefully apply equally to JS/Flow/TypeScript.

[Vinnl]

Obviously, but thanks for the tentative impact estimates :)

[danabramov]

There was never a plan to enable async rendering in React 16. “Fiber” referred to a new internal architecture (which enabled fragments, error boundaries, portals, and now context). It was a prerequisite to exploring async rendering, but it was also important for the above features, and it shipped in React 16.0.

Async rendering indeed needed more research but we’ve been testing it internally for months now, and are getting closer to the point where it’s ready. I disagree with you that replacing a few often misunderstood lifecycle hooks with more concrete alternatives significantly raises the abstraction level.

We did anticipate that some lifecycle methods will be problematic (e.g. https://github.com/facebook/react/issues/7671 was filed over a year ago, or a few months before the first line of Fiber code was written).

We’ve thought about these issues for quite a while. Jordan (creator of React) started thinking about them about four years ago (https://twitter.com/jordwalke/status/500587022890061824).

We needed time to evaluate different possible migration strategies and experiment with them, and we have a good idea now of what they look like. We don’t have all the answers yet but we’re getting there, and are doing that in the open.

[girvo]

For what it’s worth, I think the async rendering changes/data fetching within components is a lovely idea. But I’m biased and desperately want reducerComponent from ReasonReact in Flow/React...

[danabramov]

We’re always looking at alternative component APIs and that might be a possible future direction.