I am updating a legacy component which uses:
shouldComponentUpdate() to avoid an expensive state re-computation
componentWillUpdate() to do the re-computation and render if 1 passes
The docs say
if shouldComponentUpdate() returns false, then
UNSAFE_componentWillUpdate(), render(), and componentDidUpdate() will not be invoked`
But getDerivedStateFromProps() is not mentioned. I want to use this to replace the deprecated componentWillUpdate().
My question is: does shouldComponentUpdate() block the invocation of getDerivedStateFromProps() in the same way as it did for componentWillUpdate()?
NB: I know about looking at memoization as another solution.
When the passed props change getDerivedStateFromProps() function is called and then shouldComponentUpdate().
However if state changes only the shouldComponentUpdate() lifecycle function is triggered.
You can check the component lifecycle diagram here for more help
Related
If we call the setState() function of a component in React, Browser re-render the whole DOM? or re-render only that component?
Updated
What I want to know is that whether Browser re-render(re-paint) the whole DOM(Page) when render() of only one component is called or Browser re-render only that Node.
That's not the case setState not only calls the render() function but after setState, the following lifecycle functions will run in order depending on what shouldComponentUpdate returns
if shouldComponentUpdate returns true(which is true by default).
shouldComponentUpdate (returns Boolean true/false)
componentWillUpdate (if true is returned)
render() (if true is returned)
componentDidUpdate (if true is returned)
It only triggers the re-render for the current component and all its children(considering no implementation of shouldComponentUpdate for any of its children), The process is called reconcilation.
As you know some lifecycle methods like componentWillReceiveProps are now deprecated.
Well, my code used this lifecycle method and now I have no idea how to migrate to the new API of React.
Here is how I used:
componentWillReceiveProps(nextProps) {
if (nextProps.newPost) {
this.props.posts.unshift(nextProps.newPost);
}
}
In the react blog I could read that...
Together with componentDidUpdate, this new lifecycle should cover all
use cases for the legacy componentWillReceiveProps.
... but how to implement this?
componentDidUpdate() is invoked immediately after updating occurs. This method is not called for the initial render.
Use this as an opportunity to operate on the DOM when the component has been updated. This is also a good place to do network requests as long as you compare the current props to previous props (e.g. a network request may not be necessary if the props have not changed).
componentDidUpdate(prevProps) {
// Typical usage (don't forget to compare props):
if (this.props.userID !== prevProps.userID) {
this.fetchData(this.props.userID);
}
}
Note that it must be wrapped in a condition like in the example above, or you’ll cause an infinite loop.
you can use getDerivedStateFromProps or componentDidMount, there is sequence to running lifecycles :
getDerivedStateFromProps
shouldComponentUpdate
render
getSnapshotBeforeUpdate
componentDidUpdate
getDerivedStateFromProps is being added as a safer alternative to the legacy componentWillReceiveProps.
This is what the 16.3 doc says. Is there anything more to this lifecycle or is it just a name change?
getDerivedStateFromProps is not just a name change to componentWillReceiveProps. It's a static method that is called after a component is instantiated or before it receives new props, unlike componentWillReceiveProps which was not called on initial render.
Return an object to update state in response to prop changes.
Return null to indicate no change to state.
Static lifecycle methods are introduced to prevent unsafe access of instance properties.
The purpose of getDerivedStateFromProps is to only update the state based on props change and not take actions like API call or function call based on prevProps that could be done. All of these could be done in the componentDidUpdate lifecycle function which is safe because even if the change was done in componentWillReceiveProps the data would arrive after render and most often you would trigger another re-render, which could well be done in the componentDidUpdate lifecycle method.
You can refer to this RFC to understand more about why this change was made.
I am in the process of trying to debug a third-party component. What I see happening is that it expects to initialise an internal attribute in componentWillMount() and then make use of it in componentWillUpdate(). The React documentation says this about 'update' methods:
An update can be caused by changes to props or state. These methods are
called when a component is being re-rendered
That being said, should the code handle the possibility that componentWillUpdate() will be called before componentWillMount() or should I be digging to see what seems to be apparent cause of the inverted sequence?
We are using React 15.0.1
As you mentioned componentWillUpdate() will be called only when a component is being re-rendered. And componentWillMount() will be called right before the initial render (a component is mounted just once in its lifecycle). So there are no possibility componentWillMount() is called after componentWillUpdate().
In below image we have react life cycle methods.
Is there any other method which will call only when we change the state only ?
Here shouldComponentUpdate & comonentWillUpdate both will call in case of changes into props and state.
Thank you in Advance !!!
No lifecycle methods exist, but you can use the existing shouldComponentUpdate and componentWillUpdate hooks and wrap your state change logic in a check to make sure that previousState !== this.state
When you change your state, shouldComponentUpdate will be called, if this method return false. No other lifecyle methods will be called anymore.
So just check and return false in shouldComponentUpdate if you don't want other lifecycle methods to be called.