Nothing will go wrong if you still use this method for setting your app state before mounting it’s just that it has become needless, we can carry out these pre-mounting actions in other possible ways and there are certain pitfalls with componentWillMount () —Initialize the state in the constructor itself.
Never use it for API calls, the asynchronous data fetching requests may initiate multiple times and multiple renders may hinder the user experience, use componentDidMount instead.
Do not subscribe any actions here, because in case if the mounting fails then componentWillUnmount() will never be executed.
Using setState() here will not trigger a re-rendering of the app because the component for which we are setting the state is not being mounted yet.
4.
componentWillReceiveProps() / UNSAFE_componentWillReceiveProps() —componentWillReceiveProps(nextProps) or UNSAFE_componentWillReceiveProps(nextProps)Mostly used to get new/updated props from parent components on updating the current state.
If you are using middle-wares like Redux or Mobx or managing form field validations or submission, we often use componentWillReceiveProps() to get the new props and update our app state which actually works fine, the reasons for making it UNSAFE are —React only does a shallow comparison of the instances, i.
e the old prop and new prop is compared with a triple-equals-equal reference which implies that both are same physical objects even though the values inside are not same.
The only possible solution would be to have created a deep copy of the data, and then later do a deep comparison — but this can be prohibitively expensive for large data structures.
The data prop may contain reference to some function which could change the values of the data prop and React will not be aware of this update and doesn’t have a copy of the intermediate values.
The data prop may contain reference to an object which could re-initialize values of the data prop and again without deep comparison React treats both the old and new props as same.
(A => B) !=> (B => A) problem best explains the side effects.
5.
componentWillUpdate() / UNSAFE_componentWillUpdate() —componentWillUpdate(nextProps, nextState) or UNSAFE_componentWillUpdate(nextProps, nextState)This method is invoked whenever a re-render is required, it is similar to componentWillMount() but setState() can’t be called here as after setState componentWillUpdate will be invoked again and it will lead to an infinite loop.
It’s a misconception that the app state will not get updated inside componentDidUpdate in fact React first setState for the app and then flushes the component from the DOM, the same thing happens with componentDidMount .
Since componentWillUpdate is similar in terms of execution to componentWillMount and componentWillReceiveProps combined, the new method getDerivedStateFromProps() does the job safely.
New life-cycle methods in actionstatic getDerivedStateFromProps — static getDerivedStateFromProps(props, state)As clear from the component life-cycle model above, the getDerivedStateFromProps method is called just before the render.
The keyword static is essential over here, which explains that this method is invoked by the class not by it’s instance which means any reference of ‘this’ is not accessible inside this method.
So, the static keyword must be used in the declaration.
Unlike other life-cycle methods which can return any desired values like objects or functions etc.
getDerivedStateFromProps method only returns any valid state object or null.
This method is invoke at the time of initial rendering as well as on subsequent updates.
So, it is guaranteed to get executed which makes it a replacement for componentWillReceiveProps as it doesn’t depend on any other factors to get invoked.
This is a powerful update to React components, as it makes them more smart and independent.
In getDerivedStateFromProps you can perform the calculations and produce any side-effect based on the calculation result inside componentDidUpdate(), the combination of these two makes almost all state updates of your component possible.
There are certain pitfall remains because this method may be used in an incorrect way or someone may find any unexpected behavior because of certain uncommitted DOM updates.
To prevent such unintentional code breaks we do have getSnapshotBeforeUpdate() to the rescue.
2.
getSnapshotBeforeUpdate — getSnapshotBeforeUpdate(prevProps, prevState)This method is invoked just before the most recent state changes gets updated to the DOM.
It stores the current state of your app and resume it exactly after the updates are being made, which can be used to make network requests in the background without affecting the user experience.
getSnapshotBeforeUpdate takes the snapshot of the current appstate and after the commit phase, this ‘snapshot’ is passed as a third parameter to the componentDidUpdate method.
componentDidUpdate(prevProps, prevState, snapshot) This combination makes it a replacement for componentWillUpdate method and make our components even more powerful.
This feature could be used to avoid latency while scrolling to a large list of dynamically fetched data.
TakeawaysUse React.
PureComponent to prevent unnecessary updates.
Make smart and standalone components to improve reusability.
Do not compensate on using UNSAFE methods instead of the new methods as they will be deprecated with React 17.
The two new methods are capable of performing every state update irrespective of the cause.
Advance concepts like Context API could also be used to provide global state to be consumed by specific child components, to get rid of unnecessary passing of props down the components hierarchy.
This article was originally published by Systango Technologies, a specialised software studio.
.. More details