36
votes

React introduced new static method getDerivedStateFromProps(props, state) which is called before every render method, but why? Calling it after prop change makes sense to me but after setState it doesn't, maybe I am missing something.

I was creating a datePicker Component according to my company requirement, in the component date is controlled from the prop. I have the following state in the component.

selectedDate: number;
selectedMonth: number;
selectedYear: number;
currentMonth: number;
currentYear: number;
view: string;

selected represents selected date which is derived from date prop and currentMonth and currentYear represents month and year in the current calendar view.

If date from prop changes selected*, currentMonth and currentYear should be changed accordingly. For that, I am using getDerivedStateFromProps but let say user clicks on Month name which will switch calendar view to month (instead of dates name of the month will be shown), the function updates the currentMonth for this using setState, but date the prop is same as before (containing previous month) which should, but getDerivedStateFromProps is called and currentMonth is again as same as before instead of changing.

Right I creating an extra variable in state to track if getDerivedStateFromProps is called due to setState but I don't think that's the right way.

Either I am doing something wrong or missing something or getDerivedStateFromProps should not be called after setState. Probably I am doing something wrong.

6
getDerivedStateFromProps isn't called on setState call. Its when the parent re-renders that the childs getDerivedStateFromProps is called and when the component mounts. A reproducible demo or a relevant code might help in pointing out the mistake. Check this demo which proves that setState doesn't trigger getDerivedStateFromProps codesandbox.io/s/k94z83mz6rShubham Khatri
getDerivedStateFromProps is called before every render method, it was used to call only on prop change once but they changed that in a release probably 16.4 Can you check the sandbox again, I have updated the react and react-dom versionmukuljainx
Yeah, you are right, in the latest version it is called before every re-renderShubham Khatri
So did you find a workaround for this. It seems to be useless, to call it on every rerender, as it breaks setState functionality, and it is impossible to distinguish between state change and props change. Really annoying...tylik
Hi @tylik, I am setting state from props in the constructor and using componentDidUpdate to update state from props if required.mukuljainx

6 Answers

10
votes

The way getDerivedStateFromProps hook works whenever the new props, setState, and forceUpdate is being received.

In the version of 16.3, React is not affecting getDerivedStateFromProps whenever the setState is being used. But they improved it in the version starting with 16.4, so whenever the setState is being called the getDerivedStateFromProps is being hooked.

Here's extracted image from React lifecycle diagram:

16.3

enter image description here

^16.4

enter image description here


So, it's up to you when to hook the getDerivedStateFromProps by checking props and states properly. Here's an example:

static getDerivedStateFromProps (props, state) {
  // check your condition when it should run?
  if(props.currentMonth != state.currentMonth) {
    return {
      currentMonth: state.currentMonth
    }
  }
  // otherwise, don't do anything
  else {
   return null
  }
}
10
votes

I did something like this

constructor(props) {
    super(props);
    this.state = {
        expanded: props.expanded,
        ownUpdate: false
    }
}

static getDerivedStateFromProps(props, state) {
    if (state.ownUpdate) {
        return {
            expanded: state.expanded,
            ownUpdate: false
        };
    } else if (props.expanded !== state.expanded) {
        return {
            expanded: props.expanded
        };
    }
    return null;
}

toggle() {
    this.props.onAftePress(this.state.expanded, this.props.index);
    this.setState({
        expanded: !this.state.expanded,
        ownUpdate: true
    })
}
3
votes

I also got that issue. So I set another variable to check is that prop received for the first time.

this.state={flag:true}

In getderivedstatefromprops

static getderivedstatefromprops(props, state){
   if(props.<*propName*> && flag){
      return({ props.<*propName*>, flag:false})
   }
}

if you want to use multiple props values you need to set your if statements (or any other logic) accordingly.

0
votes

you have the answer in your question itself. "which is called before every render method". Whenever you do a setState the render method will be called.

I would suggest that you lift the state variables currentMonth and currentYear to the parent component and pass them as prop along with other three. You can also pass the change handler as prop and call it from the child.

on initial render - currentMonth and currentYear can be set to null, so that you can have the logic for showing default stuff. When someone chicks on month name, you can call the changeHandler from parent which will pass the new prop. Now in getderivedstatefromprops you no longer have currentMonth and currentYear as `null so you know that the month has changed.

0
votes

For this case (updating the state based on props change), use:

componentDidUpdate(prevProps) {
  // don't forget to compare props
  if (this.props.userID !== prevProps.userID) {
    this.fetchData(this.props.userID);
  }
}

componentDidUpdate will get called after each update (due to props changes / state changes). so you should check if the prop is changed (by this.props.userID !== prevProps.userID).

0
votes

The below seemed to work well for me, and is pretty general.

In constructor:

this.state = {
    props,
    // other stuff
}

In gDSFP:

static getDerivedStateFromProps(newProps, state) {
    if (state.props !== newProps)
        // Compute and return new state relevant to property change
    else
        return state;
}

A bit of experimentation confirms that "state" is no longer automatically the old state, but in this hook instance is the newly set state in combination with the existing props. I imagine the hook was added so as not to have to directly call gDSFP to repeat complex state evolutions dependent on the props, e.g.

this.setState(ClassName.getDerivedStateFromProps(this.props, newState))

The problem is that this is not quite a breaking change, but may result in subtle inefficiencies if old code needlessly does a lot of computation in getDerivedStateFromProps. I just discovered, for instance, that a complex object was being triply constructed, once for real, and two more times just because of this new hook.