Kann ich RxJS vs. Redux/Context verwenden, wenn ich versuche, den Status in verschiedenen Komponenten und Handlermethoden zu verwalten und darauf zuzugreifen? [closed]

Ich weiß, dass Redux eine bessere „Implementierung“ von Flux ist, oder besser gesagt, es ist eine Neugestaltung zur Vereinfachung (Anwendungsstatusverwaltung).

Ich habe viel über reaktive Programmierung (RxJS) gehört, bin aber noch nicht in die Materie eingetaucht, um es zu lernen.

Meine Frage lautet also: Gibt es eine Schnittstelle (irgendetwas gemeinsam) zwischen diesen beiden Technologien oder ergänzen sie sich? …oder ganz anders?

Redux ist zusammen mit der Reach-Kontext-API eine Möglichkeit, einen Statusspeicher zu erstellen und zu verwalten, der durch Redux-Aktionen beobachtet werden kann.

RxJS, eine reaktive Programmiersprache, bietet die Möglichkeit, den Status verschiedener Komponenten festzulegen und darauf zuzugreifen, ohne den Aufwand von Redux-Aktionen und -Reduzierern.

Wo könnte Redux als Zustandsspeicher nützlicher sein als ein reaktives Programmierparadigma, um den Zustand zu verwalten und darauf zuzugreifen?

Wie würden Sie sich dafür entscheiden, das eine oder das andere für die Verwaltung und den Zugriff auf den Status verschiedener Komponenten zu verwenden?

Kurz gesagt, es handelt sich um sehr unterschiedliche Bibliotheken für sehr unterschiedliche Zwecke, aber es gibt tatsächlich einige vage Ähnlichkeiten.

Redux ist ein Tool zur Statusverwaltung in der gesamten Anwendung. Es wird normalerweise als Architektur für Benutzeroberflächen verwendet. Betrachten Sie es als eine Alternative zu (der Hälfte von) Angular.

RxJS ist eine reaktive Programmierbibliothek. Es wird normalerweise als Werkzeug zum Ausführen asynchroner Aufgaben in JavaScript verwendet. Betrachten Sie es als Alternative zu Promises.

Reaktive Programmierung ist ein Paradigma (Arbeits- und Denkweise), bei dem Datenänderungen stattfinden aus der Ferne beobachtet. Daten sind es nicht aus der Ferne verändert.

Hier ist ein Beispiel dafür aus der Ferne verändert:

// In the controller.js file
model.set('name', 'George');

Der Modell wurde geändert vom Controller.

Hier ist ein Beispiel dafür aus der Ferne beobachtet:

// logger.js
store.subscribe(function (data) {
    console.log(data);
});

Im Logger beobachten wir die Datenänderungen, die im Store stattfinden (aus der Ferne) und schreiben in die Konsole.

Redux verwendet das reaktive Paradigma nur ein wenig: Der Store ist reaktiv. Sie bestimmen den Inhalt nicht aus der Ferne. Deshalb gibt es keine store.set() in Redux. Der Store beobachtet Aktionen aus der Ferne und verändert sich. Und der Store ermöglicht es anderen, seine Daten aus der Ferne zu beobachten.

RxJS verwendet ebenfalls das reaktive Paradigma, aber anstatt eine Architektur zu sein, bietet es Ihnen grundlegende Bausteine, Observableum dieses Muster der „Beobachtung aus der Ferne“ zu erreichen.

Zusammenfassend lässt sich sagen, dass es sehr unterschiedliche Dinge für unterschiedliche Zwecke gibt, aber einige Ideen teilen.

Es sind sehr unterschiedliche Dinge.

RxJS kann für reaktive Programmierung verwendet werden und ist eine sehr umfassende Bibliothek mit mehr als 250 Operatoren.

Und Redux ist wie im Github-Repo beschrieben: „Redux ist ein vorhersehbarer Zustandscontainer für JavaScript-Apps“.

Redux ist lediglich ein Tool zur Statusverwaltung in Apps. Aber im Vergleich dazu könnten Sie eine vollständige App nur in RxJS erstellen.

Hoffe das hilft 🙂

Redux ist eine reine Zustandsverwaltungsbibliothek mit klar definierten Standards für Aktualisierungsvorgänge. Solange Sie sich an die Standards halten, können Sie Ihren Datenfluss vernünftig und leicht nachvollziehbar halten. Es bietet außerdem die Möglichkeit, den Datenfluss mit Middleware und Store-Enhancern zu verbessern.

RxJS ist ein Toolkit für reaktive Programmierung. Sie können sich eigentlich alles, was in Ihrer App passiert, als Stream vorstellen. RxJS bietet ein sehr umfangreiches Toolset zum Verwalten dieser Streams.

Wo fangen RxJS und Redux ab? In Redux aktualisieren Sie Ihren Status mit Aktionen und diese Aktionen können natürlich als Streams behandelt werden. Mit einer Middleware wie redux-observable (das ist nicht notwendig) können Sie Ihre sogenannte „Geschäftslogik“ reaktiv implementieren. Eine andere Sache ist, dass Sie ein Observable aus Ihrem Redux-Store erstellen können, was manchmal einfacher sein kann als die Verwendung eines Enhancers.

