Vorteile der Verwendung von immutable.js über Object.weisen Sie oder spread-Betreiber

Hier geht es um Effizienz.

Persistente Datenstrukturen

Einer persistenten Datenstruktur hält früheren Versionen von sich selbst, wenn es mutiert ist immer gedeckt, eine neue Datenstruktur. Um zu vermeiden, teure Klonen nur der Unterschied zum vorherigen Datenstruktur gespeichert ist, in der Erwägung, dass die Schnittmenge zwischen Ihnen geteilt. Diese Strategie nennt strukturellen teilen. Daher persistente-Daten-Strukturen sind viel effektiver als das Klonen mit Object.assign oder der spread-operator.

Nachteile von persistenten Datenstrukturen in Javascript

Leider von Javascript keine Unterstützung für die persistente Datenstrukturen nativ. Das ist der Grund, immutable.js vorhanden ist und dass die Objekte unterscheiden sich stark von plain old Javascript Objects. Dies führt zu mehr verbose code und eine Menge von Bekehrungen von persistenten Datenstrukturen, um native Javascript-Datenstrukturen.

Die entscheidende Frage

Wann wird die Vorteile von immutable.js's structural sharing (Effizienz) ist größer als seine Nachteile (Ausführlichkeit, conversions)?

Ich denke, die Bibliothek zahlt nur in großen Projekten mit zahlreichen und umfangreichen Objekten und Sammlungen, beim Klonen der gesamten Daten, Strukturen und Müllabfuhr wird teurer.

Ich denke, der wesentliche Vorteil von ImmutableJs ist in seinen Datenstrukturen und Geschwindigkeit. Sicher, es setzt auch der Unveränderlichkeit, aber Sie sollten dies tun sowieso, also das ist nur ein zusätzlicher Vorteil.

Zum Beispiel, sagen, Sie haben ein sehr großes Objekt in Ihrem reducer und Sie ändern möchten, zu einem sehr kleinen Teil des Objekts. Wegen der Unveränderlichkeit, die Sie nicht ändern können das Objekt direkt, sondern erstellen Sie eine Kopie des Objekts. Sie tun, indem Sie kopieren alles (in ES6 mit dem spread-operator).

Wo ist also das problem? Kopieren von sehr großen Objekten sehr langsam. Datenstrukturen in ImmutableJS tun etwas namens strukturellen teilen, wo du wirklich nur die Daten ändern, die Sie wollen. Die anderen Daten, die Sie ändern sich nicht gemeinsam zwischen den Objekten, so dass es nicht kopiert wird.

Das Ergebnis dieses hoch effizienten Datenstrukturen, mit schnell schreibt.

ImmutableJS bietet auch einfache Vergleiche für Tiefe Objekte. Zum Beispiel

const a = Immutable.Map({ a: Immutable.Map({ a: 'a', b: 'b'}), b: 'b'});
const b = Immutable.Map({ a: Immutable.Map({ a: 'a', b: 'b'}), b: 'b'});

console.log(a.equals(b)) //true 

Ohne diese, würden Sie brauchen eine Art von tiefen-Vergleich-Funktion, das würde auch viel Zeit in Anspruch nehmen, in der Erwägung, dass der root-Knoten, die hier enthalten einen hash der gesamte datastructure (don ' T zitieren Sie mich auf dieser, das ist, wie ich es in Erinnerung habe, aber die Vergleiche sind immer instant), so dass Vergleiche sind immer O(1) d.h. sofortige, unabhängig von der Größe des Objekts.

Dies ist besonders nützlich, Reagieren die shouldComponentUpdate Methode, wo man nur vergleichen Sie die Requisiten mit dieser equals Funktion, die ausgeführt wird, sofort.

Natürlich gibt es auch Nachteile, wenn Sie mischen immutablejs Strukturen und regelmäßige Objekte, kann es schwierig sein, zu sagen, was was ist. Auch die codebase ist übersät mit den immutableJS syntax, die unterscheidet sich von regulären Javascript.

Ein weiterer Nachteil ist, dass, wenn Sie nicht gehen, um tief verschachtelte Objekte, es ist ein bisschen langsamer ist als plain old js, da die Datenstrukturen haben einigen overhead.

Just my 2 cents.

immutable.js gibt Ihnen eine Menge von Dienstprogrammen, die immer wieder ein neues Objekt.

Beispiel:

var Immutable = require('immutable');
var map1 = Immutable.Map({a:1, b:2, c:3});
var map2 = map1.set('b', 50);
map1.get('b'); //2
map2.get('b'); //50

Nur für reagieren /redux finde ich persönlich das Objekt.zuweisen ist mächtig genug, aber in einigen Fällen die Nutzung der Bibliothek könnte sparen Sie ein paar Zeilen code.