Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

React v16.3.0: New lifecycles and context API

reactjs.org

Post reply on HN
Print view View original

71–80 of 133 posts

Re: React v16.3.0: New lifecycles and context API

#71

Post by danabramov »

steve_taylor wrote: post #67

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, bu…

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

Re: React v16.3.0: New lifecycles and context API

#72

Post by danabramov »

hardwaresofton wrote: post #55
sibeliuss wrote: post #50

Earlier quoted context omitted.

Components are just functions -- HOC's are higher order functions. The pattern dropped out like all patterns drop out -- from use. Its nothing specific to React, but to functional programming

Just replied in the other spot -- I understand the similarities now, but I think this points to react still not being as simple as it could be -- if components were really as simple as being functions from state to UI, reacts API would be drastically smaller. My point is that it's not that simple (for better or for worse, some of the added complexity in the API IS essential IMO), but people still say things like "com…

To be fair if a function gets called, any functions called from it also... get called (whether arguments to them have changed or not).

So if anything, this particular example speaks more to React components being “just functions” (which is a statement I disagree with—but I don’t think this example is very relevant to that).

Re: React v16.3.0: New lifecycles and context API

#73

Post by akrumel »

danabramov wrote: post #58
akrumel wrote: post #56

Earlier quoted context omitted.

Responding to "exists for a fairly rare use case" statement, I just searched the the web app I am currently writing and it uses componentWillReceiveProps() ~20 times. Most cases are for detecting changes requiring freeing/fetching network based resources where the data involved can get excessive if care is not taken. This would seem to be a common scenario for many domains. On a sidenote, I have thoroughly enjoyed wo…

>I just searched the the web app I am currently writing and it uses componentWillReceiveProps() ~20 times. How many components do you have? Absolute number doesn’t tell me a lot. :-) >Most cases are for detecting changes requiring freeing/fetching network based resources where the data involved can get excessive if care is not taken. Not sure I fully understand. Could you provide a small example?

Component count is around 140. Fwiw, some are stateless, functional components while others are more complex.

A form of master/detail is driving the need to detect prop changes to fetch additional data while freeing previous data. Consider the master/detail of multiple levels deep driven by route parameters through the ui hierarchy. In RN, this is less of an issue since screens tend to be more focused and ui stack driven. But users working full-time in a complex ui specialized for power users can require much more data/dynamism.

Re: React v16.3.0: New lifecycles and context API

#74

Post by danabramov »

akrumel wrote: post #73
danabramov wrote: post #58

Earlier quoted context omitted.

>I just searched the the web app I am currently writing and it uses componentWillReceiveProps() ~20 times. How many components do you have? Absolute number doesn’t tell me a lot. :-) >Most cases are for detecting changes requiring freeing/fetching network based resources where the data involved can get excessive if care is not taken. Not sure I fully understand. Could you provide a small example?

Component count is around 140. Fwiw, some are stateless, functional components while others are more complex. A form of master/detail is driving the need to detect prop changes to fetch additional data while freeing previous data. Consider the master/detail of multiple levels deep driven by route parameters through the ui hierarchy. In RN, this is less of an issue since screens tend to be more focused and ui stack dr…

Fair enough. As mentioned in Update on Async Rendering blog post, there’s a less verbose data fetching API coming down the line (“suspense”). Not quite ready for the release yet. But it will require components to be async-compatible which is why we're getting these lifecycle changes out now.

Re: React v16.3.0: New lifecycles and context API

#75

Post by danabramov »

myth_drannon wrote: post #62
myth_drannon wrote: post #43

Does anyone finds the new getDerivedStateFromProps adds too much boilerplate code for the developer to write and be aware? So for every previous prop that I need to compare with I need to remember to update it in the state? If before it was as simple as this.props.X!==nextProps.X now I need to set the state with the current prop!

For different reasons I don't use Redux that much in my app. The state is persisted in the url, or to be more precise React-Router's location. So let's say I have five different components on the page. All of them receive location and history as props. Each component updates the url separately, let's say a table updates the url with sort1=blah now the component needs to read this param compare next and current and fe…

I believe it's in the blog post:

https://reactjs.org/blog/2018/03/27/update-on-async-renderin...

(TLDR: Use `componentDidUpdate` for this.)

Have you had a chance to skim through it?

Re: React v16.3.0: New lifecycles and context API

#76

Post by jakelazaroff »

eric_b wrote: post #10

I like that they are taking the deprecation of the lifecycle methods slowly. And the automated script to migrate to the 'UNSAFE' version of those methods in 17 is a nice touch. I don't know if I love the new context API, but it's great they're giving an official option. Of the big JS frameworks that are popular at the moment, I think the React team is doing the best job of balancing new features with minimizing devel…

> I like that they are taking the deprecation of the lifecycle methods slowly.

React has a great deprecation strategy. Their general philosophy is "if you can use version X with no warnings, you should be able to use version X+1 with no changes to your app."

Re: React v16.3.0: New lifecycles and context API

#77

Post by steve_taylor »

danabramov wrote: post #71
steve_taylor wrote: post #67

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, bu…

>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…

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.

Re: React v16.3.0: New lifecycles and context API

#78

Post by chrischen »

hoodoof wrote: post #26
swalsh wrote: post #9

In the unlikely scenario of Facebook's demise, how do you think the maintenance of React would transpire? Do you think some other tech company would snatch up the design leads, and pick up the torch? Would it go into its own independent organization?

There is no demise coming for Facebook. They'll clean up, grandma, aunty and the school mothers will continue posting and they never even knew there was an issue. People will soon forget.

Eventually grandma will cease to exist.

Re: React v16.3.0: New lifecycles and context API

#79

Post by brianvaughn »

steve_taylor wrote: post #77
danabramov wrote: post #71

Earlier quoted context omitted.

>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…

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…

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

Re: React v16.3.0: New lifecycles and context API

#80

Post by brianvaughn »

brlewis wrote: post #68

Can someone point me to reasonably simple but not contrived examples that put createContext and forwardRef to good use? As I look at this from a Mithril perspective the value isn't obvious.

The `withTheme` HOC uses `createContext` and `forwardRef`. I don't think it's contrived. :)

https://reactjs.org/blog/2018/03/29/react-v-16-3.html#forwar...

Post reply on HN