Warum Redux über Facebook Flux verwenden? [geschlossen]

Ich habe diese Antwort gelesen , Boilerplate reduziert , einige GitHub-Beispiele angeschaut und sogar ein wenig Redux ausprobiert (ToDo-Apps).

Soweit ich weiß, bieten offizielle Redux Doc-Motivationen Profis im Vergleich zu herkömmlichen MVC-Architekturen. ABER es gibt keine Antwort auf die Frage:

Warum sollten Sie Redux über Facebook Flux verwenden?

Ist das nur eine Frage der Programmierstile: funktional oder nicht funktional? Oder ist die Frage in Fähigkeiten / Entwicklungswerkzeugen, die sich aus dem Redux-Ansatz ergeben? Vielleicht skalieren? Oder testen?

Habe ich recht, wenn ich sage, dass Redux ein Fluss für Menschen ist, die aus funktionalen Sprachen kommen?

Um diese Frage zu beantworten, können Sie die Komplexität der Motivationspunkte von Implementation Redux für Flux mit Redux vergleichen.

Hier sind Motivationspunkte aus offiziellen Redux Doc-Motivationen :

1. Umgang mit optimistischen Updates ( soweit ich weiß, hängt es kaum vom 5. Punkt ab. Ist es schwierig, es in Facebook Flux zu implementieren? )
2. Rendern auf dem Server ( Facebook Flux kann dies auch. Gibt es Vorteile im Vergleich zu Redux? )
3. Abrufen von Daten vor dem Durchführen von Routenübergängen ( Warum kann dies in Facebook Flux nicht erreicht werden? Was sind die Vorteile? )
4. Hot Reload ( Mit React Hot Reload ist es möglich . Warum brauchen wir Redux? )
5. Rückgängig / Wiederherstellen-Funktionalität
6. Irgendwelche anderen Punkte? Wie anhaltender Zustand ...

Redux Autor hier!

Redux unterscheidet sich nicht so sehr von Flux. Insgesamt hat es die gleiche Architektur, aber Redux ist in der Lage, einige Komplexitätsprobleme zu lösen, indem es die funktionale Zusammensetzung verwendet, bei der Flux die Rückrufregistrierung verwendet.

Es gibt keinen grundlegenden Unterschied in Redux, aber ich finde, dass es bestimmte Abstraktionen einfacher oder zumindest möglich macht, sie zu implementieren, die in Flux schwer oder unmöglich zu implementieren wären.

Reduziererzusammensetzung

Nehmen Sie zum Beispiel die Paginierung. Mein Beispiel für den Flux + React Router behandelt die Paginierung, aber der Code dafür ist schrecklich. Einer der Gründe, warum es schrecklich ist, ist, dass Flux es unnatürlich macht, Funktionen in Geschäften wiederzuverwenden. Wenn zwei Speicher die Paginierung als Reaktion auf unterschiedliche Aktionen verarbeiten müssen, müssen sie entweder von einem gemeinsamen Basisspeicher erben (schlecht! Sie sperren sich in ein bestimmtes Design ein, wenn Sie die Vererbung verwenden) oder eine extern definierte Funktion aus dem aufrufen Event-Handler, der irgendwie auf den privaten Status des Flux-Stores angewendet werden muss. Das Ganze ist chaotisch (obwohl definitiv im Bereich des Möglichen).

Andererseits ist bei Redux die Paginierung dank der Reduktionszusammensetzung natürlich. Es handelt sich um Reduzierungen, sodass Sie eine Reduzierungsfabrik schreiben können , die Paginierungsreduzierer generiert, und diese dann in Ihrem Reduziererbaum verwenden können . Der Schlüssel, warum es so einfach ist, liegt darin, dass in Flux die Geschäfte flach sind, aber in Redux können Reduzierungen über die funktionale Zusammensetzung verschachtelt werden, genau wie React-Komponenten verschachtelt werden können.

Dieses Muster ermöglicht auch wunderbare Funktionen wie das Rückgängigmachen / Wiederherstellen ohne Benutzercode . Können Sie sich vorstellen, Undo / Redo in zwei Codezeilen in eine Flux-App einzufügen? Kaum. Mit Redux ist es dank des Zusammensetzungsmusters des Reduzierers wieder möglich. Ich muss hervorheben, dass es nichts Neues gibt - dies ist das Muster, das in Elm Architecture, das selbst von Flux beeinflusst wurde , entwickelt und ausführlich beschrieben wurde.

Server-Rendering

