javascript - 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.

• The state of all stores is kept together in a single immutable data structure
• Components have no state but access data in their render() based on a store getter function
• Stores are also stateless but mutate the global application state for their domain using a cursor.
• The top level app component listens for state changes, and re-renders the whole component tree.
• Components are implemented as "pure" meaning they use shouldComponentUpdate to efficiently figure out of they can be skipped in the re-rendering.

It simplifies the application structure in a few ways:

• Components don't listen to stores and also don't copy store data to their local state. They simply grab their store state on each render.
• The global state is always a snapshot of the whole application, making it easier to debug and adding features like undo trivial.
• The global state seems to simplify isomorphic rendering.

I only read positive things about using immutable data with React, and it is recommended to avoid state in components, so I wonder if there are any disadvantages. I figured there must be because otherwise I don't see why it isn't recommended as the way to structure React apps.

Immutability is new to me, so are there any caveats I should be aware of if I start using this approach in a complex real world app?

The only minor thing I can think of is the use of forceUpdate() as Este is using it, as I've read that it is a synchronous function. Morearty for example seems to defer the updates to the next animation frame in order to batch them, but I consider this an implementation detail / optimization and not some inherit downside of the immutable single state approach.

Answer 1

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.