Frage Warum Redux über Facebook Flux verwenden?


Ich habe gelesen diese Antwort, Reduzieren von Boilerplate, guckten sich ein paar GitHub-Beispiele an und probierten Redux sogar ein bisschen aus (todo apps).

Wie ich es verstehe, offizielle redux doc motivationen bieten Vorteile 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 von Programmierstilen: funktional vs. nicht funktional? Oder liegt die Frage in den Fähigkeiten / Entwicklungswerkzeugen, die aus dem Redox-Ansatz folgen? Vielleicht Skalierung? Oder testen?

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

Um diese Frage zu beantworten, können Sie die Komplexität der Implementierungspunkte von redux und redux vergleichen.

Hier sind Motivationspunkte aus offizielle redux doc motivationen:

  1. Umgang mit optimistischen Updates (wie ich es verstehe, kommt es kaum auf den 5. Punkt an. Ist es schwierig, es in facebook flux zu implementieren?)
  2. Rendern auf dem Server (facebook flux kann das auch tun. Irgendwelche Vorteile im Vergleich zu Redux?)
  3. Abrufen von Daten vor dem Ausführen von Routenübergängen (Warum kann es nicht in Facebook Flux erreicht werden? Was sind die Vorteile?)
  4. Heißes Nachladen (Es ist möglich mit Hot Reload reagieren. Warum brauchen wir Redox?)
  5. Rückgängig / Wiederherstellen
  6. Irgendwelche anderen Punkte? Wie anhaltender Zustand ...

1003
2017-09-08 15:05


Ursprung


Antworten:


Redux Autor hier!

Redux ist nicht Das anders als Flux. Insgesamt hat es die gleiche Architektur, aber Redux ist in der Lage, einige Komplexitätsecken zu reduzieren, indem es eine funktionale Zusammensetzung verwendet, bei der Flux die Rückrufregistrierung verwendet.

Es gibt keinen grundlegenden Unterschied in Redux, aber ich finde, dass es bestimmte Abstraktionen erleichtert oder zumindest möglich macht, die in Flux schwer oder gar nicht implementiert werden können.

Reducer Zusammensetzung

Nehmen Sie zum Beispiel die Seitennummerierung. Meine Flux + React Router Beispiel Griffe Paginierung, aber der Code dafür ist schrecklich. Einer der Gründe, warum es schrecklich ist, ist dass Flux macht es unnatürlich, die Funktionalität in den Filialen wiederzuverwenden. Wenn zwei Speicher die Seitennumerierung als Reaktion auf verschiedene Aktionen verarbeiten müssen, müssen sie entweder von einem gemeinsamen Basisspeicher erben (schlecht! Sie sperren sich in ein bestimmtes Design, wenn Sie Vererbung verwenden) oder eine Funktion vom Handler aufrufen, die muss irgendwie im Privatstaat des Flux-Ladens operieren. Das Ganze ist chaotisch (obwohl definitiv im Bereich des Möglichen).

Auf der anderen Seite, mit Redux Paginierung ist natürlich dank Reducer Zusammensetzung. Es ist Reduktionen den ganzen Weg hinunter, so dass Sie eine schreiben können Reducer Factory, die Paginierungsreduzierer erzeugt und dann benutze es in deinem Reduziererbaum. Der Schlüssel, warum es so einfach ist, ist, weil In Flux sind Geschäfte flach, aber in Redux können Reduzierer über die funktionale Zusammensetzung geschachtelt werden, genauso wie React-Komponenten geschachtelt werden können.

Dieses Muster ermöglicht auch wunderbare Funktionen wie Nicht-Benutzer-Code rückgängig wiederholen. Können Sie sich vorstellen, das Rückgängigmachen / Wiederherstellen in eine Flux-App zu stecken, die aus zwei Codezeilen besteht? Kaum. Mit Redux ist es-wieder dank des Reducer-Zusammensetzungsmusters. Ich muss hervorheben, dass es nichts Neues daran gibt - das ist das Muster, das in diesem Buch ausführlich vorgestellt und beschrieben wurde Ulme Architektur welches selbst von Flux beeinflusst wurde.

Server-Rendering

