I have just started a React-Redux project using Immutable.js and am considering switching it over to this as I can see a lot of advantages in the compatibility with JS data. What downsides do you think I would encounter after switching?
I wrote a long Reddit comment a while back that describes the reasons why I advise that people _not_ use Immutable.js [0].
As a quick summary:
- It doesn't magically improve perf the way some people think it will. It does make easier to use the standard shallow equality implementation of `shouldComponentUpdate`, and can be faster at copying/updating very large objects. However, many people use `toJS()` to extract values, and that is absolutely bad for perf (especially if you call it in `mapState`).
- You either have to use its API everywhere in your codebase, or spend a lot of time encapsulating it to keep your components unaware of its existence.
- It can be harder to debug the contents of the objects.
I'm not sure about specific downsides for using Seamless-Immutable.
My React/Redux links list has a section of articles that discuss the pros and cons of using Immutable.js for performance [1]. I've also got a section on use of immutable data in general [2], including some articles that talk about how to actually use Immutable.js in your app, and articles on using plain JS data immutably.
I actually misread your question a bit at first - I originally thought you were asking about switching _to_ Immutable.js, not away from it. I realized that before I posted it, and decided my answer was still relevant to the aspect of "why someone might want to switch away from Immutable.js". So, in that sense it's adding context to the reasoning behind your question.
As I said, I'm not aware of specific downsides to using Seamless-Immutable. It seems like a good balance of enforced immutability in development via freezing and replacement of mutation methods, and compatibility with standard JS object/array notation and usage.
The main thing I can think of is that it will add all it's internal methods to your objects, which restricts which properties you can use – eg, "update", "merge" etc. This isn't usually an issue but we happened to have some policy objects with the same property names.
It also doesn't play nicely with Flow unless you use the static syntax.
Performance was the main reason we switched over. We found using Immutable objects to be the key to a performant UI when using something like React that's diffing your props every render loop.
