Qual è la migliore implementazione di react shouldComponentUpdate con immutable.js

Question

Sono nuovo a ImmutableJS. La mia app implementa grandi componenti Redux Store &.

mi corregga se sbaglio:

• Capisco che i benefici di Immutabile è quello di proteggere Flux Store e per evitare inutili VDOM rendering on componente ottenere puntelli invariati.
• Per beneficiare di prestazioni di rendering migliori con ImmutableJS, è necessario implementare shouldComponentUpdate().

Qual è la migliore implementazione di questa funzione?

ho già trovato diverse implementazioni di esso, il tutto utilizzando shallowEqual() con alcune modifiche:

• Facebook implementa shallowEqual per reagire e più mi immagino.
• Jurassix offre an implementation che implementa shallowEqualImmutable. È la funzione di Facebook tranne che la funzione is() è sostituita da quella fornita da ImmutableJS. Anche la prima uguaglianza è diversa.
• Dan fa la stessa cosa con uno different shalllowEqual function che implementa parti delle due precedenti implementazioni.

Qualcuno sa quale implementazione dovrei usare nel mio caso? o nessuno e implementare lo specifico shouldComponentUpdate()? Sono leggermente in perdita su questo punto

Grazie mille per qualsiasi aiuto !!

Answer 1

Capisco che i vantaggi di Immutable è proteggere Flux Store ed evitare inutili rendering di vDom sul componente che ottiene puntelli invariati.

Questo non è realmente correlato a Immutable (se si intende la libreria). Ad esempio, puoi usare gli oggetti e gli array semplici con Redux, ma poiché Redux ti chiede di non mutarli mai, ottieni quasi gli stessi benefici nella maggior parte dei casi. La libreria così immutabile può offrire un'API migliore per l'aggiornamento delle cose immutabilmente, ma non è necessaria per l'ottimizzazione delle prestazioni se non si muta gli oggetti semplici o gli array.

Per beneficiare di prestazioni di rendering migliori con ImmutableJS, deve essere implementato shouldComponentUpdate().

Ancora una volta, non proprio legati a ImmutableJS, ma sì, di beneficiare di immutabilità in oggetti di scena, avresti bisogno di implementare shouldComponentUpdate(). Tuttavia, se si utilizza Redux probabilmente si utilizza già connect() dal pacchetto React Redux che implementa shouldComponentUpdate() per la maggior parte dei casi. Quindi non hai davvero bisogno di scriverlo a mano per qualsiasi componente di connect() ed.

Qualcuno sa quale implementazione dovrei usare nel mio caso? o nessuno e implementare specifici shouldComponentUpdate()?Sono leggermente in perdita su questo punto

Se non si verificano problemi di prestazioni, non utilizzare neanche. Reagire da solo è abbastanza performante nella maggior parte dei casi, e un connect() in cima ad esso aggiungerà una buona implementazione di default di shouldComponentUpdate().

Per i componenti che non sono connect() ed ancora vengono aggiornati di frequente, suggerirei di utilizzare react-addons-shallow-compare. È utilizzato da PureRenderMixin internamente ma poiché i mixin non sono realmente usati nelle moderne API React, una funzione separata può essere più comoda.

Se si desidera supporto speciale per Immutable.is, si può effettivamente utilizzare qualcosa come shallowEqualImmutable. Comprende meglio le raccolte Immutable, in quanto considera le liste degli stessi valori uguali. A questo punto, sarebbe meglio profilare diverse implementazioni sulla tua app, in quanto le specifiche possono variare in base al tuo caso d'uso.

Non ottimizzare prima del tempo, assicurarsi che questo sia un problema reale prima di risolverlo.

Answer 2

Stavo anche utilizzando un grande Redux Store e ho scoperto che l'utilizzo di Immutable.js può complicare l'accesso allo stato, ad esempio nested2.getIn (['a', 'b', 'd']) vs nested2.abd; Quello di cui ho veramente bisogno è di assicurarmi di non mutare lo stato nei miei riduttori, e di essere ancora in grado di controllare l'uguaglianza usando === nel metodo shouldComponentUpdate().

Ho creato https://github.com/engineforce/ImmutableAssign per soddisfare i miei requisiti. Si tratta di una luce pesare aiutante immutabile, che supporta immutabilità e consente di continuare a lavorare con POJO (Plain Object Vecchio JavaScript), così i nostri Reagire componenti possono leggere lo stato, come al solito, per esempio,

return newState.a.b.d === oldState.a.b.d; 

Esempio,

var iassign = require("immutable-assign"); 

var o1 = { a: { b: { c: [[{ d: 11, e: 12 }], [{ d: 21, e: 22 }]], c2: {} }, b2: {} }, a2: {} }; 

// 
// Calling iassign() to push new item to o1.a.b.c[1] 
// 
var o2 = iassign(
    o1, 
    function (o) { return o.a.b.c[1]; }, // get property to be updated 
    function (c) {      // update select property 
    c.push(101); 
    return c; 
    } 
); 


// o2.a.b.c[1][1] === 101 
// o1 is not modified 

// o2 !== o1 
// o2.a !== o1.a 
// o2.a.b !== o1.a.b 
// o2.a.b.c !== o1.a.b.c 
// o2.a.b.c[1] !== o1.a.b.c[1] 

// o2.a2 === o1.a2 
// o2.a.b2 === o1.a.b2 
// o2.a.b.c2 === o1.a.b.c2 
// o2.a.b.c[0] === o1.a.b.c[0] 
// o2.a.b.c[0][0] === o1.a.b.c[0][0] 
// o2.a.b.c[1][0] === o1.a.b.c[1][0]