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

61–70 of 133 posts

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

#61

Post by brianvaughn »

hardwaresofton wrote: post #60
danabramov wrote: post #49

Earlier quoted context omitted.

We maintain more than 50,000 components at Facebook, and I don’t believe your assessment that “APIs undergoes drastic changes every few months” is accurate. The component API has barely changed since the initial release five years ago. When we need to make changes, it’s the team of 8 people that need to port all those dozens of thousands of components to new APIs. It would be infeasible for us to break APIs every few…

I apologize -- I should have written "API internals". I did not mean to state that the component API changed a lot, just seemingly that the internals did, with fiber and the like. I understand the team is hard at work making React better, and there is absolutely no doubt that you are succeeding and react is getting better. However, the amount of large internal changes indicates that as you improve and (most likely) s…

> However, the amount of large internal changes indicates that as you improve and (most likely) shed unneeded complexity, that there must have been complexity to shed.

The v16 rewrite (dubbed "fiber") wasn't just about cleaning up internals- it was about supporting a fundamentally different type of behavior- asynchronous rendering [1]

> Obviously no one is perfect, and hindsight is 20/20, but for such a "small" (yes, interacting with the dom is actually super duper hard, and edgecases abound) scope, I've seen more large-ish overhauls than I am comfortable with.

To be fair, React supports many more targets than just the DOM. In addition to the DOM- there's react-native, react-art, react-music, react-hardware, etc.

Don't mean to sound argumentative, just wanted to add some info in case there were potential misconceptions. :)

1: https://reactjs.org/blog/2018/03/01/sneak-peek-beyond-react-...

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

#62

Post by myth_drannon »

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 fetch the new data in componentWillReceiveProps. All components verify if the url was updated with the url param they need and only the one that had it changed will fetch data. I use componentWillReceiveProps everywhere. I'm not sure if there is another life cycle to do just that.

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

#63

Post by adam_sohn »

myth_drannon wrote: post #59
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?

I think developers will stop using ReactJS long before FB is gone. Look at angular, backbone, JQuery, Adobe Flex and so many others. It's just a framework....

Angular 5 is very popular now. Big teams with data intensive administration dashboards are choosing it over React.

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

#64

Post by Bahamut »

navls wrote: post #38
hoodoof wrote: post #26

Earlier quoted context omitted.

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.

> Will MySpace ever lose its monopoly? [2007] https://www.theguardian.com/technology/2007/feb/08/business....

FB is on a whole different level in terms of revenue (and profitability) and users.

While it may be possible that FB fails, there’s not a whole lot of symptoms apparent that it will, unlike MySpace.

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

#65

Post by aioprisan »

adam_sohn wrote: post #63
myth_drannon wrote: post #59

Earlier quoted context omitted.

I think developers will stop using ReactJS long before FB is gone. Look at angular, backbone, JQuery, Adobe Flex and so many others. It's just a framework....

Angular 5 is very popular now. Big teams with data intensive administration dashboards are choosing it over React.

I don't buy it. Vue is eating Angular's lunch, with React leading. https://medium.jonasbandi.net/angular-vs-react-popularity-ea...

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

#66

Post by WhitneyLand »

m0meni wrote: post #3

Summary: * Context overhaul that makes it way easier to pass state/props down multiple levels of components. Uses function as a child for the API * Adds React.createRef function to create refs. Creating refs through callbacks is still a thing for advanced cases, but this provides a more ergonomic API to replace the old clunky ref={(c) => this._yourthing = c} type callback. * Adds React.forwardRef, which solves the is…

Developer learning curve: The context name is a good choice I think. Context API sounds much more elegant than global variables API.

While that’s a little tongue in cheek, the lifecycle method names I would rate as a drastic drop in intuitiveness:

Previous:

  componentWillMount

  componentWillReceiveProps

  componentWillUpdate
New:

  getDerivedStateFromProps

  getSnapshotBeforeUpdate

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

#67

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

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

#69

Post by danabramov »