Die Leute haben mit Flux gut auf dem Server gerendert, aber da wir 20 Flux-Bibliotheken haben, die jeweils versuchen, das Rendern von Servern „einfacher“ zu machen, hat Flux möglicherweise einige Ecken und Kanten auf dem Server. Die Wahrheit ist, dass Facebook nicht viel Server-Rendering macht, daher waren sie nicht sehr besorgt darüber und verlassen sich auf das Ökosystem, um es einfacher zu machen.

Im traditionellen Flux sind Geschäfte Singletons. Dies bedeutet, dass es schwierig ist, die Daten für verschiedene Anforderungen auf dem Server zu trennen. Nicht unmöglich, aber schwer. Aus diesem Grund empfehlen die meisten Flux-Bibliotheken (sowie die neuen Flux-Utils ) jetzt, Klassen anstelle von Singletons zu verwenden, damit Sie Speicher pro Anforderung instanziieren können.

Es gibt immer noch die folgenden Probleme, die Sie in Flux lösen müssen (entweder selbst oder mithilfe Ihrer bevorzugten Flux-Bibliothek wie Flummox oder Alt ):

• Wenn Geschäfte Klassen sind, wie erstelle und zerstöre ich sie mit dem Dispatcher pro Anfrage? Wann registriere ich Geschäfte?
• Wie hydratisiere ich die Daten aus den Filialen und rehydriere sie später auf dem Client? Muss ich dafür spezielle Methoden implementieren?

Zugegeben, Flux-Frameworks (nicht Vanilla Flux) haben Lösungen für diese Probleme, aber ich finde sie überkompliziert. Zum Beispiel Flummox fragt Sie zu implementieren serialize()und deserialize()Ihre Geschäfte in . Alt löst dieses Problem, indem es bereitstellt, takeSnapshot()dass Ihr Status automatisch in einem JSON-Baum serialisiert wird.

Redux geht nur noch weiter: Da es nur einen einzigen Speicher gibt (der von vielen Reduzierern verwaltet wird), benötigen Sie keine spezielle API, um die (Wieder-) Flüssigkeitszufuhr zu verwalten. Sie müssen die Geschäfte nicht „spülen“ oder „hydrieren“ - es gibt nur ein einziges Geschäft, und Sie können den aktuellen Status lesen oder ein neues Geschäft mit einem neuen Status erstellen. Jede Anforderung erhält eine separate Speicherinstanz. Lesen Sie mehr über das Rendern von Servern mit Redux.

Auch dies ist ein Fall von etwas, das sowohl in Flux als auch in Redux möglich ist, aber Flux-Bibliotheken lösen dieses Problem, indem sie eine Menge APIs und Konventionen einführen, und Redux muss es nicht einmal lösen, weil es dieses Problem nicht in der erster Platz dank konzeptioneller Einfachheit.

Entwicklererfahrung

Ich hatte eigentlich nicht vor, Redux zu einer beliebten Flux-Bibliothek zu machen - ich schrieb es, als ich an meinem ReactEurope-Vortrag über das heiße Nachladen mit Zeitreisen arbeitete . Ich hatte ein Hauptziel: es möglich zu machen, den Reduzierungscode im laufenden Betrieb zu ändern oder sogar die Vergangenheit zu ändern, indem Aktionen durchgestrichen werden, und zu sehen, wie der Zustand neu berechnet wird.

Ich habe keine einzige Flux-Bibliothek gesehen, die dies kann. React Hot Loader lässt Sie dies auch nicht zu - tatsächlich bricht es ab, wenn Sie Flux-Stores bearbeiten, weil es nicht weiß, was es damit tun soll.

Wenn Redux den Reduzierungscode neu laden muss, wird es aufgerufen replaceReducer()und die App wird mit dem neuen Code ausgeführt. In Flux sind Daten und Funktionen in Flux-Speichern verschränkt, sodass Sie die Funktionen nicht einfach ersetzen können. Außerdem müssten Sie die neuen Versionen irgendwie beim Dispatcher neu registrieren - etwas, das Redux nicht einmal hat.

Ökosystem

Redux hat ein reiches und schnell wachsendes Ökosystem . Dies liegt daran, dass einige Erweiterungspunkte wie Middleware bereitgestellt werden . Es wurde unter Berücksichtigung von Anwendungsfällen wie Protokollierung , Unterstützung für Versprechen , Observables , Routing , Unveränderlichkeitsprüfungen , Persistenz usw. entwickelt. Nicht alle davon werden sich als nützlich erweisen, aber es ist schön, Zugriff auf eine Reihe von Tools zu haben, die einfach kombiniert werden können, um zusammenzuarbeiten.