Die Leute haben auf dem Server mit Flux gut rendern können, aber da wir 20 Flux-Bibliotheken haben, die jeweils versuchen, Server-Rendering "einfacher" zu machen, hat Flux vielleicht einige Ecken und Kanten auf dem Server. Die Wahrheit ist, dass Facebook nicht viel Server-Rendering macht, also 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 werden die meisten Flux - Bibliotheken (sowie die neue Flux Utils) schlagen Sie vor, Klassen anstelle von Singletons zu verwenden, damit Sie Geschäfte pro Anfrage instanziieren können.

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

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

Zugegebenermaßen haben Flux-Gerüste (nicht Vanilla Flux) Lösungen für diese Probleme, aber ich finde sie zu kompliziert. Beispielsweise, Flummox bittet Sie um Umsetzung serialize() und deserialize() in deinen Geschäften. Alt löst das schöner, indem es bereitstellt takeSnapshot() Dadurch wird Ihr Status automatisch in einem JSON-Baum serialisiert.

Redux geht einfach weiter: Da es nur einen einzigen Speicher gibt (der von vielen Reduzierern verwaltet wird), benötigen Sie keine spezielle API, um die (erneute) Hydration zu verwalten. Sie müssen Speicher nicht "leeren" oder "hydratisieren" - es gibt nur einen einzigen Speicher, und Sie können den aktuellen Status lesen oder einen neuen Speicher mit einem neuen Status erstellen. Jede Anfrage erhält eine separate Filialinstanz. Lesen Sie mehr über Server Rendering mit Redux.

Wiederum ist dies 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 API und Konventionen einführen, und Redux muss es nicht einmal lösen, weil es dieses Problem nicht hat erster Platz dank konzeptioneller Einfachheit.

Entwicklererfahrung

Ich hatte eigentlich nicht vor, Redux zu einer beliebten Flux-Bibliothek zu machen - ich schrieb sie, als ich an meiner Arbeit arbeitete ReactEurope spricht über heißes Nachladen mit Zeitreisen. Ich hatte ein Hauptziel: ermöglichen es, Reducer-Code im laufenden Betrieb zu ändern oder sogar "die Vergangenheit zu ändern", indem Sie Aktionen auskreuzen und sehen, dass der Status neu berechnet wird.

Ich habe keine einzige Flux-Bibliothek gesehen, die das kann. Mit React Hot Loader können Sie das auch nicht tun - es bricht tatsächlich, wenn Sie Flux-Stores bearbeiten, weil es nicht weiß, was Sie damit machen sollen.

Wenn Redux den Reducer-Code neu laden muss, ruft er auf replaceReducer()und die App wird mit dem neuen Code ausgeführt. In Flux sind Daten und Funktionen in Flux-Stores verstrickt, so dass Sie nicht "nur die Funktionen ersetzen" können. Außerdem müssten Sie die neuen Versionen irgendwie mit dem Dispatcher neu registrieren - etwas, das Redux nicht hat.

Ökosystem

Redux hat ein reiches und schnell wachsendes Ökosystem. Dies liegt daran, dass es einige Erweiterungspunkte wie z Middleware. Es wurde mit Anwendungsfällen wie z protokollieren, Unterstützung für Versprechen, Observablen, Routing, Immutability-Dev-Checks, Beharrlichkeitusw. im Hinterkopf. Nicht alle davon werden sich als nützlich erweisen, aber es ist schön, Zugang zu einer Reihe von Tools zu haben, die einfach miteinander kombiniert werden können.

Einfachheit

Redux bewahrt alle Vorteile von Flux (Aufzeichnung und Wiedergabe von Aktionen, unidirektionaler Datenfluss, abhängige Mutationen) und fügt neue Vorteile hinzu (einfaches Undo-Redo, Hot-Reload), ohne den Dispatcher einzuführen und die Registrierung zu speichern.

Es ist wichtig, es einfach zu halten, denn es hält Sie gesund, während Sie Abstraktionen höherer Ebenen implementieren.

Im Gegensatz zu den meisten Flux-Bibliotheken ist die Redux-API-Oberfläche winzig. Wenn Sie die Entwicklerwarnungen, Kommentare und Plausibilitätsprüfungen entfernen, ist dies der Fall 99 Zeilen. Es gibt keinen kniffligen Async-Code zum Debuggen.

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


