The State of Immutability

Maciej Sikora
Dec 30, 2017 · 8 min read
Image for post
Image for post

About immutable data structures in JavaScript

In JavaScript, and many different languages, an assign statement works in two ways. For primary types (string, number, bool) assignment is passing the value, for complex types (objects) it is passing the reference(memory pointer). For complex types, any change will impact all occurrences because they really are only pointers to the same place. In the effect only primary types are immutable and can be safely changed, everything beyond primary types is mutable by default.

You should care, because the trust matters

Using mutable structures is a reason of the trust deficit. Mutation can be done in every code part with the access to the reference.

Image for post
Image for post
Image for post
Image for post

Few words about mutation

The opportunity of mutation provides no guaranty that something will stay unchanged. The worst scenario takes place when some structure is used in separate parts of the application, then any mutation in one component can create a bug in the other one. Such bug is really hard to track, because the source of the problem lies out of the scope of the failure. This is an example of a bad side effect.

Mutation is a cause of side effects

Side effect is anything which has impact on the outside of the current scope. If many parts of the code are dealing with the same reference then any change will impact all the parts. Side effects are bad, of course those unwanted ones, because code starts to be tightly coupled, code fragments instead of following single responsibility rule, are doing uncontrolled things outside their scope, they have impact on wider application context . Touching outside is always risky and has unpredictable consequences. When a bug will be found the questions will be risen — Where it was changed? What exactly was changed? Who also have access to the reference? But no history of change is available and questions can’t be easily answered.

Mutation provides only current state

When one reference is being many times changed, there is no history of these changes. No access to the previous state. Changing the object attributes is really rewriting the memory, old values are lost. The problem related to lack of the knowledge about changes is growing with number of places having access to the same mutable structure. It stays unknown how the structure is changing in the time.

Image for post
Image for post
Transformation car object into bike object— no parking spot monitoring!

Mutation is a cause of unpredictable state

If mutation procedure contains many steps, many attributes are being changed then it is fairy possible that procedure can brake in the middle. In such case, the state needs to have rollback to previous valid version, or if not the state will be left in unknown shape. An unknown and unpredictable state can turn into a crash in a place where this structure is consumed.

On the other hand mutation reuse the memory and is fast

Yes that is true, mutation is reusing the memory. Mutation is beneficial for performance and memory usage. But we are in 21-century, memory is cheap and in micro scale of the front-end development it does not matter if some object will be copied or not. No risk that our immutable copies will impact the performance. Garbage collector will clean not used references for us, so no worries about memory leaks or unnecessary memory occupying.

Image for post
Image for post
We have plenty of memory

Place Oriented Programming — PLOP

The term presented by Rich Hickey exactly capture the sense of using mutability. If guarantee about value not exists, then our object is only a pointer to the place in the memory, nothing more. Object was created in a shape A, but during the code execution it was transformed into a shape B, C, D and so on. Variables are representing memory not values.

Image for post
Image for post

Immutability is about values

Image for post
Image for post
Immutable structure vs Mutable structure

Value Oriented Programming — VOP

Contrary to PLOP, VOP is about values only. Code is operating on values not on pointers in the memory. Anything representing different value should be separated structure. The value remains unchanged from its creation until its destruction. Every pure functional language is value oriented.

Any difference should be reflected in the new value

Change doesn’t mean mutation, change means — generate new version of the state which reflects the change. But is it applicable to all cases? This is were some developers, also me, have problems with immutability. The problem starts when exists something big, like a big collection of data, and only small change needs to be done. In such case creating new structure feels wrong, it feels that the memory is used in very non effective way. Why I need to create the whole new structure of the data, if really only single element needs to be added or one field needs to be changed?

Image for post
Image for post

Value Oriented Programming in JavaScript

VOP can be implemented in JavaScript. As said before JavaScript has no immutable structures, but immutability can be achieved by principles and rules.

Freeze your objects

Object.freeze method give opportunity to block the object from further mutation.

Create new instance instead of doing changes

Use immutable data structures

JavaScript has no immutable structures out of box but there are third party implementation of such. The most popular are Immutable.js and mori. Both are base on trie data structure which is kind of search tree structure. Such structures allows for very efficient way of creating new instances without copying.

Image for post
Image for post

Is immutability bound to the functional programming

No is not. VOP can be used in other programming paradigms. Nowadays experts and evangelist of Object Oriented Programming also are talking about immutable and stateless objects. Here VOP gives the same benefits as in functional programming. Object without state or object with immutable state gives guarantee and trust for all parties consuming it. Immutable objects are amplifying single responsibility rule because of the need of passing all dependencies into the constructor. Immutability blocks any state change during object live cycle. In other words you are sure that object stays in unchangeable state from beginning to the end.

Image for post
Image for post

Are you ready for immutability?

All things considered — immutability can be achieved by rules and principles. JavaScript doesn’t have immutability builded in, spread operator and external libs can easily help in implementing it though. If immutability is about rules, then everything is in the developer hands. If you see the value of value, then from this moment, the mutation should be gone in your application.

DailyJS

JavaScript news and opinion.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store