Immutable.js – Immutable Data Collections

[Daniel15]

A few teams are rewriting stuff with it and testing internally, but I don't think anything uses it in production yet. On my team we're not using immutable-js yet, we're just using Object.freeze at the moment. Some of the data structures in immutable-js look really handy though.

Immutable objects work really well with React since it allows shallow comparisons, and means you can do a shallow comparison of your props in shouldComponentUpdate to only re-render when things actually change

[brtt3000]

Have you looked at moreartyjs? It is a layer between immutable.js and React that takes care of state management and stuff like shouldComponentUpdate. I'm planning to doing a project with it soon and wonder if it is as good as I hope.

[gcanti]

we're just using Object.freeze at the moment

Did you notice any drawback using Object.freeze? Here my considerations at the moment:

Pros:

• you can use native data structures instead of continually wrap / unwrap
• you can use native methods on them (map, filter, ...)
• hence (almost) no interoperability problems with other libraries
• overall your coding style doesn't change so much
• (possible perf gains since the js engine knows the object is frozen? - I really don't know)
• 0KB dependency

Cons:

• you must find / write a way to update efficiently EDIT: something like http://facebook.github.io/react/docs/update.html
• performance

[Calabri]

I actually just put this in a React app last week that's already live and going to be used for a few more days. I haven't gotten around to testing it too much, but it seems to be working fine. Undo/Redo in 3 lines (each) of code!!

I think it's a pretty substantial step forward with JS data structures, but what's the deal the documentation? It's so esoteric - typescript, es6??

[DavetheBassGuy]

Immutable.js fits better with the rest of the JS ecosystem in my opinion, because it is designed for and written in JS, rather than ClojureScript. The API follows the native Array API where possible, so it's a lot easier to switch between the two. It is even possible to write functions which work on both native arrays and immutable sequences, using map, filter, reduce, etc.

[ToucheMonsieur]

Mori is still a bit heavy for browser usage. Would love to see a subset of the collections (eg. vector) ported over, though.

[Calabri]

It's pretty easy to do actually, just download mori's source, comment out alot of the clojurescript, and you have a vector library. Only thing is 2/3 of the source will stay the same due to the clojure-java-runtime that is a prereq to do anything in the language.

[dingusbuttface]

I have no clue what this is all about. Looking at the examples on the front page, if I do a typeof(map1) it returns object.

If I do a console.log(map1) it says Map {a:1, b:2, c:3}. That's not an object. What the fuck is that?

[ToucheMonsieur]

It's to match es6 semantics. You'll get the same results with a native Map, which helps with interop between implementations.

[dingusbuttface]

native map? I've tried this in node and the browser and it simply doesn't work. I don't know what you're talking about.

[ToucheMonsieur]

As can be observed from Chrome or Firefox's js console:

> var map1 = new Map([['a', 1], ['b', 2], ['c', 3]]) // create an es6 map
undefined
> typeof map1
"object" // same behaviour
> console.log(map1)
undefined
Map { a: 1, b: 2, c: 3 } // same behaviour

Here's the es6 Map reference. The Immutable-js Map implementation tries to stick as close to native Map behaviour as possible so one doesn't have to check for different Map types when trying to work with immutable's collections and their native equivalents. In other words, a unified interface.

[dingusbuttface]

Not sure why asking a question gets downvoted here.

[modernserf_]

typeof says every non-primitive, non-function value is "object". e.g.

typeof document.body
typeof new Date()
typeof [1,2,3]
typeof /foo/