Gibt es irgendwelche Nachteile, nur den gesamten Zustand zu Komponenten von Redux zu übergeben?

Question

Ich benutze die ES6 (?) Dekoratoren mit Redux und React. In vielen Beispielen sehe ich Leute, die explizit festlegen, welche Store-Artikel als Requisiten übergeben werden. In einigen Beispielen sehe ich Leute mit Spread-Attribute einfach alles durch wie passieren:

@connect((store) => { 
    return { 
    ...store 
    } 
}) 
export default class SomeComponent extends React.Component { 
... 

Ist es in Ordnung zu tun, nur dies für jede Komponente, oder sollten Sie Kirsche die Requisiten spezifisch für diese Komponente wählen?

Answer 1

Es gibt einen enormen Performance-Nachteil, da bei jedem Action-Versand react-redux die mapStateToProps jeder verbundenen Komponente ausführt und dann die alten Requisiten flach mit den neuen Requisiten vergleicht. Wenn Änderungen vorgenommen werden, wird die umschlossene Komponente erneut gerendert. Wenn Sie den gesamten Store übergeben, wird jede verbundene Komponente bei jeder ausgeführten Aktion erneut gerendert.

Answer 2

Ja, da sind. Es ist nicht so einfach zu lesen, welche Requisiten die Komponente tatsächlich benutzt. Außerdem können sich Requisiten, die Sie nicht in der Komponente verwenden, ändern und unnötige erneute Rendervorgänge auslösen.

Answer 3

Ich ging durch beide Paradigmen der Redux-Entwicklung.

• Jede Komponente erhält alle Aktionen und alle Status.
• Nur die Container/Eltern/Basisseiten erhalten Sie alle Aktionen/Zustand
  • die Kinder gibt nur das, was es

Was muss ich gefunden habe. Ja, es gibt einen Leistungseinbruch, denn wenn jede Komponente über jede Statuseigenschaft verfügt, stellen Sie sich vor, Sie ändern einen Zustandswert - jede einzelne Komponente erhält dieses Update - ob sie es benötigt oder nicht. Ständige Aktualisierungen

All night you are woken up: 


Imagine your dog wakes up at 3:30am every night to go outside to pee. 
Imagine your neighbor wakes up at 4am for work. 
Imagine your other neighbor wakes up at 4:30 am for work. 
Imagine your family wakes up at 5:15 am for work. 

And you need to get up at 6:00am work. 

In all diesen Szenarien werden Sie geweckt. Im Laufe der Zeit, wie effektiv wirst du bei der Arbeit sein? Du wirst müde, träge usw. sein ...

Jetzt stell dir vor - du kannst nur fragen, aufgewacht zu werden, wenn du es sein musst? Und nicht all die anderen Zeiten, die nichts mit dir zu tun haben?

So denke ich darüber. Lassen Sie also Ihre Kinderkomponenten nur über die Dinge wissen, die ihnen wichtig sind.

Also, ich habe normalerweise die Container-Seite/Eltern - weiß über alles - und geben Sie, was es braucht.

Vorbehalt - Ich habe festgestellt, es gibt einige Fälle, in denen eine Kindkomponente (aus welchem ​​Grund auch immer) über fast alles wissen muss. jede einzelne Sache bis auf mehreren Ebenen für mich vorbei - auch Auswirkungen auf die Kinder, Sie auf dem Weg passieren ...

parent ---> 
    child (just care about one thing) ---> 
     child (just care about one thing)---> 
      child (I want alot of stuff) 

Ich mag an das Zeug alles auf die Kinder, alle, nicht passieren vor allem, wenn diese Kinder weiter oben auf der Leiter ist es egal. Also, in diesem tiefsten Kind gebe ich alles von Anfang an - und gebe nichts weiter.

Das ist ein bisschen ein Performance-Hit, ich nehme, um den Code sauberer zu machen.

Aber insgesamt, geben Sie nicht alle Komponenten alles.Macht einen großen Leistungsunterschied über die Zeit hinweg und wenn Ihre Anwendung wächst.