curiousreacter's comments

Well, I'm thinking that Redux would apply the diffs to the state destructively, so I'm not sure why we would need to "constantly" reapply them in order to recreate the latest state... we would simply have the latest state on-hand already. But if we're in a context where a lot of rewinding and fast-forwarding of state is happening for some reason, or where these state diffs can't easily be reversed/inverted, then I can see why this would be inefficient.

Hmm, but reducers are supposed to return references to new state objects, right? So clearly something more substantial than a pointer has to be created/duplicated.

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?

Side question: Isn't it grossly inefficient that in Redux, you have reducers that return an entirely new state object? Wouldn't it be better to return some kind of data that represents just the diff you intend to make, like {op: INCREMENT, arg: 1, key: "Foo"}?