3

Here's the scenario. I have a parent component, with a child component. Parent component does the ajax calls and pushes data down to the child.

When child component receives new data, within componentDidUpdate (of the child) i will re-set its internal state.

componentDidUpdate(prevProps, prevState) { 

    if ( prevProps.myRow !== this.props.myRow ) { //check for when new data is passed into this component from its parent / container...
            this.setState({
                editableRowObj    : this.props.myRow    //... only then I should bother updating the state with the new data passed in.         
            })
    }
}

I cannot think of a scenario where inside componentDidUpdate (of the child) I will need to check

prevState !== this.state

This is because when I pass new data into the child component, this.state will be equal to prevState (which will be the old state, prior to receiving new data); i.e. until such time as I run the above setState, the prev and current states will remain the same.

Hence my question is, under what scenarios will I need to check prevState != this.state ?

joedotnot
  • 4,810
  • 8
  • 59
  • 91

2 Answers2

1

The same scenario that applies to props, can apply to props. It might so happen that on change of state you need to trigger an API call to fetch the data. Now you might decide to call a function in the setState callback, but if the same state is being changed from multiple places then componentDidUpdate is a good place.

Shubham Khatri
  • 270,417
  • 55
  • 406
  • 400
  • I guess there will be scenarios where prevState will be useful.. i may be overthinking the problem. I read somewhere that ComponentDidUpdate is a replacement for componentWillReceiveProps. can you recall or confirm if this is correct? – joedotnot Nov 27 '18 at 06:32
  • componentDidUpdate is not a replacement for componentWillReceiveProps, its just that it should be used for a part of the componentWillRecieveProps functionality. i.e to handle side-effects. in order to update state based on props change, you could use getDerivedStateFromProps or memoization in render. – Shubham Khatri Nov 27 '18 at 06:38
  • 1
    Just found where i read that from, React docs on this link https://reactjs.org/blog/2018/03/27/update-on-async-rendering.html#fetching-external-data-when-props-change , where it says the recommended upgrade path is to move data updates into componentDidUpdate (and?) getDerivedStateFromProps. which is probably what you are saying, but i have to study that example – joedotnot Nov 27 '18 at 06:47
0

There's no meaning in comparing the states as is, as they will never be the same. What you're comparing this way is references to the state, and not the nested values. Also, you should be careful with this function, and using setState inside componentDidUpdate is considered an anti-pattern and is not advisable - there's even an ESlint rule that enforces not to do this.

One scenario for comparing states (or props) is in the function shouldComponentUpdate(nextProps, nextState) wherein you decide wether the component should update or not (returns boolean).

Gilad Bar
  • 1,302
  • 8
  • 17
  • `There's no meaning in comparing the states as is, as they will never be the same` Not really, componentDidUpdate in child can be called because of prop update or state update in child itself – Shubham Khatri Nov 26 '18 at 10:59
  • The states (prevState and this.state) are exactly the same in the scenario I described. that's why i asked the question.But thanks for answering. In any case i read somewhere that ComponentDidUpdate is a replacement for componentWillReceiveProps. – joedotnot Nov 27 '18 at 06:28