在ImmutableJS中更新列表中的对象

Question

I am a little confused by the functionality of ImmutableJS when working with an array of objects. The following example shows that even though the List x is immutable, I can still modify properties of objects inside the list both with and without using Immutable List's update() function.

My question is, why would I use Immutable if I can still modify the contents of my objects? I expected this module to protect me from that. I realize that I will not be able to add or remove entire objects to/from the list, but that doesn't fully protect me from modifying the list, which when working with a list in React state, I do not want to be able to do.

The other interesting thing I noticed is that when I directly modify the name after first performing the update, x.get(0).name and y.get(0).name are both changed. I thought that the resulting list from update() would not contain references to the same objects in the list.

How and why is ImmutableJS really helping me in this case?

var x = Immutable.List.of({name: 'foo'});
console.log(x.get(0).name);

var y = x.update(0, (element) => {
  element.name = 'bar';
  return element;
});
console.log(x.get(0).name);
console.log(y.get(0).name);

x.get(0).name = 'baz';
console.log(x.get(0).name);
console.log(y.get(0).name);

Output:
foo
bar
bar
baz
baz

https://jsfiddle.net/shotolab/rwh116uw/1/

Example of @SpiderPig's suggestion of using Map:

var x = Immutable.List.of(new Immutable.Map({name: 'foo'}));
console.log(x.get(0).get('name'));

var y = x.update(0, (element) => {
  return element.set('name', 'bar');
});
console.log(x.get(0).get('name'));
console.log(y.get(0).get('name'));

Output:
foo
foo
bar

While the last example shows what I was trying to accomplish, ultimately I don't know if I will end up using Map or List or even ImmutableJS at all. What I don't like is the alternate APIs (especially for a mapped object). I am afraid that when I hand my project off to another developer, or as others join the team, using these immutable objects and lists correctly will completely fall apart without the proper governance.

Maybe this is more of a commentary on React, but if React intends for the state to be immutable, but it's not enforced, it just seems to me like this will end up a mess in a project that is moving quickly with multiple developers. I was trying my best not to mutate the state, but forgetting that modifying an object in a list/array is very easy mistake to make.

Answer 1

The immutable.js does not provide true immutability in the sense that you could not modify the Objects directly - it just provides API which helps you to maintain the immutable state.

The update -function should return completely new version of the indexed object:

var y = x.update(0, (element) => {
  return { name : "bar"};
});

But doing something like this is a big no-no: x.get(0).name = 'baz';

Here is a much better explanation of the whole thing than I could ever write: https://github.com/facebook/immutable-js/issues/481

The point of immutable.js is to allow re-use of objects which are not modified, which consumes less memory and gives a good practical performance.

There is also library "Seamless immutable", which freezes the objects, so that they can not be modified, but this comes with some performance penalty under JavaScript: https://github.com/rtfeldman/seamless-immutable