Meta

Effective Application State Management - Lesson 4

Keep your state simple II - Flatten the state

Here we go with the fourth lesson of my series about "Effective Application State Management". In this lesson I will - once again - emphasize the simplicity of an application state. If you followed (and understood) the previous lesson you may have noticed that it can be quite tedious to update immutable states.

Honestly, I "robbed" it from the normalizr.js example, 'coz I'm a lazy guy

Assuming we adopt the concept of immutable states, and we want to update such state. Fortunately, the (currently) most notable immutability libraries ImmutableJS, seamless-immutable, provide a kind of navigation feature to change deeply nested values of JSONs. So, let's change the author's name of a state made immutable with seamless-immutable

state = Immutable.setIn(state, ["author", "name"], "Elmar");

This is not pretty complicated, yet...but how can I change the array of the commenters? Basically, you need to create a mutable copy, change that array and reset the value in your immutable structure:

Here's a nice discussion on how one can update elements of an array using seamless-immutable.

You can imagine that more complex structures, e.g. arrays in arrays can get really difficult to deal with. My advice is to keep your data structure as simple as possible (even if not immutable). Focus on what you really need and keep your objects flat. Unfortunately, the reality can be cruel and you cannot change the API you use. In that case, you would need to map the state to a simpler structure and eventually need to convert it back when passing to the server. You could do it manually, or use a tool like normalizr.js. Anyway, this seems somewhat ponderous, and you might think "Fuck off, Immutability", but as always everything comes at a cost. Do you want to guarantee that your shared data doesn't change accidentally (by your teammates)? Do you need the performance on object comparison? You need to evaluate the risks and the costs to reduce them. But I tell you, that using Immutability is kind of an architectural decision, that needs to be made in an early project stage. The later the refactoring towards Immutability is done the more time consuming it is.