Einfachheit

Redux bewahrt alle Vorteile von Flux (Aufzeichnung und Wiedergabe von Aktionen, unidirektionaler Datenfluss, abhängige Mutationen) und fügt neue Vorteile hinzu (einfaches Rückgängigmachen, erneutes Laden im laufenden Betrieb), ohne die Dispatcher- und Store-Registrierung einzuführen.

Es ist wichtig, es einfach zu halten, da es Sie bei der Implementierung von Abstraktionen auf höherer Ebene gesund hält.

Im Gegensatz zu den meisten Flux-Bibliotheken ist die Redux-API-Oberfläche winzig. Wenn Sie die Entwicklerwarnungen, Kommentare und Überprüfungen entfernen, sind es 99 Zeilen . Es gibt keinen kniffligen asynchronen Code zum Debuggen.

Sie können es tatsächlich lesen und alles von Redux verstehen.

Siehe auch meine Antwort zu den Nachteilen der Verwendung von Redux im Vergleich zu Flux .

In Quora sagt jemand :

Erstens ist es durchaus möglich, Apps mit React without Flux zu schreiben.

Auch dieses visuelle Diagramm, das ich erstellt habe, um eine schnelle Ansicht von beiden zu zeigen, wahrscheinlich eine schnelle Antwort für die Leute, die nicht die ganze Erklärung lesen wollen:

Aber wenn Sie immer noch daran interessiert sind, mehr zu wissen, lesen Sie weiter.

Ich glaube, Sie sollten mit reiner Reaktion beginnen und dann Redux und Flux lernen. Nachdem Sie einige echte Erfahrungen mit React gemacht haben, werden Sie sehen, ob Redux für Sie hilfreich ist oder nicht.

Vielleicht haben Sie das Gefühl, dass Redux genau für Ihre App geeignet ist, und vielleicht stellen Sie fest, dass Redux versucht, ein Problem zu lösen, das Sie nicht wirklich haben.

Wenn Sie direkt mit Redux beginnen, erhalten Sie möglicherweise überentwickelten Code, Code, der schwieriger zu warten ist und noch mehr Fehler aufweist als ohne Redux.

Aus Redux-Dokumenten :

Motivation
Da die Anforderungen für JavaScript-Anwendungen mit nur einer Seite immer komplizierter werden, muss unser Code mehr Status als je zuvor verwalten. Dieser Status kann Serverantworten und zwischengespeicherte Daten sowie lokal erstellte Daten enthalten, die noch nicht auf dem Server gespeichert wurden. Der UI-Status wird auch immer komplexer, da wir aktive Routen, ausgewählte Registerkarten, Spinner, Paginierungssteuerelemente usw. verwalten müssen.

Es ist schwierig, diesen sich ständig ändernden Zustand zu bewältigen. Wenn ein Modell ein anderes Modell aktualisieren kann, kann eine Ansicht ein Modell aktualisieren, wodurch ein anderes Modell aktualisiert wird. Dies kann wiederum dazu führen, dass eine andere Ansicht aktualisiert wird. Irgendwann verstehen Sie nicht mehr, was in Ihrer App passiert, da Sie die Kontrolle über das Wann, Warum und Wie ihres Status verloren haben. Wenn ein System undurchsichtig und nicht deterministisch ist, ist es schwierig, Fehler zu reproduzieren oder neue Funktionen hinzuzufügen.

Als ob dies nicht schlimm genug wäre, sollten Sie die neuen Anforderungen berücksichtigen, die in der Front-End-Produktentwicklung üblich werden. Als Entwickler wird von uns erwartet, dass wir optimistische Updates, serverseitiges Rendern, Abrufen von Daten vor dem Ausführen von Routenübergängen usw. durchführen. Wir versuchen, mit einer Komplexität umzugehen, mit der wir uns noch nie befasst haben, und stellen unweigerlich die Frage: Ist es Zeit aufzugeben? Die Antwort ist nein.

Diese Komplexität ist schwer zu bewältigen, da wir zwei Konzepte mischen, über die der menschliche Verstand nur schwer nachdenken kann: Mutation und Asynchronität. Ich nenne sie Mentos und Cola. Beide können großartig sein, wenn sie getrennt sind, aber zusammen verursachen sie ein Chaos. Bibliotheken wie React versuchen, dieses Problem in der Ansichtsebene zu lösen, indem sie sowohl Asynchronität als auch direkte DOM-Manipulation entfernen. Die Verwaltung des Status Ihrer Daten bleibt jedoch Ihnen überlassen. Hier kommt Redux ins Spiel.

