Comment by acemarke | Hacker News Reader

Comment by acemarke | Hacker News Reader

Parent Full thread

`setState` doesn't actually care whether you've mutated your data or updated it immutably. In fact, I just ran a quick test, and you can even directly mutate your state object and then call `this.setState({})`, and it will update. `setState` is basically a combination of "queue an update to `this.state`, and queue a re-render along with that". So, if you mutate `this.state` and then re-render, your render output would be "correct" because the state object was updated.

Where immutability really comes into play with React itself is optimizations via `shouldComponentUpdate`. The fastest way to determine if a component needs to update is shallow equality comparisons of current and next props/state, which requires that you do immutable data updates to produce new object references. Two good articles on the topic are [0] and [1].

[0] http://reactkungfu.com/2015/08/pros-and-cons-of-using-immuta...

[1] https://www.bennadel.com/blog/2903-why-should-i-care-about-i...

> setState doesn't actually care whether you've mutated your data or updated it immutably.

Not necessarily - if something downstream is looking at the values (such as a shouldComponentUpdate check), the first mutation may cause the current value to === the next value and prevent a render. I know you called this out as an "optimization" but you don't always know what's happening inside your components, especially if 3rd party libraries are involved.

That's what I was saying. The actual `setState()` function can be called with new references from immutable data, the same references that already existed but were mutated, or even no references at all if you mutated. So, literally, `setState()` does not care what process you used to potentially update data before calling it - it just applies a shallow merge of whatever object you passed in to the existing `this.state` object, and then queues a re-render. It's the _rest_ of your code that might care.

The primary reasons to actually update data immutably before calling `setState` are for easy and consistent implementation of `shouldComponentUpdate` / use of `PureComponent`, and general FP principles that immutability should be preferred over mutation.

Reply on news.ycombinator.com