Ah, immutability. Where to even begin.

Why do we want immutability?

Immutability severely reduces bugs in your code by limiting any outside modifications that you did not intend.

All objects in JavaScript are mutated via reference. Meaning if you do this:

var obj = {
  greeting: 'Hello!'
}

function someHelperFunction() {
    obj.greeting = 'Hola'
}

someHelperfunction();

console.log(obj.greeting) // Hola

Even though someHelperFunction() doesn't own the obj variable, it can still mutate it's property and it will be reflected anywhere that obj is used.

Immutability is a concept taken from functional programming languages. Instead of mutating the object's value, it uses functions to create a new object, modify that one, and return the resulting new object. Immutable mutations always return a copy of the previous object.

Let's take a functional approach to the above example.

var obj = {
    greeting: 'Hello!'
}

var obj2 = obj

function someHelperFunction(object) {
    var copy = { ...object }
    copy.greeting = 'Hola'
    return copy
}

obj = someHelperFunction(obj)

console.log(obj.greeting) // Hola
console.log(obj2.greeting) // Hello!

So this has a lot going on here but you can see we already have gained so many positive things. Let's break it down:

1. We removed the side effect from someHelperFunction. We turned it into a pure function which owns all of its state (no modifications to global vars). It makes a copy of the inputted object as to not modify the reference (using ES2015 object spread). It modifies the new object, and then returns it.

2. We can see exactly where obj changed, because we are reassigning its value via that function. In the first example, if it were a bigger codebase, we'd have to search through all of the code trying to find out where our variable is being mutated without us directly assigning it.

3. Another benefit added here was that we assigned obj2 equal to obj. If we had just mutated obj directly, our obj2 values all would have updated as well. This functional approach eliminated that side effect and now they both have their intended values.

4. This is just a bonus but pure functions are so easy to test. Given the same input, this function will return the same output every single time.

Anyway, it's late and I'm exhausted but I love talking about this topic so I thought I'd chime in. If this doesn't answer your question or is crazy hard to follow I'll come back in the morning and update it.

For the "What" part, I'd like to suggest this posts since immutable.js is almost same as persistent data structure in Clojure, which is well described: en.wikipedia.org/wiki/Persistent_data_structure hypirion.com/musings/understanding-persistent-vec…

Why should use? Well it's not necessary to use immutable.js . It's useful to build a uni-directional data-flow and make React components diffing faster. In JavaScript, a language designed with mutation at heart, using persistent data structure is not a perfect choice. If you are just learning, I would suggest ClojureScript. But if you are building large apps with React, immutable.js is a nice-to-have.

Not ImmutableJS, but immutable data in general. Immutable data is the first step in functional programming. It helps to keep your data in its integrity, protects your program from side effeects.

You don't need ImmutableJS. It's too heavy for regular usage.

The simplest way to ensure your data is immutable is Object.freeze. Another way, that I often use, is Object.defineProperty or Object.defineProperties with writable set to false. You may like to refer my old library "stabilize.js":

github.com/ndaidong/stabilize.js/blob/master/src/…