Siehe auch meine Antwort auf die Nachteile von Redux im Vergleich zu Flux.


1804
2017-10-03 08:26



In Quora sagt jemand: 

Zum einen ist es durchaus möglich, Apps mit React ohne zu schreiben   Fluss.

Auch das visuelles Diagramm Was ich erstellt habe, zeigt eine schnelle Ansicht von beiden, wahrscheinlich eine schnelle Antwort für die Leute, die nicht die ganze Erklärung lesen wollen: Flux vs Redux

Aber wenn Sie noch mehr wissen möchten, lesen Sie weiter.

Ich glaube, du solltest mit reinem React beginnen, dann Redux und Flux lernen.   Nachdem du REAL mit REAL erfahren hast, wirst du sehen   ob Redux für Sie hilfreich ist oder nicht.

Vielleicht werden Sie fühlen, dass Redux genau für Ihre App und vielleicht Sie ist   finden heraus, dass Redux versucht, ein Problem zu lösen, das Sie nicht sind   wirklich erleben.

Wenn Sie direkt mit Redux beginnen, können Sie überentwickelt sein   Code, Code schwerer zu pflegen und mit noch mehr Bugs und als ohne   Redux.

Von Redux-Dokumente:

Motivation 
 Da die Anforderungen für JavaScript-Einzelseiten-Anwendungen immer komplizierter geworden sind, haben unsere   Code muss mehr Status verwalten als je zuvor. Dieser Zustand kann beinhalten   Serverantworten und zwischengespeicherte Daten sowie lokal erstellte Daten, die   wurde noch nicht auf dem Server gespeichert. UI-Status wird ebenfalls erhöht   In der Komplexität, wie wir aktive Routen verwalten müssen, ausgewählte Registerkarten,   Spinner, Paginierungskontrollen und so weiter.

Es ist schwierig, diesen sich ständig verändernden Staat zu managen. Wenn ein Modell aktualisiert werden kann   ein anderes Modell, dann kann eine Ansicht ein Modell aktualisieren, das ein anderes aktualisiert   Modell, und dies wiederum kann dazu führen, dass eine andere Ansicht aktualisiert wird. Bei einigen   Punkt, Sie verstehen nicht mehr, was in Ihrer App passiert, wie Sie haben   verlor die Kontrolle über das Wann, Warum und Wie seines Zustandes. Wenn ein System   ist undurchsichtig und nicht deterministisch, es ist schwer, Bugs zu reproduzieren oder hinzuzufügen   Neue Eigenschaften.

Als ob das nicht schlimm genug wäre, bedenken Sie, dass die neuen Anforderungen immer größer werden   häufig in der Entwicklung von Front-End-Produkten. Als Entwickler sind wir   erwartet, mit optimistischen Updates, serverseitigem Rendering und Abrufen umzugehen   Daten vor dem Ausführen von Routenübergängen und so weiter. Wir finden uns   versuchen, eine Komplexität zu bewältigen, mit der wir uns nie zu befassen hatten   vorher, und wir stellen unweigerlich die Frage: Ist es Zeit aufzugeben? Das   Antwort ist Nein.

Diese Komplexität ist schwierig zu handhaben, da wir zwei Konzepte miteinander kombinieren   das ist sehr schwer für den menschlichen Verstand zu begründen: Mutation und   Asynchronität. Ich nenne sie Mentos und Cola. Beides kann großartig sein   getrennt, aber zusammen schaffen sie ein Durcheinander. Bibliotheken mögen reagieren   Versuchen Sie, dieses Problem in der Ansichtsschicht zu lösen, indem Sie beides entfernen   Asynchronität und direkte DOM-Manipulation. Jedoch, den Staat von   Ihre Daten bleiben Ihnen überlassen. Hier kommt Redux ins Spiel.

Auf den Spuren von Flux, CQRS und Event Sourcing, Redux   Versuche, Mutationen im Staat vorhersagbar zu machen, indem sie bestimmte auferlegt werden   Einschränkungen, wie und wann Updates stattfinden können. Diese Einschränkungen   spiegeln sich in den drei Prinzipien von Redux wider.

