Version tags are a pretty simple technique I’ve used with ReactJS to optimize rendering larger apps. This optimization does not add any dependency on an immutable data library. Right away I have to say that this is not something you want to be choosing all of the time. If you want to be able to use shouldComponentUpdate optimizations easily by default, or if you have any reason to be saving and replaying undo history, then you should seriously consider using an immutable data structure. But there are a couple of common reasons to skip that piece of architecture. First, If you simply cannot afford to load any more JavaScript after ReactJS and the other libraries you might already be using, then the convenience of ImmutableJS or a similar library might not justify the overhead to load it. And second, if it would be too difficult to learn and/or integrate ImmutableJS with your existing architecture, this is one alternative. In some ways it is much simpler, but in one important way it is more difficult to use.
If you want to do a very clean implementation of a flux-type architecture, your data might propagate down from a top-level “controller-view” through a whole big tree of React components. Each component in the tree will potentially render on every state change, so to avoid this you want certain nodes to be implementing shouldComponentUpdate and checking if their particular data has changed. The simplest way to do this is to flatten all props and check them one by one. While this can give a performance boost, the boilerplate required to do so can get ridiculous. ImmutableJS and similar libraries eliminate this problem by making the state an immutable data structure. Basically this means that every time a node in the state updates, that node is copied and a new reference is made to hold the new node, along with every node directly above it in the state tree. Then any component which only needs a particular state node to render can check if that reference has changed, and superfluous rendering can be easily skipped. Having the old nodes around also makes undo features trivial to add.
Here’s how version tags work. Instead of copying the node(s) that you need to be updating, you just change a version tag on those nodes. Then instead of checking an immutable reference, the components check if the version has changed to see whether to render. That’s it.
This means you’ll have to add a version tag to the same scope as each node of data you want to be able to optimize for, and it means you will have to manually update the version tag every time something in that node changes. This approach is a sort of middle ground optimization between checking every individual value type at one extreme, and working with and checking an immutable data structure at the other. However in some situations it has the potential to perform better than both.
As a simple example you might have an application that displays a list of clients and a list of appointments. You could add a version tag to each object in your state:
var _state = {
clients: [...],
clientsVersion: 1,
appointments: [...],
appointmentsVersion: 1
};
And then if you ever update something in appointments you’d do appointmentsVersion++; as well. The component that renders the appointments implements shouldComponentUpdate which just has to compare appointmentsVersion. Versions can be added to as many nodes of the tree as you like, to get the degree of optimization you need at the time.
Will updating versions all the time be in several ways less advantageous than using ImmutableJS? Absolutely. But it is a useful technique.
GusBook 