4 ms·

Oh right, immutable data structures are good for exactly this situation. I've been in mutation land for a while now. :) However, now I'm newly confused: Yes, I

Oh right, immutable data structures are good for exactly this situation. I've been in mutation land for a while now. :) However, now I'm newly confused: Yes, I'm proposing that the diff then get applied directly to the state by the Redux infrastructure, and I don't understand why that would break any important assumptions provided by Redux. Is there an example you could give of how this might create a problem?

RussianCow 8y ago
You would have to be much more disciplined with your approach. With Redux, if I store a reference to any part of the state, I am guaranteed that the value will never be changed by Redux itself (so, unless I manually mutate it, it is guaranteed to be frozen [0]). Because of this, I can do things like safely store a value off of the Redux state inside a component, and when the state changes, I can compare the new value against my stored value to see if it has changed. If you directly mutate state, then the reference would update in-place, so there is no way to compare changes locally without first making a copy. It also goes the other way: I can't accidentally change the state by mutating the object I get back. With your scheme, any "accidental" mutation on any part of the state will actually change the state. This opens up a whole world of bugs, because any time you want to store part of the state locally (inside a component, for instance), you have to remember to make a copy if you want to guarantee that no unwanted side effects occur. (Plus, getting into the convention of "everything is immutable" means you can generally be much more confident about passing objects around without fear of them being mutated unexpectedly.) Edit: Now that I think about it, what you are proposing sounds pretty similar to MobX.[1] You should check it out if you haven't already. I personally strongly prefer Redux for the reasons I mentioned, but it's a pretty solid library either way. [0]: In development, it's very easy to enforce this with Redux by simply calling `Object.freeze` on the state in the root reducer, completely preventing the state object from being mutated. [1]: https://mobx.js.org/ https://mobx.js.org/

RussianCow 8y ago

You would have to be much more disciplined with your approach. With Redux, if I store a reference to any part of the state, I am guaranteed that the value will never be changed by Redux itself (so, unless I manually mutate it, it is guaranteed to be frozen [0]). Because of this, I can do things like safely store a value off of the Redux state inside a component, and when the state changes, I can compare the new value against my stored value to see if it has changed. If you directly mutate state, then the reference would update in-place, so there is no way to compare changes locally without first making a copy. It also goes the other way: I can't accidentally change the state by mutating the object I get back. With your scheme, any "accidental" mutation on any part of the state will actually change the state. This opens up a whole world of bugs, because any time you want to store part of the state locally (inside a component, for instance), you have to remember to make a copy if you want to guarantee that no unwanted side effects occur. (Plus, getting into the convention of "everything is immutable" means you can generally be much more confident about passing objects around without fear of them being mutated unexpectedly.) Edit: Now that I think about it, what you are proposing sounds pretty similar to MobX.[1] You should check it out if you haven't already. I personally strongly prefer Redux for the reasons I mentioned, but it's a pretty solid library either way. [0]: In development, it's very easy to enforce this with Redux by simply calling `Object.freeze` on the state in the root reducer, completely preventing the state object from being mutated. [1]: https://mobx.js.org/ https://mobx.js.org/