Was ist der Hauptunterschied zwischen Redux und Reflux bei reaktionsbasierten Anwendungen?

Ich wollte eine weitere Antwort schreiben, die sich auf den spezifischen Unterschied zwischen Reflux und Redux konzentriert. @Mijamo geht auf den Kern der Frage ein, warum sie als unterschiedliche Dinge entstanden sind und ist eine sehr gute Zusammenfassung, wenn Sie Kontext haben, aber ich bin auf diese Frage gekommen, um speziell den Unterschied zwischen den beiden aus einer Entwicklungsperspektive zu kennen. Da ich gerade reinging und all die Dinge las, wollte ich eine Antwort schreiben. Ich werde diese Antwort mit weiteren Codebeispielen aktualisieren.

Flussmittel (Kurzübersicht)

Bevor wir darauf eingehen, sollten wir uns zunächst Gedanken über den aktuellen Flux machen und darüber, wie derzeit eine Anwendung mit vielen Komponenten oder vielen verschiedenen Statuselementen skaliert wird, die verwaltet werden müssen. Dies ist eine ziemlich gute Diskussion bei React NYC: Scaling Flux , die auf das Problem eingeht und deren Lösung nicht allzu weit von den Möglichkeiten von Reflux und Redux entfernt ist Sie zu tun, aber auf den Punkt gebracht, ist eine große Frage: " Was machen wir, wenn wir Komponenten haben, die einen gemeinsamen Zustand haben, an den sie alle denken müssen? Wie gehen wir damit um und skalieren sie ? "Letztendlich ist eine Antwort, zu der viele dieser Rahmenbedingungen gelangen, dass wir diese Idee eines globalen Staates brauchen. Unweigerlich führen beide Frameworks einige ähnliche Konzepte ein, um dies zu erreichen, auf die im Folgenden eingegangen wird.

Da ich auf einen Vergleich von Flux verweisen muss, möchte ich nur ein eine kurze Übersicht über die Funktionsweise von Flux mit dem folgenden Bild zeigen:

Reflux

In Reflux gibt es keinen Dispatcher, und die View Components kommunizieren direkt über die Komponenten durch Aktionen.

+---------+       +--------+       +-----------------+
¦ Actions ¦------>¦ Stores ¦------>¦ View Components ¦
+---------+       +--------+       +-----------------+
     ^                                      ¦
     +--------------------------------------+

In Bezug darauf, wie es sich von Flux unterscheidet, gibt es nicht zu viel. Sie erstellen immer noch Ihre eigenen Aktionen und Ihre eigenen Geschäfte, und Sie lassen Ihre Geschäfte immer noch Aktionen anhören. Ich glaube, der größte Unterschied ist, dass, damit die View-Komponenten Aktionen direkt an das Geschäft senden, anstatt einen Dispatcher zu durchlaufen, die Components eine Store-Eigenschaft haben, die von Reflux.Component Anstelle von React.Component damit es eine Möglichkeit gibt, sich direkt in ein Geschäft einzuklinken. dieses Beispiel

class MyComponent extends Reflux.Component
{
    constructor(props)
    {
        super(props);
        this.state = {}; // our store will add its own state to the component's
        this.store = StatusStore; // <- just assign the store class itself
    }

    render()
    {
        var flag = this.state.flag; // <- flag is mixed in from the StatusStore
        return <div>User is {flag}</div>
    }
}

