React-Redux: Sollten alle Komponentenzustände im Redux Store aufbewahrt werden

Angenommen, ich habe einen einfachen Schalter:

Wenn ich auf die Schaltfläche klicke, wechselt die Farbkomponente zwischen Rot und Blau

Ich könnte dieses Ergebnis erzielen, indem ich so etwas mache.

index.js

Button: onClick={()=>{dispatch(changeColor())}}
Color: this.props.color ? blue : red

container.js

connect(mapStateToProps)(indexPage)

action_creator.js

function changeColor(){
 return {type: 'CHANGE_COLOR'}
}

reducer.js

switch(){
case 'CHANGE_COLOR':
return {color: true}

Aber das ist verdammt viel Code, um etwas zu schreiben, das ich mit jQuery, einigen Klassen und einigen CSS in 5 Sekunden hätte erreichen können ...

Ich denke also, was ich wirklich frage, ist, was mache ich hier falsch?

Redux ist hauptsächlich für den "Anwendungsstatus" vorgesehen. Das heißt, alles, was mit Ihrer Anwendungslogik zu tun hat. Die darauf erstellte Ansicht spiegelt diesen Zustand wider, muss diesen Zustandscontainer jedoch nicht ausschließlich für alles verwenden, was er tut.

Stellen Sie einfach folgende Fragen: Ist dieser Status für den Rest der Anwendung wichtig? Werden sich andere Teile der Anwendung basierend auf diesem Status anders verhalten? In vielen kleineren Fällen wird dies nicht der Fall sein. Nehmen Sie ein Dropdown-Menü: Die Tatsache, dass es geöffnet oder geschlossen ist, hat wahrscheinlich keine Auswirkungen auf andere Teile der App. Die Verkabelung mit Ihrem Geschäft ist wahrscheinlich übertrieben. Es ist sicherlich eine gültige Option, bringt Ihnen aber keine wirklichen Vorteile. Du bist besser dran this.state, es einen Tag zu benutzen und zu nennen.

Wird in Ihrem Beispiel die Farbe dieser Schaltfläche umgeschaltet, um einen Unterschied in anderen Teilen der Anwendung zu bewirken? Wenn es sich bei einem Großteil Ihrer Anwendung um eine Art globales Ein- / Ausschalten handelt, gehört es definitiv in den Store. Wenn Sie jedoch nur auf eine Schaltflächenfarbe umschalten, wenn Sie auf die Schaltfläche klicken, können Sie den Farbstatus lokal definiert lassen. Das Klicken auf die Schaltfläche kann andere Auswirkungen haben, die einen Aktionsversand erfordern. Dies unterscheidet sich jedoch von der einfachen Frage, welche Farbe sie haben soll.

Versuchen Sie im Allgemeinen, Ihren Anwendungsstatus so klein wie möglich zu halten. Sie müssen nicht alles hineinschieben . Tun Sie es, wenn Sie müssen, oder es macht sehr viel Sinn, etwas dort zu behalten. Oder wenn es Ihnen das Leben mit Dev Tools erleichtert. Aber überladen Sie seine Bedeutung nicht zu sehr.

Redux FAQ: Organisationsstatus
Dieser Teil des offiziellen Redux-Dokuments hat Ihre Frage gut beantwortet.

Die Verwendung des lokalen Komponentenstatus ist in Ordnung . Als Entwickler ist es Ihre Aufgabe, zu bestimmen, welche Arten von Status Ihre Anwendung ausmachen und wo jeder Status leben soll. Finden Sie eine Balance, die für Sie funktioniert, und machen Sie mit.

Einige allgemeine Faustregeln für die Festlegung, welche Art von Daten in Redux eingefügt werden sollen:

• Interessieren sich andere Teile der Anwendung für diese Daten?
• Müssen Sie in der Lage sein, weitere abgeleitete Daten basierend auf diesen Originaldaten zu erstellen?
• Werden dieselben Daten verwendet, um mehrere Komponenten anzutreiben?
• Ist es für Sie von Wert, diesen Status zu einem bestimmten Zeitpunkt wiederherstellen zu können (dh Zeitreise-Debugging)?
• Möchten Sie die Daten zwischenspeichern (dh den aktuellen Status verwenden, wenn er bereits vorhanden ist, anstatt ihn erneut anzufordern)?

Zum Hervorheben des großartigen Links von @ AR7 und weil sich dieser Link vor einiger Zeit verschoben hat:

Verwenden Sie Reagieren für einen kurzlebigen Status, der für die App global nicht wichtig ist und nicht auf komplexe Weise mutiert. Zum Beispiel ein Umschalten in einem UI-Element, ein Formulareingabestatus. Verwenden Sie Redux für Zustände, die global wichtig sind oder auf komplexe Weise mutiert sind. Zum Beispiel zwischengespeicherte Benutzer oder ein Post-Entwurf.

Manchmal möchten Sie vom Redux-Status in den React-Status wechseln (wenn das Speichern in Redux umständlich wird) oder umgekehrt (wenn mehr Komponenten Zugriff auf einen Status haben müssen, der früher lokal war).

Als Faustregel gilt: Tun Sie, was weniger umständlich ist.

Dan Abramov: https://github.com/reactjs/redux/issues/1287#issuecomment-175351978

Ja, es lohnt sich , den gesamten Komponentenstatus in Redux zu speichern . Wenn Sie dies tun, profitieren Sie von vielen Funktionen von Redux wie dem Debuggen von Zeitreisen und wiederholbaren Fehlerberichten. Wenn Sie dies nicht tun, können diese Funktionen völlig unbrauchbar werden .

Jedes Mal, wenn Sie keine Änderung des Komponentenzustands in Redux speichern, geht diese Änderung vollständig aus dem Stapel der Redux-Änderungen verloren und die Benutzeroberfläche Ihrer Anwendung ist nicht mehr mit dem Speicher synchron. Wenn dies für Sie nicht wichtig ist, fragen Sie sich, warum Sie Redux überhaupt verwenden. Ihre Anwendung wird ohne sie weniger komplex sein!

Aus Leistungsgründen möchten Sie möglicherweise auf this.setState()alles zurückgreifen, was viele Aktionen wiederholt auslösen würde. Beispiel: Das Speichern des Status eines Eingabefelds in Redux jedes Mal, wenn der Benutzer einen Schlüssel eingibt, kann zu einer schlechten Leistung führen. Sie können dies lösen, indem Sie es wie eine Transaktion behandeln: Sobald die Benutzeraktion "festgeschrieben" ist, speichern Sie den endgültigen Status in Redux.

In Ihrem ursprünglichen Beitrag wird erwähnt, dass der Redux-Weg "verdammt viel Code zum Schreiben" ist. Ja, aber Sie können Abstraktionen für allgemeine Muster wie den lokalen Komponentenstatus verwenden.