Um es kurz zu machen:

Redux: Von Fluss inspirierte Bibliothek, die für verwendet wird Staatsmanagement.

RxJS: Es handelt sich um eine weitere Javascript-Bibliothek, die auf der reaktiven Programmierphilosophie basiert und für den Umgang mit „Streams“ (Observablen usw.) verwendet wird. [Read about Reactive Programming to understand the Stream concepts].

Ich wollte nur einige pragmatische Unterschiede zu der Zeit hinzufügen, als ich Redux-inspirierten RxJS-Code erstellte.

Ich habe jeden Aktionstyp einer Subjektinstanz zugeordnet. Jede zustandsbehaftete Komponente verfügt über ein Subjekt, das dann einer Reduzierfunktion zugeordnet wird. Alle Reduzierströme werden mit kombiniert merge und dann scan gibt den Zustand aus. Der Standardwert wird mit eingestellt startWith kurz vor dem scan. ich benutzte publishReplay(1) für Staaten, wird aber möglicherweise später entfernt.

Die Renderfunktion „React Pure“ besteht darin, nur dort zu platzieren, wo Sie Ereignisdaten produzieren, indem Sie alle Produzenten/Subjekte einsenden.

Wenn Sie untergeordnete Komponenten haben, müssen Sie beschreiben, wie diese Zustände in Ihrem Zustand kombiniert werden. combineLatest könnte dafür ein guter Ausgangspunkt sein.

Bemerkenswerte Unterschiede in der Umsetzung:

• Keine Middleware, nur RXJS-Operatoren. Ich denke, das ist die größte Stärke und Schwäche. Sie können immer noch Konzepte ausleihen, aber es fällt mir schwer, Hilfe von Schwestergemeinschaften wie Redux und Cycle.js zu erhalten, da es sich um eine weitere benutzerdefinierte Lösung handelt. Deshalb muss ich in diesem Text „ich“ statt „wir“ schreiben.

• Kein Schalter/Fall oder Zeichenfolgen für Aktionstypen. Sie haben eine dynamischere Möglichkeit, Aktionen zu trennen.

• rxjs kann an anderer Stelle als Tool verwendet werden und ist nicht auf die staatliche Verwaltung beschränkt.

• Weniger Produzenten als Aktionstypen (?). Ich bin mir da nicht sicher, aber Sie können viele Reaktionen in übergeordneten Komponenten haben, die auf untergeordnete Komponenten hören. Das bedeutet weniger zwingenden Code und weniger Komplexität.

• Sie besitzen die Lösung. Kein Rahmen erforderlich. Gut und schlecht. Am Ende schreiben Sie sowieso Ihr eigenes Framework.

• Es ist viel fraktaler und Sie können problemlos Änderungen aus einem Unterbaum oder mehreren Teilen des App-Statusbaums abonnieren.

  • Ratet mal, wie einfach es ist, Epen zu erstellen, wie es Redux-Observable tun? Wirklich einfach.

Ich arbeite auch an viel größeren Vorteilen, bei denen die untergeordneten Komponenten als Streams beschrieben werden. Das bedeutet, dass wir den übergeordneten und untergeordneten Zustand nicht in den Reduzierern zusammenfassen müssen, da wir die Zustände einfach („nur“) rekursiv basierend auf der Komponentenstruktur kombinieren können.

Ich denke auch darüber nach, React zu überspringen und mit Snabbdom oder etwas anderem fortzufahren, bis React reaktive Zustände besser handhabt. Warum sollten wir unseren Staat nach oben aufbauen, um ihn dann über Requisiten wieder abzubauen? Deshalb werde ich versuchen, mit Snabbdom eine Version 2 dieses Musters zu erstellen.

Hier ist ein fortgeschrittenerer, aber kleinerer Ausschnitt, in dem die Datei „state.ts“ den Statusstream erstellt. Dies ist der Status der Ajax-Formularkomponente, die ein Objekt aus Feldern (Eingaben) mit Validierungsregeln und CSS-Stilen erhält. In dieser Datei verwenden wir lediglich die Feldnamen (Objektschlüssel), um alle untergeordneten Zustände im Formularzustand zusammenzufassen.

export default function create({
  Observable,
  ajaxInputs
}) {
  const fieldStreams = Object.keys(ajaxInputs)
  .map(function onMap(fieldName) {
    return ajaxInputs[fieldName].state.stream
    .map(function onMap(stateData) {
      return {stateData, fieldName}
    })
  })

  const stateStream = Observable.combineLatest(...fieldStreams)
  .map(function onMap(fieldStreamDataArray) {
    return fieldStreamDataArray.reduce(function onReduce(acc, fieldStreamData) {
    acc[fieldStreamData.fieldName] = fieldStreamData.stateData
    return acc
  }, {})
  })

  return {
    stream: stateStream
  }
}

Auch wenn der Code für sich genommen vielleicht nicht viel aussagt, zeigt er doch, wie Sie einen Status nach oben aufbauen und wie Sie problemlos dynamische Ereignisse erzeugen können. Der dafür zu zahlende Preis besteht darin, dass Sie einen anderen Codestil verstehen müssen. Und ich liebe es, diesen Preis zu zahlen.