Why use getDerivedStateFromProps when you have componentDidUpdate?

I’m confused about the new lifecycle of react 16, getDerivedStateFromProps use case. Take below code for example, getDerivedStateFromProps is not needed at all since I can achieve what I want with componentDidUpdate.

export class ComponentName extends Component {
  //what is this for?
  static getDerivedStateFromProps(nextProps, prevState) {

    if (nextProps.filtered !== prevState.filtered && nextProps.filtered === 'updated') {
      return {
        updated: true //set state updated to true, can't do anything more?

    return null;


  componentDidUpdate(prevProps, prevState) {
    if(prevProps.filtered !== this.state.filtered && this.state.filtered === 'updated'){
      console.log('do something like fetch api call, redirect, etc..')

  render() {
    return (


Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.

Method 1

From this article:

As componentWillReceiveProps gets removed, we need some means of updating the state based on props change — the community decided to introduce a new — static — method to handle this.

What’s a static method? A static method is a method / function that exists on the class not its instance. The easiest difference to think about is that static method does not have access to this and has the keyword static in front of it.

Ok, but if the function has no access to this how are we to call this.setState? The answer is — we don’t. Instead the function should return the updated state data, or null if no update is needed

Why use getDerivedStateFromProps when you have componentDidUpdate?

The returned value behaves similarly to current setState value — you only need to return the part of state that changes, all other values will be preserved.

You still need to declare the initial state of the component (either in constructor or as a class field).

getDerivedStateFromProps is called both on initial mounting and on re-rendering of the component, so you can use it instead of creating state based on props in constructor.

If you declare both getDerivedStateFromProps and componentWillReceiveProps only getDerivedStateFromProps will be called, and you will see a warning in the console.

Usually, you would use a callback to make sure some code is called when the state was actually updated — in this case, please use componentDidUpdate instead.

Method 2

With componentDidUpdate you can execute callbacks and other code that depends on the state being updated.

getDerivedStateFromProps is a static function and so has no access to the this keyword. Also you wouldn’t have any callbacks placed here as this is not an instance based lifecycle method. Additionally triggering state changes from here could cause loops(e.g. with redux calls).

They both serve different fundamental purposes. If it helps getDerivedStateFromProps is replacing componentWillReceiveProps.

Method 3

getDerivedStateFromProps basically can save you one render cycle. Let’s say due to some props change, you have to update some state and the UI responds with the new state. Without getDerivedStateFromProps, you have to wait until componentDidUpdate is invoked to make the prop comparison and call setState to update the UI. After that, componentDidUpdate is invoked again and you have to pay attention to avoiding endless rendering. With getDerivedStateFromProps, the UI update just happens earlier.

All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0

0 0 votes
Article Rating
Notify of

Inline Feedbacks
View all comments
Would love your thoughts, please comment.x