javascript - meaning - immutable react js

Ventajas de utilizar immutable.js sobre los operadores Object.assign o spread

Question

Hasta ahora, la mayoría de las "repeticiones iniciales" y algunas publicaciones sobre reaccionar / redux que he visto fomentan el uso de immutable.js para abordar la mutabilidad. Personalmente Object.assign en los operadores Object.assign o spread para manejar esto, por lo que realmente no veo ventaja en immutable.js, ya que agrega aprendizaje adicional y se aleja un poco de las técnicas de vainilla js utilizadas para la mutabilidad. Estaba tratando de encontrar razones válidas para un cambio, pero no pude por lo tanto, estoy preguntando aquí para ver por qué es tan popular.

Answer 1

Creo que la principal ventaja de ImmutableJs es su velocidad y estructura de datos. Claro, también impone la inmutabilidad, pero deberías hacerlo de todos modos, así que eso es solo un beneficio adicional.

Por ejemplo, supongamos que tiene un objeto muy grande en su reductor y desea cambiar una parte muy pequeña de ese objeto. Debido a la inmutabilidad, no puede cambiar el objeto directamente, pero debe crear una copia del objeto. Lo hace copiando todo (en ES6 utilizando el operador de propagación).

¿Entonces, cuál es el problema? Copiar objetos muy grandes es muy lento. Las estructuras de datos en ImmutableJS hacen algo que se denomina compartición estructural donde realmente solo cambia los datos que desea. Los otros datos que no está cambiando se comparten entre los objetos, por lo que no se copian.

El resultado de esto son estructuras de datos altamente eficientes, con escrituras rápidas.

ImmutableJS también ofrece comparaciones fáciles para objetos profundos. Por ejemplo

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 

Sin esto, necesitarías algún tipo de función de comparación profunda, que también llevaría mucho tiempo, mientras que los nodos raíz aquí contienen un hash de toda la estructura de datos (no me cites sobre esto, así es como lo recuerdo). , pero las comparaciones son siempre instantáneas), por lo que las comparaciones son siempre O(1) es decir, instantáneas, independientemente del tamaño del objeto.

Esto puede ser especialmente útil en el método React shouldComponentUpdate , donde simplemente puede comparar los accesorios utilizando esta función de equals , que se ejecuta instantáneamente.

Por supuesto, también hay desventajas, si combina estructuras inmutables y objetos regulares, puede ser difícil saber qué es qué. Además, su base de código está llena de la sintaxis de JS, que es diferente de Javascript regular.

Otro inconveniente es que si no va a utilizar objetos profundamente anidados, será un poco más lento que los js antiguos, ya que las estructuras de datos tienen cierta sobrecarga.

Sólo mis 2 centavos.

Answer 2

Esto es todo acerca de la eficiencia.

Estructuras de datos persistentes

Una estructura de datos persistente mantiene las versiones anteriores de sí misma cuando se muta al generar siempre una nueva estructura de datos. Para evitar una clonación costosa, solo se almacena la diferencia con la estructura de datos anterior, mientras que la intersección se comparte entre ellos. Esta estrategia se llama compartir estructural. Por lo tanto, las estructuras de datos persistentes son mucho más eficientes que la clonación con Object.assign o el operador de difusión.

Desventajas de las estructuras de datos persistentes en Javascript

Desafortunadamente, Javascript no admite estructuras de datos persistentes de forma nativa. Esa es la razón por la que immutable.js existe y que sus objetos difieren mucho de los antiguos Object JavaScript. Esto lleva a un código más detallado y muchas conversiones de estructuras de datos persistentes a estructuras de datos nativas de Javascript.

La pregunta crucial

¿Cuándo los beneficios de la distribución estructural (eficiencia) de immutable.js superan sus desventajas (verbosidad, conversiones)?

Supongo que la biblioteca solo paga en grandes proyectos con numerosos y extensos objetos y colecciones, cuando la clonación de estructuras de datos completas y la recolección de basura se vuelve más costosa.

Answer 3

He creado las pruebas de rendimiento para múltiples bibliotecas inmutables, el script y los resultados se encuentran dentro de la asignación inmutable (proyecto GitHub) , lo que muestra que immutable.js está optimizado para operaciones de escritura, más rápido que Object.assign (), sin embargo, es más lento para las operaciones de lectura. A continuación se presenta el resumen de los resultados de los puntos de referencia:

-- Mutable
Total elapsed = 50 ms (read) + 53 ms (write) = 103 ms.

-- Immutable (Object.assign)
Total elapsed = 50 ms (read) + 2149 ms (write) = 2199 ms.

-- Immutable (immutable.js)
Total elapsed = 638 ms (read) + 1052 ms (write) = 1690 ms.

-- Immutable (seamless-immutable)
Total elapsed = 31 ms (read) + 91302 ms (write) = 91333 ms.

-- Immutable (immutable-assign (created by me))
Total elapsed = 50 ms (read) + 2173 ms (write) = 2223 ms.

Por lo tanto, si usar immutable.js o no dependerá del tipo de su aplicación y su relación de lectura a escritura. Si tiene muchas operaciones de escritura, immutable.js será una buena opción.

La optimización temprana es la raíz de todo mal

Idealmente, debe crear un perfil de su aplicación antes de introducir cualquier optimización de rendimiento, sin embargo, la inmutabilidad es una de las decisiones de diseño que deben decidirse con anticipación. Cuando comienza a usar immutable.js , debe usarlo en toda la aplicación para obtener los beneficios de rendimiento, ya que interoperar con objetos JS simples utilizando fromJS () y toJS () es muy costoso.

Answer 4

La ventaja de immutable.js es que impone un almacén de redux inmutable (puede olvidarse de extender o hacer un trabajo descuidado para proteger su tienda de modificaciones) y simplifica mucho los reductores en comparación con los operadores Object.assign o spread (ambos son superficial por cierto!).

Dicho esto, he usado redux + immutable en un gran proyecto de Angular 1.x y hay desventajas: problemas de rendimiento, no está claro qué es inmutable y qué no lo es, Angular no puede utilizar estructuras immutable.js en ng-repeat , etc. Sin embargo, no estoy seguro de reaccionar, me encantaría escuchar opiniones.

Answer 5

No se trata solo de ganancias de rendimiento a través de estructuras de datos persistentes. La inmutabilidad es una calidad altamente deseable en sí misma, ya que elimina completamente cualquier error causado por mutaciones accidentales. Además, es bueno tener estructuras de datos sanas con una API conveniente en Javascript, algo realmente utilizable, e immutable.js está muy por delante de los objetos y matrices de Vanillla, incluso con las recientes incorporaciones de ES6 y ES7. Es como jQuery: es tan popular porque su API es realmente genial y fácil de usar en comparación con la API DOM de vainilla (que es solo una pesadilla). Claro, puedes tratar de mantenerte inmutable con los objetos de vainilla, pero no debes olvidarte de Object.assign y array spread TODOS LOS TIEMPOS LIBRES, y con immutable.js simplemente no puedes equivocarte, cualquier mutación aquí es explícita

Answer 6

immutable.js te ofrece muchas utilidades que siempre devuelven un nuevo objeto.

ejemplo:

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

Para solo reaccionar / redux, personalmente creo que Object.assign es lo suficientemente poderoso, pero en algunos casos el uso de esa biblioteca podría ahorrarle algunas líneas de código.