Is React's setState() guaranteed to create a new state object every time?

Question

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.

this is duplicate of this : https://stackoverflow.com/questions/35867038/what-the-difference-of-this-state-and-this-setstate-in-reactjs — eenagy, Aug 13 '17 at 03:19
you don't want to mutate this.state like in the second example, use this.setState always as advised in react docs — eenagy, Aug 13 '17 at 03: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, Aug 13 '17 at 03:43
you are right, it's not duplicate, mistake on my part about that — eenagy, Aug 13 '17 at 03:46

score 5 · Accepted Answer · answered Aug 13 '17 at 04:53

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 component. 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 componentDidUpdate() 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 component has updated only because of props change.

Indeed, I edited the question to make it clear that I meant to ask "is it guaranteed to be true if the update was triggered by `setState`". My bad. Thanks! — philraj, Aug 13 '17 at 05:37

score 4 · Answer 2 · answered Aug 13 '17 at 04:06

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.

Oops, I meant to ask if `nextState` will be a new object when `setState` is what triggered the update. Edited the question to reflect that. Thanks! — philraj, Aug 13 '17 at 05:41

Is React's setState() guaranteed to create a new state object every time?

2 Answers2