Redux tritt in die Fußstapfen von Flux, CQRS und Event Sourcing und versucht, Zustandsmutationen vorhersehbar zu machen, indem bestimmte Einschränkungen festgelegt werden, wie und wann Aktualisierungen erfolgen können. Diese Einschränkungen spiegeln sich in den drei Prinzipien von Redux wider.

Auch aus Redux-Dokumenten :

Kernkonzepte
Redux selbst ist sehr einfach.

Stellen Sie sich vor, der Status Ihrer App wird als einfaches Objekt beschrieben. Der Status einer ToDo-App könnte beispielsweise folgendermaßen aussehen:

{
  todos: [{
    text: 'Eat food',
    completed: true
  }, {
    text: 'Exercise',
    completed: false
  }],
  visibilityFilter: 'SHOW_COMPLETED'
}

Dieses Objekt ist wie ein "Modell", nur dass es keine Setter gibt. Auf diese Weise können verschiedene Teile des Codes den Status nicht willkürlich ändern, was zu schwer reproduzierbaren Fehlern führt.

Um etwas im Status zu ändern, müssen Sie eine Aktion auslösen. Eine Aktion ist ein einfaches JavaScript-Objekt (beachten Sie, dass wir keine Magie einführen?), Das beschreibt, was passiert ist. Hier einige Beispielaktionen:

{ type: 'ADD_TODO', text: 'Go to swimming pool' }
{ type: 'TOGGLE_TODO', index: 1 }
{ type: 'SET_VISIBILITY_FILTER', filter: 'SHOW_ALL' }

Wenn wir durchsetzen, dass jede Änderung als Aktion beschrieben wird, haben wir ein klares Verständnis dafür, was in der App vor sich geht. Wenn sich etwas geändert hat, wissen wir, warum es sich geändert hat. Handlungen sind wie Brotkrumen von dem, was passiert ist. Um Status und Aktionen miteinander zu verknüpfen, schreiben wir schließlich eine Funktion, die als Reduzierer bezeichnet wird. Auch hier ist nichts Magisches daran - es ist nur eine Funktion, die Status und Aktion als Argumente verwendet und den nächsten Status der App zurückgibt. Es wäre schwierig, eine solche Funktion für eine große App zu schreiben, daher schreiben wir kleinere Funktionen, die Teile des Staates verwalten:

function visibilityFilter(state = 'SHOW_ALL', action) {
  if (action.type === 'SET_VISIBILITY_FILTER') {
    return action.filter;
  } else {
    return state;
  }
}

function todos(state = [], action) {
  switch (action.type) {
  case 'ADD_TODO':
    return state.concat([{ text: action.text, completed: false }]);
  case 'TOGGLE_TODO':
    return state.map((todo, index) =>
      action.index === index ?
        { text: todo.text, completed: !todo.completed } :
        todo
   )
  default:
    return state;
  }
}

Und wir schreiben einen weiteren Reduzierer, der den vollständigen Status unserer App verwaltet, indem wir diese beiden Reduzierer für die entsprechenden Statusschlüssel aufrufen:

function todoApp(state = {}, action) {
  return {
    todos: todos(state.todos, action),
    visibilityFilter: visibilityFilter(state.visibilityFilter, action)
  };
}

Dies ist im Grunde die ganze Idee von Redux. Beachten Sie, dass wir keine Redux-APIs verwendet haben. Es enthält einige Hilfsprogramme, um dieses Muster zu vereinfachen. Die Hauptidee ist jedoch, dass Sie beschreiben, wie Ihr Status im Laufe der Zeit als Reaktion auf Aktionsobjekte aktualisiert wird, und 90% des von Ihnen geschriebenen Codes nur einfaches JavaScript ohne Verwendung von Redux ist selbst, seine APIs oder irgendeine Magie.

Beginnen Sie am besten mit dem Lesen dieses Beitrags von Dan Abramov, in dem er verschiedene Implementierungen von Flux und ihre Kompromisse zu der Zeit beschreibt, als er Redux schrieb: The Evolution of Flux Frameworks

Zweitens werden auf der Motivationsseite, auf die Sie verlinken, die Motivationen von Redux nicht so sehr erörtert wie die Motivationen hinter Flux (und React). Die drei Prinzipien sind reduxspezifischer, behandeln jedoch immer noch nicht die Implementierungsunterschiede zur Standard-Flux-Architektur.