Auch von Redux-Dokumente:

Kernkonzepte
 Redux selbst ist sehr einfach.

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

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

Dieses Objekt ist wie ein "Modell", außer dass es keine Setter gibt. Dies   ist so, dass verschiedene Teile des Codes den Zustand nicht ändern können   willkürlich, verursacht schwer zu reproduzieren Bugs.

Um etwas im Staat zu ändern, müssen Sie eine Aktion versenden. Ein   Aktion ist ein einfaches JavaScript-Objekt (beachten Sie, dass wir keine einführen   Magie?) das beschreibt, was passiert ist. Hier sind 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 eine Aktion beschrieben wird, können wir a   Ein klares Verständnis davon, was in der App passiert. Falls etwas   geändert, wir wissen, warum es sich geändert hat. Aktionen sind wie Brotkrumen von was   ist passiert. Um schließlich den Zustand und die Handlungen miteinander zu verbinden, schreiben wir ein   Funktion namens Reducer. Wieder nichts Magisches - es ist nur ein   Funktion, die state und action als Argumente akzeptiert und den Befehl zurückgibt   nächster Status der App Es wäre schwer, eine solche Funktion für einen zu schreiben   große App, also 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 Reducer, der den kompletten Zustand unserer   App durch Aufruf dieser beiden Reduzierungen für die entsprechenden Statusschlüssel:

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 nicht verwendet haben   alle Redux-APIs. Es kommt mit ein paar Hilfsprogrammen, um dies zu erleichtern   Muster, aber die Hauptidee ist, dass Sie beschreiben, wie Ihr Zustand ist   aktualisiert im Laufe der Zeit als Reaktion auf Aktionsobjekte und 90% des Codes   Du schreibst einfach JavaScript, ohne Redux selbst zu benutzen   APIs oder irgendeine Magie.


74
2018-03-22 12:59



Am besten beginnen Sie mit dem Lesen dieses Posts von Dan Abramov, wo er verschiedene Implementierungen von Flux und ihre Kompromisse zu der Zeit, als er reduc schrieb, diskutiert: Die Evolution der Flux Frameworks

Zweitens, diese Motivationsseite, auf die Sie verlinken, diskutiert nicht so sehr die Motivation von Redux als die Motivation hinter Flux (und React). Das Drei Prinzipien ist mehr Redux-spezifisch, behandelt jedoch immer noch nicht die Implementierungsunterschiede von der 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 fühlt es sich zumindest an wie Redux den Datenfluss weiter vereinfacht und vereinheitlicht, indem er den Datenfluss zu den Komponenten vereinheitlicht (oder reduziert, wie Redux sagen würde) - während Flux sich darauf konzentriert, die andere Seite des Datenflusses zu vereinigen Modell.


50
2017-09-23 14:51



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

Da ich ein bisschen spät dran bin, möchte ich nur darauf hinweisen, dass Facebook trotz meiner größten Hoffnungen die Flux-Implementierung als Beweis für das Konzept betrachtet und nie die Aufmerksamkeit erhalten hat, die es verdient.

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

Wir haben beschlossen, dass wir uns nach Redux bewegen werden und ich schlage vor, dass Sie dasselbe tun;)


22
2018-01-05 13:45



Hier ist die einfache Erklärung von Redux über Flux. Redux hat keinen Dispatcher. Es beruht auf reinen Funktionen, die als Reduzierer bezeichnet werden. Es benötigt keinen Dispatcher. Jede Aktion wird von einem oder mehreren Reduzierern ausgeführt, um den einzelnen Speicher zu aktualisieren. Da Daten unveränderlich sind, gibt reducers einen neuen aktualisierten Status zurück, der den Speicher aktualisiertenter image description here

Für mehr Informationen http://www.prathapkudupublog.com/2017/04/flux-vs-redux.html


13
2018-04-18 14:27



Ich habe lange mit Flux gearbeitet und jetzt ziemlich lange mit Redux gearbeitet. Wie Dan betonte, sind beide Architekturen nicht so verschieden. Die Sache ist, dass Redux die Dinge einfacher und sauberer macht. Es lehrt dich ein paar Dinge über Flux. Wie zum Beispiel Flux ist ein perfektes Beispiel für One-Direction-Datenfluss. Trennung von Belangen, bei denen Daten, Manipulationen und View-Layer getrennt sind. In Redux haben wir die gleichen Dinge, aber wir lernen auch Unveränderlichkeit und reine Funktionen.


