Veröffentlicht am 18-02-2019

Redux Free gehen

Sobald Sie mit dem Schreiben einer React-Webanwendung beginnen, werden Sie einen globalen Zustandsverwaltungsmechanismus für erforderlich halten. Hier kommen fluxbasierte Lösungen wie Redux und MobX ins Spiel.

Oder ist es wirklich so?

Dies mag vor Jahrhunderten der Fall gewesen sein, aber nicht mehr. Bevor wir uns den Details zuwenden, werfen wir einen Blick auf Redux.

Der eine wahre König

Während der Flux-Kriege, als Dan Abramov Redux während seines Hot Reloading-Vortrags vorstellte, geschahen zwei Dinge: Das Publikum klatschte und dann….

Der große Flusskrieg endete - Redux krönte den einen wahren König !!!

Die Mördermerkmale, die in diesem Vortrag aufgedeckt wurden, waren die Einfachheit über Flux und Time Traveling. Redux wurde auch mit Middleware geliefert, was die Protokollierung, Prüfprotokolle und Alarmierung vereinfachte.

Sie wollen Datenabruf und Nebenwirkungen? Cool, hier sind Redux-Thunk oder Redux-Saga.
Sie möchten ein Formular verwalten? Cool, hier ist das Redux-Formular.
Sie möchten Routenänderungen mit Redux synchronisieren? Cool, hier ist React-Router-Redux.

Ich kann weitermachen und weiter…

Reagieren + Redux

Meiner Meinung nach wurde React ursprünglich unter Berücksichtigung der Unix-Philosophie entwickelt.

React bietet die Grundlage für die Implementierung deklarativer Benutzeroberflächen, und die Community erstellt Bibliotheken und Tools, die den unterschiedlichen Bedürfnissen und Geschmacksrichtungen entsprechen. React lieferte keine eindeutige Lösung für die Zustandsverwaltung (z. B. ähnlich wie bei Vuex Vuex). Ich denke, dass das Befolgen der Unix-Philosophie dem Wachstum von React mehr als geschadet hat. Etwas komplizierter ist der aktuelle Stand der Staatsführung.

Wenn Sie wirklich darüber nachdenken, war der Umgang mit dem Komponentenstatus mit React nicht der schwierige Teil. Das Teilen des Status zwischen Komponenten war etwas schwieriger. Am schwierigsten waren jedoch Nebenwirkungen.

Wie würden Sie einen API-Endpunkt aufrufen und eine darauf basierende Benutzeroberfläche darstellen?

Der idiomatische Ansatz bestand darin, den Anfangszustand im Konstruktor festzulegen, den Endpunkt in der Lebenszyklusmethode "componentDidMount" aufzurufen und dort den lokalen Status (mit this.setState) festzulegen. Basierend auf dem lokalen Status würden Sie schließlich die Komponente rendern. Die Dinge werden schwieriger, wenn Sie die Daten bei jeder Aktualisierung der Komponente erneut abrufen möchten, da Sie auch die Lifecycle-Methode componentDidUpdate implementieren müssen. Noch schwieriger wird es, wenn die abgerufenen Daten mit dem Status einer anderen Komponente gemeinsam genutzt werden. Daher war es absolut sinnvoll, Redux oder MobX als Grundgerüst einer React-Anwendung zu verwenden.

Warum also nicht Redux?

Redux füllte diese Lücke aus, führte aber auch eine Menge Umleitung in eine App ein.

Um beispielsweise dasselbe zu erreichen, brauchen wir:

  • Ein Minderer
    • Ein Aktionstyp
    • Ein Action-Schöpfer
    • Eine Kartenstatusfunktion und
    • Ein auf Thunk basierender Versand (oder eine Redux-Saga)
    • Ein Container zum Binden des Statusmappers und des Dispatchers an eine Komponente
    • Zu viel Mist für einen einfachen API-Aufruf.

      Was wäre, wenn wir einen Spinner zeigen wollten, während Daten abgerufen werden? Dann müssten wir dem Reduktionszustand eine neue Eigenschaft hinzufügen. Darüber hinaus müssen wir Tests schreiben. Jedes neue Modul, das wir schreiben, erfordert möglicherweise auch einen Test dafür.

      Stellen Sie sich vor, Sie machen das für jeden API-Aufruf ... !!!

      Aufgrund dieser Komplikationen ähnelte eine mit Redux erstellte React-App eher einer mit React erstellten Redux-App.

      Die Community entwickelte verschiedene Ansätze, um die Dinge einfacher zu machen. Ich selbst habe einen kleinen Rahmen um Redux und Redux Saga erstellt, um das Abrufen von Abrufen einfacher zu gestalten, indem eine Reihe fester Konventionen erzwungen wird. Es hatte nur einen Aktionstyp für alle Abrufaufrufe, und ein Schlüssel wurde mit der Aktion übergeben, um den Abrufaufruf eindeutig zu identifizieren. Dies ermöglichte es mir, eine einzige Saga und einen einzigen Reduzierer zu verwenden, um alle meine Abrufanrufe abzuwickeln. Die Handhabung der Abrufzustände wurde durch diesen einzigen Reduzierer einfacher.

      Ich habe ähnliche Anstrengungen gesehen, um solche von Redux eingeführten Umwege zu lösen. Ein beliebtes Beispiel sind Enten (https://github.com/erikras/ducks-modular-redux), um die Reduzierungen, Aktionstypen und Aktionen an einem Ort festzulegen.

      Aber dann fing ich an zu denken…

      Was ist der Sinn von Redux, wenn Sie Redux nicht tun?

      In der Tat warnte der Autor, Dan Abr-acadabr-amov, selbst vor Jahren vor diesem Thema.

      Schneller Vorlauf bis heute. Die Reaktion hat sich sehr verändert - auf eine gute Art und Weise.

      • Die neue Kontext-API ist angekommen.
        • Haken sind überall.
        • Der Abruf von Daten ist auf dem Weg.
        • Jetzt können diese Leckereien verwendet werden, um alle von Redux eingeführten Aufblähungen und Umleitungen auf moderne und skalierbare Weise zu ersetzen.

          Verstehen Sie mich nicht falsch, es gibt immer noch eine Menge Probleme, die mit Redux gelöst werden können, aber ich glaube, dass ~ 90% einer typischen React-App auf der Basis von

          • Umgang mit Shared State
            • Komplexe Statusaktualisierungen und
            • Datenabruf
            • In den folgenden Artikeln dieser Serie werde ich auf jeden dieser Aspekte eingehen und meine Argumente für eine Redux-freie Architektur aufzeigen.

              Autoren: Pubudu Dodangoda, Kenneth Ah Young

Siehe auch

So erstellen Sie Ihren ersten witzigen Chatbot mit SAP Conversational AI