hardwaresofton wrote: post #60
danabramov wrote: post #49

Earlier quoted context omitted.

We maintain more than 50,000 components at Facebook, and I don’t believe your assessment that “APIs undergoes drastic changes every few months” is accurate. The component API has barely changed since the initial release five years ago. When we need to make changes, it’s the team of 8 people that need to port all those dozens of thousands of components to new APIs. It would be infeasible for us to break APIs every few…

I apologize -- I should have written "API internals". I did not mean to state that the component API changed a lot, just seemingly that the internals did, with fiber and the like. I understand the team is hard at work making React better, and there is absolutely no doubt that you are succeeding and react is getting better. However, the amount of large internal changes indicates that as you improve and (most likely) s…

>just seemingly that the internals did, with fiber and the like.

We‘ve lived with the same codebase for four years and frankly, it was slowing us down. Not all original abstractions aged well because when React was written, we didn’t really have a lot of experience with React :-)

I don’t think it’s because the original code was bad (I’m not familiar with Mongo so I don't know if that’s what you were implying), but because it’s not very easy to come up with an architecture that is both efficient and targets multiple view output targets (e.g. React Native) from the first attempt. Especially considering support for Native was retrofitted into an existing design at some point. It was also pretty much impossible to foresee the kind of features we’d be working on in a few years before anybody used React.

Some fundamental assumptions in the old codebase were actively preventing us from implementing new features. For example, there was an assumption all over the codebase that a custom component always renders one root, but this prevented us from letting people return arrays from render. There were many small things like this, and at some point it was clear we needed to redesign the internals from scratch.

The Fiber rewrite was about unlocking our larger vision (we recently shared its details: https://reactjs.org/blog/2018/03/01/sneak-peek-beyond-react-...) but it was just as essential for smaller incremental improvements.

Long-requested features that shipped in React 16 like fragments (returning multiple components from render), error boundaries (gracefully recovering from runtime errors), portals (declaratively rendering the child React tree to a different DOM subtree), and an official context API (finally shipped today) would not be possible without rewriting the internals to an architecture that incorporates our learnings about how React should work that we’ve accumulated over the years.

I’d also argue those features (and then ones we’re working towards—please do watch my demo at the previous link!) are a bit more ambitious than “interacting with the DOM”.

> am just dumbfounded when people bill react as simple but have never heard of something like Mithril that actually is simple

I agree React is not simple internally, but that was never the goal. The goal is to make it simple to build products with React, and so far I believe its success speaks to product developers finding it helpful.

I don’t push for React being used everywhere (and I heard people who used Mithril are happy with it) but I hope this gives some insight into our decision and development process.

We didn’t rewrite React because we wanted to clean a few things up, or because we didn’t know what we were doing. We’re pursuing very specific goals, and a new architecture is essential to enabling them. And there were no multiple rewrites; just one: https://code.facebook.com/posts/1716776591680069/react-16-a-....

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

#70

Post by danabramov »

WhitneyLand wrote: post #66
m0meni wrote: post #3

Summary: * Context overhaul that makes it way easier to pass state/props down multiple levels of components. Uses function as a child for the API * Adds React.createRef function to create refs. Creating refs through callbacks is still a thing for advanced cases, but this provides a more ergonomic API to replace the old clunky ref={(c) => this._yourthing = c} type callback. * Adds React.forwardRef, which solves the is…

Developer learning curve: The context name is a good choice I think. Context API sounds much more elegant than global variables API. While that’s a little tongue in cheek, the lifecycle method names I would rate as a drastic drop in intuitiveness: Previous: componentWillMount componentWillReceiveProps componentWillUpdate New: getDerivedStateFromProps getSnapshotBeforeUpdate

This is intentional because those are relatively rare use cases. We want them to stand out and be quite specific about what they're doing.

You still have `componentDidMount`, `componentDidUpdate`, and `componentWillUnmount` that should be used more commonly and do exactly what you expect them to.

Post reply on HN