Does React recommend using setState in componentWillReceiveProps? Since componentWillReceiveProps is already occurring just before an update is rendered, I believe updating state in this portion of the lifecycle does not cause a 2nd re-render, it just changes the state along with the new props on the current update. So why not just mutate state directly? For example, why not do this:
componentWillReceiveProps (nextProps) {
this.state.title = nextProps.title
}
What are the drawbacks of the above or the advantages of using setState such as:
componentWillReceiveProps (nextProps) {
this.setState({title: nextProps.title})
}
Related
I am looking at someone else code who updated the state of object in the react lifecyle:componentWillReceiveProps. I am fairly new to react and redux but thought that you do all the updating of state in the reducer useless its local state. Can someone tell me why he is doing it in componentWillReceiveProps? Thanks
componentWillReceiveProps(nextProps) {
if(this.props.isEditingbook && !nextProps.isEditingbook) {
let book = this.props.index.bookDictionary[this.props.currentbook.id]
book.name = this.state.model.name.value
}
this.setState({ ...this.state, ...nextProps})
}
Well, first of all, componentWillrecieveProps has been deprecated because it might cause some problems, take a look here . Instead, React docs point out that you should use componentDidUpdate which is a safe-to-use method.
And answering your question, if you looked a code where that person was using redux, then he used that deprecated method because when you bind a component to redux goblal state (store) through mapStateToProps, it's properties are bind to that component props. So, in other words, whenever the global state changes so does the component props, and if you want to "track" these changes in your component logic, you have to know when it's props are going to change, that's why you use componentWillRecieveProps or componentDidUpdate methods.
Here is how that example code should has been done with componentDidUpdate:
componentDidUpdate(prevProps) { //prevProps is the previous props of the component before being updated
//so, if this.props != prevProps it means that component props have been updated
if(this.props.isEditingbook && !prevProps.isEditingbook) {
let book = this.props.index.bookDictionary[this.props.currentbook.id]
book.name = this.state.model.name.value
}
this.setState({ ...this.state, ...prevProps})
}
componentDidUpdate(){
var date = this.props.navigation.state.params.selected_date
this.setState({
sleepinputs_date: date
})
}
When I try to setState the props value it throws an error "
You had created infinite state update.
Inside componentDidUpdate you update the state, when it updates the state, componentDidUpdate invokes again in this stuff keeps going without ending.
According to react docs, you will get an argument in componentDidUpdate. You can set state only if you use a conditional like the following.
componentDidUpdate(prevProps) {
// Typical usage (don't forget to compare props):
if (this.props.userID !== prevProps.userID) {
this.fetchData(this.props.userID);
}
}
Basically you are comparing the old props with the new ones. Only if they are different, you can keep updating or modifying the value. If previous props are the same as current props, why you botter to set state them again.
I recently wanted to upgrade my knowledge of React, so I started from the component lifecycle methods. The first thing that got me curious, is this componentWillReceiveProps. So, the docs are saying that it's fired when component is receiving new (not necessarily updated) props. Inside that method we can compare them and save into the state if needed.
My question is: Why do we need that method, if changes in props of that component (inside parent render) will trigger the re-render of this child component?
One common use case are state (this.state) updates that may be necessary in response to the updated props.
Since you should not try to update the component's state via this.setState() in the render function, this needs to happen in componentWillReceiveProps.
Additionally, if some prop is used as a parameter to some fetch function you should watch this prop in componentWillReceiveProps to re-fetch data using the new parameter.
Usually componentDidMount is used as a place where you trigger a method to fetch some data. But if your container, for example, UserData is not unmounted and you change userId prop, the container needs to fetch data of a user for corresponding userId.
class UserData extends Component {
componentDidMount() {
this.props.getUser(this.props.userId);
}
componentWillReceiveProps(nextProps) {
if (this.props.userId !== nextProps.userid) {
this.props.getUser(nextProps.userId);
}
}
render() {
if (this.props.loading) {
return <div>Loading...</div>
}
return <div>{this.user.firstName}</div>
}
}
It is not a full working example. Let's imagine that getUser dispatch Redux action and Redux assign to the component user, loading and getUser props.
It 'serves' as an opportunity to react to the incoming props to set the state of your application before render. If your call setState after render you will re-render infinitely and that's why you're not allowed to do that, so you can use componentWillReceiveProps instead.
But... you are beyond CORRECT in your confusion, so correct in fact that they are deprecating it and other Will-lifecycle hooks Discussion Deprecation.
There are other ways to accomplish what you want to do without most of those Will-lifecycle methods, one way being don't call setState after render, just use the new incoming props directly in render (or wherever) to create the stateful value you need and then just use the new value directly, you can then later set state to keep a reference for the next iteration ex: this.state.someState = someValue, this will accomplish everything and not re-render the component in an infinite loop.
Use this as an opportunity to react to a prop transition before render() is called by updating the state using this.setState(). The old props can be accessed via this.props. Calling this.setState() within this function will not trigger an additional render.
Look at this article
the componentWillReceiveProps will always receive as param "NxtProps", componentWillReceiveProps is called after render().
some people use this method use this to compare nxtProps and this.props to check, if something should happen before the component call render, and to some validations.
check the react's documentation to know more about react lifecycle!
hope this could help you!
changes in props of that component (inside parent render) will trigger the re-render of this child component
You are absolutely right. You only need to use this method if you need to react to those changes. For instance, you might have a piece of state in a child component that is calculated using multiple props.
Small Example:
class Test extends Component {
state = {
modified: "blank"
};
componentDidMount(){
this.setState({
modified: `${this.props.myProp} isModified`
});
}
componentWillReceiveProps(nextProps) {
this.setState({
modified: `${nextProps.myProp} isModified`
});
}
render() {
return <div className="displayed">{this.state.modified}</div>
}
}
In this example, componentDidMount sets the state using this.props. When this component receives new props, without componentWillReceiveProps, this.state.modified would never be updated again.
Of course, you could just do {this.props.myProp + "IsModified"} in the render method, but componentWillReceiveProps is useful when you need to update this.state on prop changes.
The react docs mention that calls to setState are enqueued, and do not happen immediately. Does react make any guarantees that setState enqueued inside componentWillReceiveProps will execute before the next component render? Are either of these scenarios more likely than the other?
props change > componentWillReceiveProps called > setState enqueued > setState runs > render (which includes new state)
props change > componentWillReceiveProps called > setState enqueued > render > setState runs > re-rendered
Or, are both of these scenarios equally likely? Meaning does React not make any guarantees when setState will run relative to component lifecycle methods?
Here is a ES2015 code excerpt of my example:
import React from 'react';
class Widget extends React.Component {
componentWillReceiveProps() {
this.setState({foo: 'bar'});
}
render() {
return <div>
<a onClick={(e) => {
e.preventDefault();
this.props.triggerExternalPropsChange();
}}>
Click me to trigger new props
</a>
</div>;
}
}
Where triggerExternalPropsChange passes new props to the Widget component.
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. There won’t be two renders in this case, just one.
It's 1.
Calling setState() in componentWillReceiveProps() is an exception in the sense of executing state update before the component renders, so you will get both props changes and state changes applied in the same render.
Yep, both are likely. React will try to render anytime it gets new props or state and because it does dom diffing, it tries to render as often as possible. You have options to control it though, using shouldComponentUpdate you can check and wait until both props and state have been updated before rendering.
I have a login page in which I am using componentWillReceiveProps to route to the next page. But the state that I am setting inside componentWillReceiveProps does not seem to set.
This is my componentWillReceiveProps method :
componentWillReceiveProps(nextProps) {
if (nextProps.isAuthenticated === true) {
browserHistory.push('/home');
} else {
console.log("this.props :::" + JSON.stringify(this.props))
console.log("this.state :::" + JSON.stringify(this.state))
console.log("nextProps :::" + JSON.stringify(nextProps))
this.setState({
errorMessage: nextProps.authenticationError
})
console.log("this.state :::" + JSON.stringify(this.state))
}
}
The console output I am getting is this :
this.props :::{"authenticationError":null}
this.state :::{"username":"35135","password":"3135","errorMessage":""}
nextProps :::{"isAuthenticated":false,"authenticationError":"Could not find user in DB."}
this.state :::{"username":"35135","password":"3135","errorMessage":""}
Here even after setting the state, my state has not changed.
Please tell me what is it that I'm doing wrong.
EDIT: I have this component which is ErrorText , which takes in the errroMessage property.
<ErrorText errorMsg={this.state.errorMessage}></ErrorText>
setState() is an asynchronous operation, so it doesn't take effect immediately:
setState() enqueues changes to the component state and tells React that this component and its children need to be re-rendered with the updated state [...]
Think of setState() as a request rather than an immediate command to update the component. For better perceived performance, React may delay it, and then update several components in a single pass. React does not guarantee that the state changes are applied immediately.
setState() does not always immediately update the component. It may batch or defer the update until later. This makes reading this.state right after calling setState() a potential pitfall. Instead, use componentDidUpdate or a setState callback [...], either of which are guaranteed to fire after the update has been applied.
Here's an example of a setState callback in your context:
this.setState(
{ errorMessage: nextProps.authenticationError },
function() {
console.log( 'this.state ::: ' + JSON.stringify( this.state ) );
}
);
Refer to same stackoverflow question:
Why Calling react setState method doesnt mutate the state immediately
setState() does not immediately mutate this.state but creates a
pending state transition. Accessing this.state after calling this
method can potentially return the existing value. There is no
guarantee of synchronous operation of calls to setState and calls may
be batched for performance gains.
This is likely because this.setState is an async function. You can pass a callback to handle events which should happen directly after setting state. Checkout this chosen answer for a code example.