immutable.js

var a = {address: {postcode: 5085}} var b = Immutable.fromJS(a) var c = b.setIn(['address', 'suburb'], 'broadview').toJS(); // no error console.log(c); var d = Immutable.Map(a); var e = d.setIn(['address', 'suburb'], 'broadview').toJS(); // error invalid keyPath(…) Could someone explain the difference. Thanks, Samu Joseph In this example, var a = {address: {postcode: 5085}} var d = Immutable.Map(a); Here, d.get('address') is immutable . It's value cannot change to any other objects. We can only create a new Object from the existing object using the Immutable.Map.set() function of ImmutableJS.

class Event extends Immutable.Record { constructor(text) { super({text: text, timestamp: Date.now()}); } } Calling new Event() seems to return a constuctor function: new Event('started').toString() "function Record(values){ if(values instanceof RecordType){ return values;} if(!(this instanceof RecordType)){ return new RecordType(values);} if(!hasInitialized){ hasInitialized=true; var keys=Object.keys(defaultValues); setProps(RecordTypePrototype,keys); RecordTypePrototype.size=keys.length; RecordTypePrototype._name=name; RecordTypePrototype._keys=keys; RecordTypePrototype._defaultValues

I am used to computed properties in Ember Object Model . It's a convenient way to specify computed properties that depend on other properties. Say fullName depends on firstName and lastName , I can setup computed properties as a function computeProperties and call computeProperties each time I make a change. Example: function computeFullName(state) { const fullName = state.get('firstName') + state.get('lastName'); const nextState = state.set('fullName', fullName); return nextState; } function computeProperties(state) { const nextState = computeFullName(state); return nextState; } // store

Immutable object can be an instance of: Immutable.List Immutable.Map Immutable.OrderedMap Immutable.Set Immutable.OrderedSet Immutable.Stack mbh There is an open ticket to improve the API which is on the roadmap for 4.0. Until this is implemented, I suggest you use Immutable.Iterable.isIterable() ( docs ). Using instanceof is not reliable (e. g. returns false when different modules use different copies of Immutable.js) I have learned that using instanceof to determine wether object is Immutable is unsafe: Module A: var Immutable = require('immutable'); module.exports = Immutable.Map({foo: "bar

When working with plain JavaScript objects it's easy to change a deeply nested object property: people.Thomas.nickname = "Mr. T"; But with Immutable I have to go through each property's ancestors before I have a new people object: var thomas = peopleImmutable.get("Thomas"); var newThomas = thomas.set("nickname", "Mr .T"); peopleImmutable = peopleImmutable.set("Thomas", newThomas); Is there a more elegant way to write this? Maps in Immutable have a setIn method that makes it easy to set deep values: peopleImmutable = peopleImmutable.setIn(["Thomas", "nickname"], "Mr. T"); Or, using split to

I have researched on net about the benefits of immutablejs over Object.freeze() but didn't find anything satisfying! My question is why I should use this library and work with non native data structures when I can freeze a plain old javascript object? I don't think you understood what immutablejs offers. It's not a library which just turns your objects immutable, it's a library around working with immutable values. Without simply repeating their docs and mission statement , I'll state two things it provides: Types. They implemented (immutable) infinite ranges, stacks, ordered sets, lists, ...

I'm fairly new to React, Redux and ImmutableJS, and have run into some performance issues. I have a large tree structure of data, which I'm currently storing as a flat list in this structure: new Map({ 1: new Node({ id: 1, text: 'Root', children: [2,3] }), 2: new Node({ id: 2, text: 'Child 1', children: [4] }), 3: new Node({ id: 3, text: 'Child 2', children: [] }), 4: new Node({ id: 4, text: 'Child of child 1', children: [] }) }); While structuring it as a flat list makes updating nodes easy, I'm finding that interaction gets sluggish as the tree grows. Interaction includes being able to