5 ms·

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 app

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 9y ago
>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-16.html 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-rendering.html#other-scenarios 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 9y ago
  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 9y ago
    > 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 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-16.html https://reactjs.org/blog/2018/03/01/sneak-peek-beyond-react-...).
    - Vinnl 9y ago
      > We're also working on other cool, related efforts- like a compiler (https://twitter.com/trueadm/status/944908776896978946 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 9y ago
        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 9y ago
        Obviously, but thanks for the tentative impact estimates :)
  - 9y ago
- girvo 9y ago
  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 9y ago
    We’re always looking at alternative component APIs and that might be a possible future direction.

danabramov 9y ago

>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-16.html 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-rendering.html#other-scenarios 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 9y ago
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 9y ago
  > 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 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-16.html https://reactjs.org/blog/2018/03/01/sneak-peek-beyond-react-...).
  - Vinnl 9y ago
    > We're also working on other cool, related efforts- like a compiler (https://twitter.com/trueadm/status/944908776896978946 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 9y ago
      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 9y ago
        Obviously, but thanks for the tentative impact estimates :)
- 9y ago
girvo 9y ago
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 9y ago
  We’re always looking at alternative component APIs and that might be a possible future direction.