What are disadvantages to using immutable state in React?

Question

I have built my first React application with stateful stores the \"normal\" way, and now I am looking into using an immutable global state like used in the Este starterkit.<

Answer 1

I know the answer has already been accepted, but I find the primary disadvantage to be that you pass non-plain JavaScript objects into your component code, meaning you cannot use regular JavaScript property accessors when reading values from the Immutable objects passed in via props. Instead you have to use Immutable.js' read API. This is a significant trade-off. You cannot keep your use of Immutable.js contained where it belongs, in the store; it has now leaked itself throughout your entire application. This is a pain you may feel when Immutable.js is replaced by the next buzzy Immutability library that has it's own API or is able to use the native property accessors. Additionally, third party code will almost certainly expect plain old JavaScript Objects, so Immutable objects will need to be converted before passing them along. If you plan on introducing Immutable.js into an existing application, it will become unclear very quickly in your component code which props are Immutable and which are JS object, unless you are very disciplined and come up with a naming scheme or some other method that you are consistent with as you pass objects down the rendering chain.

Answer 2

One advantage of passing data through props is that you can utilize shouldComponentUpdate for more performant updates. If you assume data always comes from the parent (e.g. via props), you can effectively prevent a large portion of your component tree from having to rerender. Immutable values make this very nice as you can do reference equality checks in shouldComponentUpdate relatively high in your component hierarchy.

The only other disadvantage I've found when using immutable data with React is that the React developer tools don't work super well with them (they show you the immutable values' underlying data structure instead of a JS-friendly value).

Answer 3

1. Documentation. Some of the most voted questions/rants in SO are about trivial things like updating nested list items all because the documentation is more oriented towards an audience familiar with functional programming, which makes it less approachable to the rest.
2. Its not trivial to separate the model hierarchy knowledge from your components. I hate to do a this.state.getIn("[parent, child, index]") in a component because it increases the possibility of a model change breaking the component code. This is preventable by extensibility (more on that below) or through helper methods, but you certainly lose the simplicity of plain JS members.
3. A significant challenge I faced was to be able to serialize and de-serialize the state. The fromJS method supports custom revivers but they are a pita and require careful testing and maintenance.
4. The Record type is severely stunted by a debilitation called nesting. This is sad because it allows easier (in relative terms) extensibility, but encourages only a single level hierarchy. You cannot easily create nested records from JSON. This makes it difficult to mix them with regular immutable fromJS usage unless you use the above mentioned pita revivers. And did I mention how sad that is, given Records expose model properties as first class members, ensure model integrity and defaults.
5. And then there is extensibility. Try adding helpers around your immutable data models to abstract model hierarchy dependency in your components and you are up for a noticeable hurdle race. De-serializing becomes a bitter divorce battle. You would need to mess around with revivers, if Records are in the mix they will cry foul and so on. An easier extensibility mechanism would go a long way towards making my components code cleaner.
6. No documented best practices. Although this sits right with #1, I still should mention that the lack of good documentation prevents one to pick the best possible way of doing something. I am not sure if I should pick from using an updater, or forEach or setIn (and so on) to update an immutable structure. The methods don't cross-reference each other enough to let you know what alternatives are around.