Grundsätzlich verfügt Flux über mehrere Speicher, die Statusänderungen als Reaktion auf UI / API-Interaktionen mit Komponenten berechnen und diese Änderungen als Ereignisse übertragen, die Komponenten abonnieren können. In Redux gibt es nur einen Speicher, den jede Komponente abonniert. IMO scheint es zumindest so, als würde Redux den Datenfluss weiter vereinfachen und vereinheitlichen, indem der Datenfluss zurück zu den Komponenten vereinheitlicht (oder reduziert wird, wie Redux sagen würde) - während sich Flux darauf konzentriert, die andere Seite des Datenflusses zu vereinheitlichen Modell.

Ich bin ein Early Adopter und habe eine mittelgroße Einzelseitenanwendung mithilfe der Facebook Flux-Bibliothek implementiert.

Da ich zu spät zum Gespräch komme, möchte ich nur darauf hinweisen, dass Facebook trotz meiner besten Hoffnungen die Flux-Implementierung als Proof of Concept zu betrachten scheint und nie die Aufmerksamkeit erhalten hat, die es verdient.

Ich möchte Sie ermutigen, damit zu spielen, da es mehr von der inneren Funktionsweise der Flux-Architektur enthüllt, die ziemlich lehrreich ist, aber gleichzeitig nicht viele der Vorteile bietet, die Bibliotheken wie Redux bieten (die es nicht sind) das ist wichtig für kleine Projekte, wird aber für größere sehr wertvoll).

Wir haben beschlossen, dass wir in Zukunft zu Redux wechseln werden, und ich schlage vor, dass Sie dasselbe tun;)

Hier ist die einfache Erklärung von Redux over Flux. Redux hat keinen Dispatcher. Es basiert auf reinen Funktionen, die als Reduzierer bezeichnet werden. Es wird kein Dispatcher benötigt. Jede Aktion wird von einem oder mehreren Reduzierungen ausgeführt, um den einzelnen Speicher zu aktualisieren. Da Daten unveränderlich sind, geben Reduzierer einen neuen aktualisierten Status zurück, der den Speicher aktualisiert

Weitere Informationen finden Sie unter Flux vs Redux

Ich habe ziemlich lange mit Flux gearbeitet und jetzt ziemlich lange mit Redux. Wie Dan betonte, sind beide Architekturen nicht so unterschiedlich. Die Sache ist, dass Redux die Dinge einfacher und sauberer macht. Es bringt Ihnen ein paar Dinge über Flux bei. Wie zum Beispiel ist Flux ein perfektes Beispiel für einen Datenfluss in eine Richtung. Trennung von Bedenken, bei denen Daten, deren Manipulationen und Ansichtsebene getrennt sind. In Redux haben wir die gleichen Dinge, aber wir lernen auch etwas über Unveränderlichkeit und reine Funktionen.

Von einem neuen React / Redux-Adopter, der Mitte 2018 aus (einigen Jahren) ExtJS migriert ist:

Nachdem ich die Redux-Lernkurve rückwärts heruntergerutscht war, hatte ich die gleiche Frage und dachte, reiner Fluss wäre einfacher als OP.

Ich sah bald die Vorteile von Redux gegenüber Flux, wie in den obigen Antworten angegeben, und arbeitete es in meine erste App ein.

Während ich die Kesselplatte wieder in den Griff bekam, probierte ich einige der anderen staatlichen Verwaltungsbibliotheken aus. Das Beste, was ich fand, war ein Rückkampf .

Es war viel intuitiver als Vanille-Redux, es schneidet 90% der Boilerplate aus und 75% der Zeit, die ich für Redux aufgewendet habe (etwas, von dem ich denke, dass eine Bibliothek dies tun sollte), ich konnte ein paar Unternehmens-Apps bekommen sofort gehen.

Es läuft auch mit dem gleichen Redux-Werkzeug. Dies ist ein guter Artikel , der einige der Vorteile behandelt.

Für alle anderen, die zu diesem SO-Beitrag gekommen sind und nach "einfacherem Redux" suchen, empfehle ich, ihn als einfache Alternative zu Redux mit allen Vorteilen und 1/4 der Boilerplate auszuprobieren.

Gemäß diesem Artikel: https://medium.freecodecamp.org/a-realworld-comparison-of-front-end-frameworks-with-benchmarks-2019-update-4be0d3c78075

Sie sollten MobX besser verwenden, um die Daten in Ihrer App zu verwalten, um eine bessere Leistung zu erzielen, nicht Redux.