2016-04-14 9 views
9

Jestem nowy w ImmutableJS. Moja aplikacja implementuje duże komponenty Redux Store &.Jaka jest najlepsza implementacja reakcji? ComponentUpdate with immutable.js

Popraw mnie jeśli się mylę:

  • Rozumiem, że korzyści z niezmiennej jest ochrona Flux Store oraz w celu uniknięcia niepotrzebnego vDom renderingu na składniku uzyskiwanie niezmienionych rekwizyty.
  • Aby skorzystać z lepszej wydajności renderowania za pomocą ImmutableJS, należy wdrożyć shouldComponentUpdate().

Jakie jest najlepsze wdrożenie tej funkcji?

ja już znalazłem kilka implementacje niego wszyscy używając shallowEqual() z pewnymi modyfikacjami:

  • Facebook wdraża shallowEqual dla React i bardziej sobie wyobrazić.
  • Firma Jurassix oferuje an implementation, która implementuje shallowEqualImmutable. Jest to funkcja z Facebooka, z tą różnicą, że funkcja is() jest zastąpiona funkcją podaną przez ImmutableJS. Pierwsza równość też jest inna.
  • Dan robi to samo z different shalllowEqual function, które implementuje części dwóch poprzednich implementacji.

Ktoś wie, jakiego wdrożenia powinienem użyć w moim przypadku? lub żaden i implementować specyficzne shouldComponentUpdate()? Jestem lekko zagubiony w tej kwestii.

Bardzo dziękuję za pomoc !!

+1

Czy obejrzałeś PureRenderMixin? https://facebook.github.io/react/docs/pure-render-mixin.html To również czyni płytkie porównanie, ale z ImmutableJs, które jest wystarczające. –

+0

Tak, PureRenderMixin faktycznie nazywa się 'shallowEqual' z Facebooka. to jest pierwszy punkt, o którym wspominam. Co masz na myśli mówiąc "to wystarczy"? –

Odpowiedz

5

Rozumiem, że korzyści z niezmiennej jest ochrona Flux Store i uniknąć niepotrzebnego renderowania vDom na składniku uzyskiwanie niezmienionych rekwizyty.

To nie jest tak naprawdę związane z niezmiennymi (jeśli masz na myśli bibliotekę). Na przykład można używać zwykłych obiektów i tablic z Redux, ale ponieważ Redux prosi o ich nieumiejętność, w większości przypadków uzyskuje się takie same korzyści. Tak więc biblioteka Immutable może zaoferować przyjemniejsze API do aktualizacji rzeczy niezmiennie, ale nie jest wymagana do optymalizacji wydajności, jeśli nie zmutujesz zwykłych obiektów lub tablic.

Aby skorzystać z lepszej wydajności renderowania za pomocą ImmutableJS, należy zaimplementować metodę shouldComponentUpdate().

Ponownie, nie jest to tak naprawdę związane z ImmutableJS, ale tak, aby skorzystać z niezmienności w rekwizytach, trzeba wdrożyć shouldComponentUpdate(). Jednak jeśli używasz Redux prawdopodobnie już używasz connect() z pakietu React Redux, który implementuje shouldComponentUpdate() dla ciebie w większości przypadków. Tak naprawdę nie trzeba pisać ręcznie dla wszystkich edytowanych komponentów connect().

Ktoś wie, których realizacja powinna używać w moim przypadku? lub none i implementować określoną metodę shouldComponentUpdate()?Jestem nieco zagubiony w tym punkcie.

Jeśli nie masz problemów z wydajnością, nie używaj ich. Reagowanie samo w sobie jest dość wydajne w większości przypadków, a na jego końcu connect() doda dobrą domyślną implementację shouldComponentUpdate().

W przypadku składników, które nie są connect() ed, ale nadal są często aktualizowane, proponuję użyć react-addons-shallow-compare. Jest on używany wewnętrznie przez PureRenderMixin, ale ponieważ mixiny nie są tak naprawdę używane w nowoczesnych interfejsach API React, oddzielna funkcja może być wygodniejsza.

Jeśli potrzebujesz specjalnej pomocy dla Immutable.is, możesz rzeczywiście użyć czegoś takiego jak shallowEqualImmutable. Rozumie niezmienne zbiory, ponieważ uważa, że ​​listy o tych samych wartościach są takie same. W tym momencie lepiej będzie profilować różne implementacje względem aplikacji, ponieważ szczegóły mogą się różnić w zależności od przypadku użycia.

Nie optymalizuj przedwcześnie, upewnij się, że jest to rzeczywisty problem przed jego rozwiązaniem.

+0

Masz również implementacje [kompilacji] (https://github.com/acdlite/reclose/blob/master/docs/API.md#pure) ('pure',' onlyUpdateForKeys', 'onlyUpdateForPropTypes') które umożliwiają korzystanie z komponentów wyższego rzędu, dzięki czemu można zachować kod w składni składnika funkcjonalnego bezstanowego. –

+0

@ Dan, bardzo dziękuję za szczegóły. Rozumiem, że 'shouldComponentUpdate()' i 'ImmutableJS' to dwie zupełnie różne rzeczy. Rozważa obie koncepcje razem, które jakoś mnie zwalniają. Ale myślę, że twoja odpowiedź bardzo pomaga. Uświadamiasz mi, że 'shouldComponentUpdate()' powinno używać 'react-addons-shallow-compare' dla zmiennych rekwizytów i' shallowEqualImmutable' dla niezmiennych pochodzących z ImmutableJS lib. –

+0

@Dan ,: i masz absolutną rację w tym punkcie: "W tym momencie lepiej byłoby wyprofilować różne implementacje przeciwko aplikacji, ponieważ szczegóły mogą się różnić w zależności od przypadku użycia". Redux-Form zmusza mnie do wdrożenia dobrej 'shouldComponentUpdate()', która nie wymaga użycia ImmutableJS. –

0

Użyłem też dużego sklepu Redux i odkryłem, że użycie Immutable.js może utrudnić dostęp do stanu, np. Nested2.getIn (['a', 'b', 'd']) vs nested2.abd; To, czego naprawdę potrzebuję, to upewnić się, że nie zmutuję stanu w moich reduktorach, i wciąż mogę sprawdzić równość używając === w metodzie shouldComponentUpdate().

Utworzono https://github.com/engineforce/ImmutableAssign, aby spełnić moje wymagania. Jest to światło waży niezmienny pomocnika, który obsługuje niezmienność i pozwala kontynuować pracę z POJO (Plain Old JavaScript Object), więc nasze reagują składniki można odczytać stan jak zwykle, np

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

przykład

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] 
Powiązane problemy