Earlier quoted context omitted.
I've actually used a plain state object with UUID version tags saved at each node that needs to be optimized. Whenever the store updates that node, it also updates the version tag with a new UUID. Then shouldComponentUpdate just checks whether the version tag is different before rendering. For my purposes this optimizes at least as well as ImmutableJS, and there is no overhead from loading and using a dedicated libra…
Your approach sounds interesting. Ever write about it? The undo / redo gains of ImmutableJS quickly vanish when you're working with remote data and the leaked getters aren't fun. A little UUID juggling is worth it if it allows my components/reducers to work with plain old javascript objects and still get fast shouldComponentUpdates.
http://guscost.com/2015/05/27/react-js-and-flux-ideas-for-pr...
One of these days I'll put up another piece on Flux/React, and an example application to demonstrate an approach that doesn't have a lot of dependencies (not even ES6, for example).
Also I have not run into any pitfalls using ImmutableJS yet apart from the extra overhead, so thanks for the heads up.