In React, does setState always assign a new object to this.state? In other words, when you call:

this.setState({
  key1: val1,
  key2: val2
});

does it always merge the current state object with the new properties into a new object, queueing an operation which is functionally equivalent to the following?

this.state = {
   ...this.state,
   key1: val1,
   key2: val2
};

The reason I'm asking is that I'd like to know whether this.state !== nextState is always guaranteed to be true inside shouldComponentUpdate() if the update was triggered by setState.

Thanks.

In React, does setState always assign a new object to this.state? In other words, when you call:

this.setState({
  key1: val1,
  key2: val2
});

does it always merge the current state object with the new properties into a new object, queueing an operation which is functionally equivalent to the following?

this.state = {
   ...this.state,
   key1: val1,
   key2: val2
};

The reason I'm asking is that I'd like to know whether this.state !== nextState is always guaranteed to be true inside shouldComponentUpdate() if the update was triggered by setState.

Thanks.

• javascript
• reactjs

• this is duplicate of this : stackoverflow./questions/35867038/… – eenagy Commented Aug 13, 2017 at 3:19
• you don't want to mutate this.state like in the second example, use this.setState always as advised in react docs – eenagy Commented Aug 13, 2017 at 3:20
• @eenagy I don't really see how it's a duplicate. I'm not asking about the difference between using setState and this.state = .... I never assign to the state object directly myself; I'm asking about the internal implementation of setState, and whether it returns a new object which doesn't have reference equality to the previous state object. – philraj Commented Aug 13, 2017 at 3:43
• 1 you are right, it's not duplicate, mistake on my part about that – eenagy Commented Aug 13, 2017 at 3:46
• No worries. :-) – philraj Commented Aug 13, 2017 at 3:51

2 Answers 2

The simple answer to your question will be "Yes", but for one update cycle. Let me explain this.

As you may already know React setState does not always immediately update the ponent. Sometimes React batch or defer the updates until later. As an example, let's assume you have something like follows in your event handler.

onClick() {
  this.setState({quantity: state.quantity + 1});
  this.setState({quantity: state.quantity + 1});
  this.setState({quantity: state.quantity + 1});
}

These state update will be queued and execute all together in one update cycle. In such scenario React only create a new state object for the first setState and that object will mutate for subsequent setState updates. You can clearly see this in the source code here.

However, this is something totally about how React works under the hood and we won't need to worry about that. Because there will be only one shouldComponentUpdate() and ponentDidUpdate() for one cycle. By the time we access the state it will be always a new object. So we can safely assume that setState() guaranteed to create a new state object every time. But make sure that you aware of other implications of setState which explains in the official documentation.

I'd like to know whether this.state !== nextState is always guaranteed to be true inside shouldComponentUpdate().

The answer to your this question will be "No" as also explained in other answers. shouldComponentUpdate() will be called because of either state change, props change or both. So this.state !== nextState won't true if the ponent has updated only because of props change.

I think you want to know the answer to this question.

Will this.state !== nextState is always guaranteed to be true inside shouldComponentUpdate() ?

According to react docs shouldComponentUpdate will be called on three instance

• state changed
• props changed
• state and props changed

So if only props are changing, your current state will be equal the last unmodified state.

shouldComponentUpdate() is invoked before rendering when new props or state are being received. Defaults to true. This method is not called for the initial render or when forceUpdate() is used.

The first question that you asked are depends on your style of data management for your state.

React lets you use whatever style of data management you want, including mutation.

And the docs also states that

shallow merge of stateChange into the new state, e.g., to adjust a shopping cart item quantity

But looking at the internal parts of setState beginUpdateQueue method let me doubtful when state gets mutated.

I think it would be wise to use immutability-helper for this part of the code, if you must guarantee that no mutation happens to the data.