ComponentDidUpdate and prevState
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 ?
reactjs react-lifecycle react-state
asked Nov 26 '18 at 9:26
joedotnotjoedotnot
2,01143554
add a comment |
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 ?
reactjs react-lifecycle react-state
asked Nov 26 '18 at 9:26
joedotnotjoedotnot
2,01143554
add a comment |
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 ?
reactjs react-lifecycle react-state
asked Nov 26 '18 at 9:26
joedotnotjoedotnot
2,01143554
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 ?
reactjs react-lifecycle react-state
reactjs react-lifecycle react-state
asked Nov 26 '18 at 9:26
joedotnotjoedotnot
2,01143554
asked Nov 26 '18 at 9:26
joedotnotjoedotnot
2,01143554
asked Nov 26 '18 at 9:26
joedotnotjoedotnot
2,01143554
asked Nov 26 '18 at 9:26
joedotnotjoedotnot
2,01143554
asked Nov 26 '18 at 9:26
joedotnotjoedotnot
2,01143554
2,01143554
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
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.
answered Nov 26 '18 at 9:32
Shubham KhatriShubham Khatri
93.8k15118158
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 6: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 6:38
1
Just found where i read that from, React docs on this link reactjs.org/blog/2018/03/27/… , 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 6:47
add a comment |
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).
answered Nov 26 '18 at 9:32
Gilad BarGilad Bar
753314
There's no meaning in comparing the states as is, as they will never be the sameNot 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 6:28
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53478065%2fcomponentdidupdate-and-prevstate%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
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.
answered Nov 26 '18 at 9:32
Shubham KhatriShubham Khatri
93.8k15118158
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 6: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 6:38
1
Just found where i read that from, React docs on this link reactjs.org/blog/2018/03/27/… , 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 6:47
add a comment |
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.
answered Nov 26 '18 at 9:32
Shubham KhatriShubham Khatri
93.8k15118158
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 6: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 6:38
1
Just found where i read that from, React docs on this link reactjs.org/blog/2018/03/27/… , 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 6:47
add a comment |
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.
answered Nov 26 '18 at 9:32
Shubham KhatriShubham Khatri
93.8k15118158
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.
answered Nov 26 '18 at 9:32
Shubham KhatriShubham Khatri
93.8k15118158
answered Nov 26 '18 at 9:32
Shubham KhatriShubham Khatri
93.8k15118158
answered Nov 26 '18 at 9:32
Shubham KhatriShubham Khatri
93.8k15118158
answered Nov 26 '18 at 9:32
Shubham KhatriShubham Khatri
93.8k15118158
93.8k15118158
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 6: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 6:38
1
Just found where i read that from, React docs on this link reactjs.org/blog/2018/03/27/… , 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 6:47
add a comment |
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 6: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 6:38
1
Just found where i read that from, React docs on this link reactjs.org/blog/2018/03/27/… , 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 6:47
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 6:32
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 6: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 6:38
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 6:38
1
1
Just found where i read that from, React docs on this link reactjs.org/blog/2018/03/27/… , 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 6:47
Just found where i read that from, React docs on this link reactjs.org/blog/2018/03/27/… , 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 6:47
add a comment |
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).
answered Nov 26 '18 at 9:32
Gilad BarGilad Bar
753314
There's no meaning in comparing the states as is, as they will never be the sameNot 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 6:28
add a comment |
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).
answered Nov 26 '18 at 9:32
Gilad BarGilad Bar
753314
There's no meaning in comparing the states as is, as they will never be the sameNot 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 6:28
add a comment |
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).
answered Nov 26 '18 at 9:32
Gilad BarGilad Bar
753314
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).
answered Nov 26 '18 at 9:32
Gilad BarGilad Bar
753314
answered Nov 26 '18 at 9:32
Gilad BarGilad Bar
753314
answered Nov 26 '18 at 9:32
Gilad BarGilad Bar
753314
answered Nov 26 '18 at 9:32
Gilad BarGilad Bar
753314
753314
There's no meaning in comparing the states as is, as they will never be the sameNot 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 6:28
add a comment |
There's no meaning in comparing the states as is, as they will never be the sameNot 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 6:28
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
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 6:28
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 6:28
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53478065%2fcomponentdidupdate-and-prevstate%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
