Da ich weiter in die Implementierung von redux + react in eine ziemlich komplexe App komme, die von vielen API-Anfragen zum Laden einer einzelnen Seite abhängig ist, habe ich Probleme zu entscheiden, ob es besser ist, eine einzelne Container-Komponente am Anfang der Seite zu haben welches alles asynchrone Zeug handhabt und Requisiten zu dummen Komponenten durchlässt, vs mehrere Container-Komponenten haben, die sich nur mit den Daten beschäftigen, die sie benötigen, sowie die benötigten Daten holen. Ich bin zwischen diesen beiden Mustern hin und her gegangen und habe festgestellt, dass sie Vor- und Nachteile haben:
Wenn ich eine einzelne Container-Komponente an die Spitze stelle:
isFetching reps und fetchSomeDependency() können an einer Stelle ausgeführt werden. Hier ist ein visuelles Beispiel für das Problem, das die requisiten Abhängigkeiten zeigt:
%Vor% Wie Sie sehen können, müssen sich <MyModal /> und <MyModalContent /> jetzt mit Requisiten beschäftigen, die nichts damit zu tun haben, da ein Modal wiederverwendbar sein sollte und nur mit den stilistischen Qualitäten von ein Modal.
Zuerst schien das oben genannte gut, aber sobald ich zu mehr als 100 Komponenten kam, fühlte sich alles sehr verworren an, und ich fand die Komplexität dieser Top-Level-Containerkomponenten für meinen Geschmack zu hoch, wie die meisten von ihnen sehen Die App, an der ich gerade arbeite, hängt von Antworten von 3+ API-Anfragen ab.
Dann habe ich beschlossen, mehrere Container auszuprobieren:
mapStateToProps und mapDispatchToProps sind spezifischer für den Zweck der Komponente, in der sie sich befindet. isFetching state an sich behandeln. Dies erhöht die Komplexität, die in dem Muster, in dem es in einer einzelnen Container-Komponente behandelt wird, nicht erforderlich ist. Das Hauptproblem besteht also darin, dass ich, wenn ich einen Container verwende, diese unnötige Komplexität in den Komponenten zwischen dem Stammcontainer und den Blattkomponenten bekomme. Wenn ich mehrere Container verwende , bekomme ich mehr Komplexität in den Blatt-Komponenten und am Ende mit Schaltflächen, die sich um isFetching kümmern müssen, obwohl eine Schaltfläche davon nicht betroffen sein sollte.
Ich würde gerne wissen, ob jemand einen Weg gefunden hat, beide Nachteile zu vermeiden, und wenn ja, was ist die "Faustregel", der Sie folgen, um dies zu vermeiden?
Danke!
Redux-Autor Dan Abramov schlägt vor, dass Sie Container-Komponenten verwenden, wenn Sie sie brauchen. Das heißt, sobald Sie zu viel Requisiten Verkabelung bekommen haben, btw. Komponenten ist es Zeit, Container zu verwenden.
Er nennt es einen "laufenden Prozess des Refactoring".
Siehe diesen Artikel: Ссылка
Wie ich es schon immer gesehen habe, sind Ihre Container an der obersten Stelle einer logischen Komponentengruppe anders als Ihrer root / app-Komponente.
Wenn wir also eine einfache Such-App haben, die Ergebnisse anzeigt und annehmen lässt, dass die Komponente Heichy so ist
%Vor% Ich würde Search und Results redux bewusst auf Container setzen. Weil die Reaktionskomponente zusammensetzbar sein soll. Möglicherweise haben Sie andere Komponenten oder Seiten, die Results oder Search anzeigen müssen. Wenn Sie das Abrufen und Speichern von Daten an die Stamm- oder App-Komponente delegieren, werden die Komponenten voneinander abhängig. Dies macht es schwieriger, wenn Sie Änderungen implementieren müssen, jetzt müssen Sie alle Orte ändern, die sie verwenden.
Die Ausnahme dazu ist wahrscheinlich, wenn Sie die Logik zwischen den Komponenten wirklich eng gekoppelt haben. Selbst dann würde ich sagen, dann sollten Sie einen Container erstellen, der Ihre eng gekoppelten Komponenten umhüllt, da sie nicht ohne einander realistisch verwendet werden können.
Ich würde nicht einmal in Erwägung ziehen, einen einzelnen Containeransatz zu verwenden. Es negiert praktisch alle Vorteile von redux. Es besteht keinerlei Notwendigkeit für ein Zustandsverwaltungssystem, wenn sich alle Zustände an einem Ort befinden und alle Rückrufe an einer Stelle sind (Wurzelkomponente).
Ich denke, dass es eine dünne Linie gibt, um zu gehen. Ich mache eine App, wo ich ungefähr 5 Wochen (Teilzeit) dabei bin und es sind bis zu 3000 Zeilen. Es hat 3 Ebenen der Ansicht Verschachtelung, ein Routing-Mechanismus, den ich selbst implementiert, und Komponenten, die mehr als 10 Ebenen der Verschachtelung sind, die den Zustand ändern müssen. Ich habe grundsätzlich einen Redux Container für jeden großen Bildschirm und es funktioniert wunderbar.
Wenn ich jedoch auf meine "clients" -Ansicht klicke, bekomme ich einen Client-Eintrag, der in Ordnung ist, da meine Client-Ansicht sich in einem redux-Container befindet und die Liste der als Props übergebenen Clients erhält. Wenn ich jedoch auf einen Client klicke, zögere ich wirklich, einen weiteren Redux-Container für das Profil des einzelnen Kunden zu erstellen, da es nur eine zusätzliche Stufe ist, um Requisiten zu übergeben. Es scheint, dass Sie abhängig vom Umfang der App Requisiten bis zu 1-2 Ebenen nach dem Redux-Container weitergeben wollen. Wenn es mehr ist, erstellen Sie einfach einen weiteren Redux-Container. Andererseits, wenn es eine noch komplexere App ist, dann könnte das Mischen von manchmal unter Verwendung von Redox-Containern und einigen anderen Zeiten, die sie nicht verwenden, für die Wartbarkeit sogar noch schlechter sein. Kurz gesagt, meine Meinung versucht, reduktive Container wo immer möglich zu minimieren, aber definitiv nicht auf Kosten von komplexen Propellerketten, da dies der Hauptgrund für die Verwendung von redux ist.
Tags und Links reactjs redux react-redux