When do you get to write `a.b = c` in react? Not with `setState`
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...
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.
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.
As far as I understand it with redux you end up having all of your application's state in the store. Unless you split it?
> Using local component state is fine. As a developer, it is your job to determine what kinds of state make up your application, and where each piece of state should live. Find a balance that works for you, and go with it.
Some common rules of thumb for determining what kind of data should be put into Redux:
> - Do other parts of the application care about this data?
> - Do you need to be able to create further derived data based on this original data?
> - Is the same data being used to drive multiple components?
> - Is there value to you in being able to restore this state to a given point in time (ie, time travel debugging)?
> - Do you want to cache the data (ie, use what's in state if it's already there instead of re-requesting it)?
I've seen some people say that you should put literally every single value in your app into Redux. You certainly _can_ do that, but I would see it as overkill. I'm much more pragmatic about it - put it into Redux if it makes sense to, per the rules of thumb in the FAQ.
> > - Do other parts of the application care about this data? > - Do you need to be able to create further derived data based on this original data? > - Is the same data being used to drive multiple components? > - Is there value to you in being able to restore this state to a given point in time (ie, time travel debugging)? > - Do you want to cache the data (ie, use what's in state if it's already there instead of re-requesting it)?
Won't having half your state outside the store and the other half inside add unneeded complexity and make your code even more difficult to read?
But, as I said, it's totally up to you to decide what lives where :)
Of course, once you need to access a piece of state from outside that component you should probably move it to the store. But until then you are just creating unnecessary complexity by cluttering global state.
And it usually isn't anything as sane as half in the store and half in one other place.
It's like 70% in the store, and 5% in component#1, and 8% in component#2, and 16% in component#3 (duplicating some stuff from component#1 and sorta duplicating some stuff from component#2 with some notes that someone should refactor all this and move those to redux) and the rest of it is only god knows where.
And then there is some hard to track down UI bug because using setState() turns out to be really much slower than you think it is going to be.
But Redux is so boilerplatey and heavy handed that it made sense in each individual case to the original coder/reviewer to not use it.