Question: Should I use immutable data structures

[remojansen]

Hi,

I'm considering doing something to prevent bad state mutations. The first thing that I though about was immutable but then I started to think about the potential performance implications.

Some immutable checks will decrease performance because they are adding some run-time overhead. At the same time using immutable could improve performance when used in places like shouldComponentUpdate:

shouldComponentUpdate: function(nextProps, nextState) {
  return this.props.value !== nextProps.value;
}

So my main question are:

1. Should I use immutable data structures?
2. Should I use immutable data structures in production?
3. Is the redux-immutable-state-invariant middleware a good alternative?

I was also trying to find out how to integrate immutable.js with Redux and I found two libraries:

• redux-immutablejs
• redux-immutable

Both libraries force you to use their custom implementation of combineReducers but there seems to be some problems with the reducers and middle-ware.

I have seem examples that use Redux + immutable.js without redux-immutable or redux-immutablejs so I'm not fully sure about those being really needed.

[gaearon]

1. If you are comfortable with something like Immutable.js, you can start using it right away. If you are not entirely familiar with it, it might be worth using plain objects (or something like seamless-immutable) first.
2. If you use them in development, surely you should use them in production. However if you only mean checks (like "immutable state invariant" project), they should be disabled in production.
3. Try it and let us know :-). It looks sensible so it probably is. But it should definitely be disabled in production.

Finally, you don't need any library to use Immutable with Redux. They just give you Immutable-first combineReducers. You can use it or you can write your own. Check their source code and you will see there is nothing fancy going on there. I'm not aware of any problems caused by them so I don't know what you are referring to.

[remojansen]

@gaearon thanks for answering!

I feel comfortable about using Immutable.js but I don't feel like I need it at all times. I work with some people that is just getting started with Redux and sometimes the new joiners perform some bad mutations. To prevent this I was considering using immutablejs. The problem is that once they get familiar with Redux we probably won't need it and it will affect performance.

That's why I was wondering if something like redux-immutable-state-invariant would suit my needs better.

[gaearon]

I work with some people that is just getting started with Redux and sometimes the new joiners perform some bad mutations. To prevent this I was considering using immutablejs.

Immutable still leaves plenty of pitfalls for beginners: they can put stuff as instance fields on immutable object, they can forget to fromJS() something and mix immutable with plain objects, some tools don’t log immutable objects nicely, etc.

The problem is that once they get familiar with Redux we probably won't need it and it will affect performance.

What will affect performance? If anything, Immutable should give you a better performance than plain objects. This is the main reason people like to use it.

That's why I was wondering if something like redux-immutable-state-invariant would suit my needs better.

No better way than to try and tell us. 😉 You can also create a similar middleware that would deep-freeze state and action objects.

[remojansen]

Thanks a lot for that 👍 I will comment on this in a few months from now to share how did it go 🍀