3 ms·
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 upda
by guscost 11y ago
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 library. However it does require extra boilerplate and manual updates to version tags each time something changes, and it can cause confusion if you forget to update a version tag or accidentally update the wrong one. Anyway, it is one alternative, but if you don't have a compelling reason not to use ImmutableJS for optimization I'd probably go with that. Of course it is perfect for undo/redo functionality too if that is a requirement.
- rymohr 11y agoYour 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.
- guscost 11y agoIt's one of the ideas for shouldComponentUpdate that I wrote about here, but it's not described in a lot of detail: http://guscost.com/2015/05/27/react-js-and-flux-ideas-for-practical-applications/ 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.