React - setState in componentWillReceiveProps
Is this legal?
componentWillReceiveProps: function(nextProps) {
if (typeof nextProps.contact != 'undefined') {
this.setState({forename: nextProps.contact.forename});
this.setState({surname: nextProps.contact.surname});
this.setState({phone: nextProps.contact.phone});
this.setState({email: nextProps.contact.email});
}
}
Because I don't know how to fill my inputs and still be able that the user can edit the inputs. So I came up with this solution instead of trying to manipulate the this.props.
Any suggestions?
javascript reactjs
add a comment |
Is this legal?
componentWillReceiveProps: function(nextProps) {
if (typeof nextProps.contact != 'undefined') {
this.setState({forename: nextProps.contact.forename});
this.setState({surname: nextProps.contact.surname});
this.setState({phone: nextProps.contact.phone});
this.setState({email: nextProps.contact.email});
}
}
Because I don't know how to fill my inputs and still be able that the user can edit the inputs. So I came up with this solution instead of trying to manipulate the this.props.
Any suggestions?
javascript reactjs
3
For anyone stepping on this in 2018, you might wanna usegetDerivedStateFromProps()
– Dane
Apr 19 '18 at 4:57
add a comment |
Is this legal?
componentWillReceiveProps: function(nextProps) {
if (typeof nextProps.contact != 'undefined') {
this.setState({forename: nextProps.contact.forename});
this.setState({surname: nextProps.contact.surname});
this.setState({phone: nextProps.contact.phone});
this.setState({email: nextProps.contact.email});
}
}
Because I don't know how to fill my inputs and still be able that the user can edit the inputs. So I came up with this solution instead of trying to manipulate the this.props.
Any suggestions?
javascript reactjs
Is this legal?
componentWillReceiveProps: function(nextProps) {
if (typeof nextProps.contact != 'undefined') {
this.setState({forename: nextProps.contact.forename});
this.setState({surname: nextProps.contact.surname});
this.setState({phone: nextProps.contact.phone});
this.setState({email: nextProps.contact.email});
}
}
Because I don't know how to fill my inputs and still be able that the user can edit the inputs. So I came up with this solution instead of trying to manipulate the this.props.
Any suggestions?
javascript reactjs
javascript reactjs
asked Aug 6 '15 at 15:08
BeneBene
98611427
98611427
3
For anyone stepping on this in 2018, you might wanna usegetDerivedStateFromProps()
– Dane
Apr 19 '18 at 4:57
add a comment |
3
For anyone stepping on this in 2018, you might wanna usegetDerivedStateFromProps()
– Dane
Apr 19 '18 at 4:57
3
3
For anyone stepping on this in 2018, you might wanna use
getDerivedStateFromProps()
– Dane
Apr 19 '18 at 4:57
For anyone stepping on this in 2018, you might wanna use
getDerivedStateFromProps()
– Dane
Apr 19 '18 at 4:57
add a comment |
4 Answers
4
active
oldest
votes
Your code is legal according to react documentation.
You also may consider to put this code inside getInitialState
method as according to another react doc initializing from props is not an anti-pattern.
You also can replace several calls with one setState
method call:
this.setState({forename: nextProps.contact.forename,
surname: nextProps.contact.surname,
phone: nextProps.contact.phone,
email: nextProps.contact.email});
add a comment |
According to this react doc , changing states inside componentWillReceiveProps is not recommended. The doc explains it very clearly.
And it also gives us alternative solutions for "fully controlled component" and "uncontrolled components", please read this react doc
add a comment |
As of React v16.6.3 this is considered UNSAFE and componentWillReceiveProps
is marked for deprecation. The removal is planned to happen in version 17.
Note:
Using this lifecycle method often leads to bugs and inconsistencies, and for that reason it is going to be deprecated in the future.
If you need to perform a side effect (for example, data fetching or an animation) in response to a change in props, use componentDidUpdate lifecycle instead.
For other use cases, follow the recommendations in this blog post about derived state.
If you used componentWillReceiveProps for re-computing some data only when a prop changes, use a memoization helper instead.
If you used componentWillReceiveProps to “reset” some state when a prop changes, consider either making a component fully controlled or fully uncontrolled with a key instead.
In very rare cases, you might want to use the getDerivedStateFromProps lifecycle as a last resort.
In your case you should use componentDidUpdate
instead.
add a comment |
The only reason componentWillReceiveProps
exists is to give the component an opportunity to setState. So yes, any state you set synchronously in it will be processed together with the new props.
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%2f31859391%2freact-setstate-in-componentwillreceiveprops%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
Your code is legal according to react documentation.
You also may consider to put this code inside getInitialState
method as according to another react doc initializing from props is not an anti-pattern.
You also can replace several calls with one setState
method call:
this.setState({forename: nextProps.contact.forename,
surname: nextProps.contact.surname,
phone: nextProps.contact.phone,
email: nextProps.contact.email});
add a comment |
Your code is legal according to react documentation.
You also may consider to put this code inside getInitialState
method as according to another react doc initializing from props is not an anti-pattern.
You also can replace several calls with one setState
method call:
this.setState({forename: nextProps.contact.forename,
surname: nextProps.contact.surname,
phone: nextProps.contact.phone,
email: nextProps.contact.email});
add a comment |
Your code is legal according to react documentation.
You also may consider to put this code inside getInitialState
method as according to another react doc initializing from props is not an anti-pattern.
You also can replace several calls with one setState
method call:
this.setState({forename: nextProps.contact.forename,
surname: nextProps.contact.surname,
phone: nextProps.contact.phone,
email: nextProps.contact.email});
Your code is legal according to react documentation.
You also may consider to put this code inside getInitialState
method as according to another react doc initializing from props is not an anti-pattern.
You also can replace several calls with one setState
method call:
this.setState({forename: nextProps.contact.forename,
surname: nextProps.contact.surname,
phone: nextProps.contact.phone,
email: nextProps.contact.email});
answered Aug 6 '15 at 15:48
Mikhail RomanovMikhail Romanov
1,2441817
1,2441817
add a comment |
add a comment |
According to this react doc , changing states inside componentWillReceiveProps is not recommended. The doc explains it very clearly.
And it also gives us alternative solutions for "fully controlled component" and "uncontrolled components", please read this react doc
add a comment |
According to this react doc , changing states inside componentWillReceiveProps is not recommended. The doc explains it very clearly.
And it also gives us alternative solutions for "fully controlled component" and "uncontrolled components", please read this react doc
add a comment |
According to this react doc , changing states inside componentWillReceiveProps is not recommended. The doc explains it very clearly.
And it also gives us alternative solutions for "fully controlled component" and "uncontrolled components", please read this react doc
According to this react doc , changing states inside componentWillReceiveProps is not recommended. The doc explains it very clearly.
And it also gives us alternative solutions for "fully controlled component" and "uncontrolled components", please read this react doc
edited Jul 19 '18 at 15:22
answered Jul 19 '18 at 15:16
HaimengHaimeng
113
113
add a comment |
add a comment |
As of React v16.6.3 this is considered UNSAFE and componentWillReceiveProps
is marked for deprecation. The removal is planned to happen in version 17.
Note:
Using this lifecycle method often leads to bugs and inconsistencies, and for that reason it is going to be deprecated in the future.
If you need to perform a side effect (for example, data fetching or an animation) in response to a change in props, use componentDidUpdate lifecycle instead.
For other use cases, follow the recommendations in this blog post about derived state.
If you used componentWillReceiveProps for re-computing some data only when a prop changes, use a memoization helper instead.
If you used componentWillReceiveProps to “reset” some state when a prop changes, consider either making a component fully controlled or fully uncontrolled with a key instead.
In very rare cases, you might want to use the getDerivedStateFromProps lifecycle as a last resort.
In your case you should use componentDidUpdate
instead.
add a comment |
As of React v16.6.3 this is considered UNSAFE and componentWillReceiveProps
is marked for deprecation. The removal is planned to happen in version 17.
Note:
Using this lifecycle method often leads to bugs and inconsistencies, and for that reason it is going to be deprecated in the future.
If you need to perform a side effect (for example, data fetching or an animation) in response to a change in props, use componentDidUpdate lifecycle instead.
For other use cases, follow the recommendations in this blog post about derived state.
If you used componentWillReceiveProps for re-computing some data only when a prop changes, use a memoization helper instead.
If you used componentWillReceiveProps to “reset” some state when a prop changes, consider either making a component fully controlled or fully uncontrolled with a key instead.
In very rare cases, you might want to use the getDerivedStateFromProps lifecycle as a last resort.
In your case you should use componentDidUpdate
instead.
add a comment |
As of React v16.6.3 this is considered UNSAFE and componentWillReceiveProps
is marked for deprecation. The removal is planned to happen in version 17.
Note:
Using this lifecycle method often leads to bugs and inconsistencies, and for that reason it is going to be deprecated in the future.
If you need to perform a side effect (for example, data fetching or an animation) in response to a change in props, use componentDidUpdate lifecycle instead.
For other use cases, follow the recommendations in this blog post about derived state.
If you used componentWillReceiveProps for re-computing some data only when a prop changes, use a memoization helper instead.
If you used componentWillReceiveProps to “reset” some state when a prop changes, consider either making a component fully controlled or fully uncontrolled with a key instead.
In very rare cases, you might want to use the getDerivedStateFromProps lifecycle as a last resort.
In your case you should use componentDidUpdate
instead.
As of React v16.6.3 this is considered UNSAFE and componentWillReceiveProps
is marked for deprecation. The removal is planned to happen in version 17.
Note:
Using this lifecycle method often leads to bugs and inconsistencies, and for that reason it is going to be deprecated in the future.
If you need to perform a side effect (for example, data fetching or an animation) in response to a change in props, use componentDidUpdate lifecycle instead.
For other use cases, follow the recommendations in this blog post about derived state.
If you used componentWillReceiveProps for re-computing some data only when a prop changes, use a memoization helper instead.
If you used componentWillReceiveProps to “reset” some state when a prop changes, consider either making a component fully controlled or fully uncontrolled with a key instead.
In very rare cases, you might want to use the getDerivedStateFromProps lifecycle as a last resort.
In your case you should use componentDidUpdate
instead.
answered Nov 23 '18 at 8:36
gyosifovgyosifov
1,84121732
1,84121732
add a comment |
add a comment |
The only reason componentWillReceiveProps
exists is to give the component an opportunity to setState. So yes, any state you set synchronously in it will be processed together with the new props.
add a comment |
The only reason componentWillReceiveProps
exists is to give the component an opportunity to setState. So yes, any state you set synchronously in it will be processed together with the new props.
add a comment |
The only reason componentWillReceiveProps
exists is to give the component an opportunity to setState. So yes, any state you set synchronously in it will be processed together with the new props.
The only reason componentWillReceiveProps
exists is to give the component an opportunity to setState. So yes, any state you set synchronously in it will be processed together with the new props.
answered Nov 20 '18 at 10:49
ShivamShivam
1,1921332
1,1921332
add a comment |
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%2f31859391%2freact-setstate-in-componentwillreceiveprops%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
3
For anyone stepping on this in 2018, you might wanna use
getDerivedStateFromProps()
– Dane
Apr 19 '18 at 4:57