react-boilerplate: Immutable.js is not a general purpose solution

@kof @mxstbr maybe this middleware makes sense for extra protection. But I like the approach of just using immutable everywhere. Seems like a mature solution.

What about using redux-immutable-state-invariant to enforce immutable Redux state and getting rid of ImmutableJS?

ok, so there is

• https://github.com/buunguyen/redux-freeze
• https://github.com/leoasis/redux-immutable-state-invariant

i think we should choose redux-freeze because it is very lean and simple (15 sloc)

cc @kof @mxstbr

https://www.npmjs.com/package/redux-freeze

That’s exactly my question haha

redux-freeze doesn’t really solve that, does it?

No, it doesn’t, but it doesn’t have to.

The reason why

shouldComponentUpdate(nextProps) {
  return !this.props.equals(nextProps);
}

works is because we never mutate the state (and therefore the props that get passed to the component by connect). Because of that, we can easily determine if props have changed by this.props.equals(nextProps), because whenever the state changes, we generate a new object, meaning we can just do a shallow equal instead of a full deep equal.

Immutable.js is just a library that makes working with immutable data structures easier (and doesn’t allow them to be mutated). redux-freeze on the other hand is just a store enhancer that throws an error if we mutate the state - its purpose is to warn us if we accidentally mutate the state.

So - for

shouldComponentUpdate(nextProps) {
  return !this.props.equals(nextProps);
}

to work we don’t need Immutable.js or redux-freeze at all - they are both useful, but have nothing to do with it directly.

For what I understood, it doesn’t. Otherwise they wouldn’t advise to use it only in dev mode.

That’s for a different reason. redux-freeze uses deep-freeze internally to make the state immutable and detect if we try to mutate it. That costs ofc a bit performance, and, as explained above, is not necessary for the app to work - its just for reporting mutations to us so we can fix them. Therefore, we don’t want it in production. It’s like the hot reload middleware - it’s useful for development, but has no reason to exist in production.

Does that help @mxstbr and @FezVrasta ?

@FezVrasta We moved from ImmutableJS to seamless-immutable, but now considering using plain js structures (+lodash) and redux-freeze. Not because there is something bad with both libraries, but we just can’t see the value, that they bring to us.

Exact answer to this issue https://youtu.be/5pMDd1t2thc?t=2509

If you start with something small, start with principle of immutability (basically pure js and cloning), once immutability becomes too hard without tools, introduce a library

I agree, but it is also important to guard yourself from accidental mutation. So, if no library is used to provide immutability, the you need at least deep freeze your state in dev mode.

Any consideration for seamless-immutable as a middle ground?

For what I understood, it doesn’t. Otherwise they wouldn’t advise to use it only in dev mode.

The question here is whether immutable.js should be the default. Of course we can add and remove stuff any time.