Sie haben auch die Möglichkeit, sich in mehrere Läden einzuklinken (es gibt eine Requisite namens stores, die ein Array annimmt, und Reflux wird auch mit der Fähigkeit edit mapStoreToState geliefert, falls Sie genau steuern möchten, wie Die Filialen übergeben den Status an die Komponenten.

Da Sie eine Komponente verwenden, die im Lieferumfang von Reflux enthalten ist, sollten Sie wahrscheinlich deren Dokumentation zu Reflux Component lesen und sich darüber im Klaren sein, wie Komponenten ordnungsgemäß hergestellt werden

Das Letzte, was ich oben erwähnen werde, ist, dass ich das große Problem des globalen Zustands erwähnte und wie geht das damit um. Reflux hat ein Reflux.GlobalState , zu dem beigetragen werden kann, solange Sie IDs in Ihren Stores festlegen. Der obige Link führt viel mehr Details ein, aber damit können Sie über Reflux.GlobalState.[StoreID].[property] Darauf zugreifen, wobei StoreID die ID ist, die Sie dem Geschäft zuweisen, und property das tatsächliche Stück ist des Staates, auf den Sie zugreifen möchten.

Redux

Redux an und für sich verändert eine Menge Dinge und tötet auch die Idee der Disponenten. Bevor ich näher darauf eingehe, möchte ich die drei Prinzipien hervorheben, die sie in ihren Dokumenten erwähnen.

1. Eine einzige Quelle der Wahrheit
2. Der Status ist schreibgeschützt
3. Änderungen werden mit reinen Funktionen vorgenommen

In Redux gibt es wirklich nur einen globalen Status, mit dem Sie sich befassen müssen, und das ist der globale Status für Ihre Anwendung (Lösung des großen Problems). Während Sie noch über Aktionen und Informationsspeicher verfügen, sind die Informationsspeicher selbst lediglich dafür verantwortlich, ihren eigenen Status in der globalen Statusstruktur zu verfolgen. Auf diese Weise können Sie Aktionen auslösen, um Änderungen an der Statusstruktur vorzunehmen, und auf den Status zugreifen. Sie können diese Stores auch weiterhin über subscribe mit Listenern versehen.

Eine große Motivation dafür steckt in den ersten beiden Prinzipien. Wenn Sie in Flux oder sogar Reflux sicherstellen möchten, dass nichts den Status ändert, als Sie es nicht wollten (da Sie technisch jederzeit auf die Stores zugreifen und den Status ändern können), sind Sie auf Folgendes angewiesen: ImmutableJS um sicherzustellen, dass Sie den Staat nicht versehentlich mutiert haben. Redux hingegen macht es so, dass Sie nur über die Stores/Selektoren auf den Status zugreifen können und Änderungen nur über Dispatching-Aktionen vornehmen können (das dritte Prinzip).

Eine interessante Sache ist, dass während Reflux und Flux Aktionen hatten, bei denen in den Läden zugehört und festgestellt wurde, welche Zustandsänderung zu tun ist, die Läden in Redux einfach eine Nachricht mit der gewünschten Nutzlast versenden und dann eine riesige Schalteranweisung durchlaufen um zu bestimmen, was es mit dem Zustandsbaum machen soll - das ist, was sie als Reduzierer bezeichnen. Dies unterscheidet sich nicht davon, wie Flux reduce in seinen Stores hat, aber Redux reißt dieses Konzept als seine eigene Sache heraus und Ihr globaler Statusbaum durchläuft ein rootReducer (Redux wird mit einer Nice-Funktion ausgeliefert) für Sie zu combineReducers und machen Sie ein rootReducer). Eine gute Möglichkeit, darüber nachzudenken, besteht darin, dass Sie eine Änderung an dem riesigen Zustandsbaum senden und diese dann auf den gewünschten Endzustand reduzieren oder verdichten. Dies beeinflusst tatsächlich, wie Redux eine Menge Dinge einrichtet, so dass es React wie neu gerendert werden soll (vorausgesetzt, Sie verwenden Redux mit React).

Über das Datenfluss von Redux wurde in dem oben erwähnten Link sehr gut gesprochen, aber ich habe auch eine ziemlich gute Infografik angehängt

Kernunterschiede sind also wirklich

• Redux verfolgt einen völlig anderen Ansatz für das Staatsmanagement - es geht um die Idee, dass es einen globalen Staat gibt und dass Änderungen zwangsläufig nur dort stattfinden sollten auf ganz bestimmte Weise (wie Sie damit umgehen, welche Komponenten Zugriff auf welchen Status haben).
• Reflux versucht wirklich zu unterstützen, Komponenten die Möglichkeit zu geben, auf mehrere Stores zuzugreifen, ohne zu viel von dem ändern zu müssen, worum es ursprünglich bei Flux ging (Ich würde gerne denken, dass Reflux das ist, was Flux hätte sein sollen).
• Redux ändert die Art und Weise, wie der Statusbaum verwaltet wird, und gibt den Filialen unterschiedliche Verantwortlichkeiten. Außerdem ändert sich die Art und Weise, wie Statusinformationen den Komponenten zugeordnet werden, während Reflux einfach den Middle Man herausreißt, damit Sie Ihren Komponenten den Zugriff auf alle benötigten Filialen erleichtern können .

Hoffentlich gibt dies mehr Einblick in die Kernunterschiede zwischen ihnen.