Freeze the state tree in dev?

[gaearon]

Should we deep-Object.freeze the state tree in development? I don't know how much of a perf hit that is.
It's hard for people to write mutation-free code from the first try so we might as well help them.

[emmenko]

Is there a way maybe to validate that and log a warning?

Using Object.freeze you have to make sure every nested object gets also "frozen". Or maybe use immutables? :)

[gaearon]

We could use something like https://github.com/substack/deep-freeze

[ooflorent]

Sounds like a good idea.

[emmenko]

Let's try it then 👍

[dariocravero]

👍

[gaearon]

If somebody wants to test this in a branch please do.

[leoasis]

I think it would be better to do what @emmenko suggests. We could deep clone the state after each dispatch and before dispatching we can check if the state is deeply equal to that previously cloned state, and if not, throw a warning, or an error directly. We can also verify that the new state returned by each dispatch is a brand new object. Since it's only for dev it shouldn't matter that much with regards to performance. In any case, we can provide a way to disable that check.

[gaearon]

Yeah, we could do that too. Would such cloning still work with ImmutableJS?

[leoasis]

We can make it work with Immutable, I don't think any out of the box cloning library works with it though.

[gaearon]

Perhaps we could bail out if we see Immutable (since it already guarantees immutability). Not sure.

[leoasis]

If noone is already working on this I'm willing to give it a try

[johanneslumpe]

Late to the party but this is a good idea to catch subtle bugs and late-night coding session issues.

[acdlite]

How about we only do this if the state is a plain object? If it's anything else (e.g. Immutable.js) we trust the user knows what they're doing.

[emmenko]

Yes, we can try like this and see how it goes.

[gaearon]

Let's continue the discussion in #138.