React v16.3.0: New lifecycles and context API
1–10 of 133 posts
Re: React v16.3.0: New lifecycles and context API
#2Lot of niceties in this one. Painful to keep up at times but at least the React team makes it worthwhile for those who do so. Kudos.
Re: React v16.3.0: New lifecycles and context API
#3Summary:
* 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 issue of HOC not passing refs to the component they're wrapping.
* Lifecycle methods (componentWillMount, componentWillReceiveProps, and componentWillUpdate) are now considered legacy, and will be deprecated in future releases. To replace them, they added two new ones (getDerivedStateFromProps and getSnapshotBeforeUpdate). This is due to these lifecycle methods interfering with the goals of async rendering and other ambitious ideas.
* Adds a StrictMode component, which basically just causes React to log more errors during development about deprecated/legacy APIs and unexpected side effects.
Re: React v16.3.0: New lifecycles and context API
#4Summary: * 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…
Note: createRef doesn’t replace callback refs. It just offers a more ergonomic API for common use cases.
There are still rarer cases where callback refs are useful. For example when you need to run a side effect on a node as it attaches and detaches.
Also note: legacy lifecycles are not deprecated yet. You won’t see the warnings unless you opt in with . They will be officially deprecated in a future minor release when more libraries have had time to update.
Re: React v16.3.0: New lifecycles and context API
#5Summary: * 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…
Note that we have no current plans to deprecate componentWillUnmount. (Edit: Parent originally said "componentWill*" deprecated.)
Re: React v16.3.0: New lifecycles and context API
#6Summary: * 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…
I'm curious that with the addition of APIs like forwardRef, if it wouldn't make sense to just add some HOC helper that does the HOC ceremony for you. For example, if you look at withRouter[0] from react-router
1. you need to set the display name
2. you need to set the wrapped component
3. you need to hoist statics
4. and with this update, you'd forward refs
Granted, I could just write it myself real quick, but it'd be nice to just have an API you could use that doesn't require you to fully grasp all the complications that come with using a HOC. I've recently just deferred to using render props instead of HOCs. Render props also require way less complex type definitions if you're using flow or typescript.
[0]: https://github.com/ReactTraining/react-router/blob/master/pa...
Re: React v16.3.0: New lifecycles and context API
#7Summary: * 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…
Note that we have no current plans to deprecate componentWillUnmount. (Edit: Parent originally said "componentWill*" deprecated.)
What would the alternatives to it be anyway?
Re: React v16.3.0: New lifecycles and context API
#8React API reminds of Microsoft COM for JavaScript. It was called Component Object Model. It was hell to deal with when lasted.
Re: React v16.3.0: New lifecycles and context API
#9In 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?
Re: React v16.3.0: New lifecycles and context API
#10I 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 developer pain and breaking changes.
If I had one thing negative to say about this release, it's that I think the forwardRef is maybe moving in the wrong direction a bit. In my experience, higher order components should be the exception, not the rule. They are a neat way to provide some functionality that is otherwise difficult, but their cognitive and maintenance overhead are high. If it stops at forwardRef, no big deal, but I am not sure HOCs are something that deserve explicit API support (and the additional surface area that entails)