2
2018-01-25 12:26



Fluss ist ein Muster und Redux ist eine Bibliothek.

Flux ist ein fantastischer Name für das Beobachtermuster, das ein wenig modifiziert wurde, um zu React zu passen, aber Facebook hat ein paar Werkzeuge zur Implementierung des Flux-Musters veröffentlicht, daher ist der folgende Unterschied zwischen der Verwendung dieser Werkzeuge (die allgemein als Flux bezeichnet werden) ) und Redux verwenden.

Sowohl Flux als auch Redux haben Aktionen. Aktionen können mit Ereignissen verglichen werden (oder mit Auslöserereignissen). In Flux ist eine Aktion ein einfaches JavaScript-Objekt, und das ist auch der Standardfall in Redux, aber bei Verwendung der Redux-Middleware können Aktionen auch Funktionen und Versprechen sein.

Mit Flux ist es eine Konvention, mehrere Geschäfte pro Anwendung zu haben; Jedes Geschäft ist ein Singleton-Objekt. In Redux besteht die Konvention darin, einen einzelnen Speicher pro Anwendung zu haben, der normalerweise intern in Datendomänen unterteilt ist (Sie können mehr als einen Redux-Speicher erstellen, wenn dies für komplexere Szenarien erforderlich ist).

Flux hat einen einzigen Dispatcher und alle Aktionen müssen diesen Dispatcher passieren. Es ist ein Singleton-Objekt. Eine Flux-Anwendung kann nicht mehrere Dispatcher haben. Dies ist erforderlich, da eine Flux-Anwendung mehrere Speicher haben kann und die Abhängigkeiten zwischen diesen Speichern einen einzelnen Manager benötigen, der Dispatcher ist.

Redux hat keine Dispatcher-Entität. Stattdessen wird der Dispatching-Prozess in den Store integriert. Ein Redux-Store stellt einige einfache API-Funktionen zur Verfügung, von denen eine zum Absetzen von Aktionen dient.

In Flux wird die Logik der Daten, die auf der empfangenen Aktion basieren, in den Speicher geschrieben. Das Geschäft hat auch die Flexibilität, welche Teile der Daten öffentlich verfügbar gemacht werden sollen. Der intelligenteste Spieler in einer Flux App ist der Laden.

In Redux ist die Logik, was auf den Daten basierend auf den empfangenen Aktionen zu tun ist, in der Reducer-Funktion, die für jede Aktion aufgerufen wird, die ausgelöst wird (über die Speicher-API). Ein Speicher kann nicht ohne eine Reduzierfunktion definiert werden. Ein Redux Reducer ist eine einfache Funktion, die den vorherigen Zustand und eine Aktion erhält und basierend auf dieser Aktion den neuen Status zurückgibt. In einer Redux-App können Sie Ihren Reducer in einfachere Funktionen aufteilen, wie Sie es mit jeder anderen Funktion tun würden. Der intelligenteste Spieler in Redux ist der Reducer.

Auch in Redux gibt es nicht viel Flexibilität darüber, was als Status des Geschäfts verfügbar gemacht werden soll. Redux wird nur das freigeben, was vom Reduzierer des Ladens zurückgegeben wurde. Dies ist eine Einschränkung.

Die andere größere Einschränkung ist, dass der Zustand des Geschäfts nicht veränderbar sein kann (oder wirklich nicht sein sollte). Es gibt keine solche Beschränkung in Flux, Sie können den Zustand wie gewünscht verändern. Die Unveränderlichkeit des Staates in Redux wird leicht erreicht, indem die Reduktoren zu reinen Funktionen gemacht werden (ohne Nebenwirkungen). Redux-Reduzierungen kopieren immer den Zustand, den sie empfangen, und geben eine modifizierte Version der Kopie des Status zurück, nicht das ursprüngliche Objekt selbst. Während dies eine große Einschränkung ist, macht es das Leben langfristig viel einfacher.


0
2018-06-24 07:13