Redux vs MobX ohne Verwirrung

Bild

In den letzten Jahren habe ich oft Redux verwendet , aber in letzter Zeit habe ich MobX als Alternative zur staatlichen Verwaltung verwendet. Redux-Alternativen scheinen sich natürlich in ein Chaos zu verwandeln. Die Leute sind sich nicht sicher, welche Lösung sie wählen sollen. Das Problem ist nicht unbedingt Redux vs MobX. Wann immer es eine Alternative gibt, sind die Leute neugierig, wie sie ihr Problem am besten lösen können. Ich schreibe diese Zeilen, um Verwirrung um Redux- und MobX-Statusverwaltungslösungen zu vermeiden.

Worum geht es in diesem Artikel? Zunächst möchte ich kurz auf das Problem zurückkommen, das die Zustandsverwaltungsbibliothek löst. Am Ende ist alles in Ordnung, wenn Sie nur this.setState () und this.state in React oder dessen Variation in einer anderen Bibliothek auf Präsentationsebene oder in einer SPA-Umgebung verwenden. Zweitens werde ich Ihnen weiterhin einen Überblick über beide Lösungen geben und dabei Konsistenz und Unterschiede aufzeigen. Und zu guter Letzt, wenn Sie bereits eine Anwendung haben, die mit MobX oder Redux funktioniert, möchte ich Sie über das Refactoring von einer Statusbibliothek in eine andere informieren.

Inhalt:


  1. Welches Problem lösen wir?
  2. Was ist der Unterschied zwischen REDUX und MOBX?
  3. Reaktionszustands-Lernkurve
  4. Aktuelle Gedanken zum Thema
  5. Mehr Ressourcen


Welches Problem lösen wir?


Jeder möchte eine staatliche Verwaltung in der Anwendung haben. Aber welches Problem löst das für uns? Die meisten Leute beginnen mit einer kleinen Anwendung und implementieren bereits eine Zustandsverwaltungsbibliothek. Alle reden darüber, oder? Redux! MobX! Die meisten Anwendungen benötigen jedoch von Anfang an kein ehrgeiziges staatliches Management. Dies ist umso gefährlicher, als die meisten Menschen niemals mit Problemen wie Bibliotheken wie Redux oder MobX konfrontiert werden .

Der Status Quo erstellt derzeit eine Front-End-Anwendung mit Komponenten. Komponenten haben einen internen Zustand. In einer wachsenden Anwendung kann das Staatsmanagement mit einem lokalen Staat chaotisch werden, weil:

  • Eine Komponente muss den Status mit einer anderen Komponente teilen
  • Eine Komponente muss den Status einer anderen Komponente ändern

Irgendwann wird es immer schwieriger, über den Status der Anwendung zu sprechen. Dies wird zu einem schmutzigen Netz von Statusobjekten und Statusmutationen in Ihrer Komponentenhierarchie. In den meisten Fällen sind Zustandsobjekte und Zustandsmutationen nicht unbedingt einer Komponente zugeordnet. Sie sind über Ihren Komponentenbaum verknüpft, und Sie müssen den Status erhöhen und senken.

Die Lösung besteht daher darin, eine Statusverwaltungsbibliothek wie MobX oder Redux einzuführen. Sie erhalten Tools, mit denen Sie Ihren Status speichern, den Status ändern und Statusaktualisierungen erhalten können. Sie haben einen Ort zum Suchen, einen Ort zum Ändern und einen Ort zum Empfangen von Statusaktualisierungen. Er folgt dem Prinzip einer einzigen Quelle der Wahrheit.. Dies erleichtert das Nachdenken über Änderungen in Ihrem Zustand und Ihren Bedingungen, da diese von Ihren Komponenten getrennt sind.

Statusverwaltungsbibliotheken wie Redux und MobX verfügen häufig über Add-Ons für Dienstprogramme. Für Angular verfügen sie beispielsweise über Angular-Redux und Mobx-Angular, um Ihren Komponenten Zugriff auf den Status zu gewähren. Oft werden diese Komponenten als containerisierte Komponenten oder genauer gesagt als verwandte Komponenten bezeichnet . Von überall in Ihrer Komponentenhierarchie können Sie auf den Status zugreifen und ihn ändern, indem Sie Ihre Komponente auf eine verwandte aktualisieren.


Was ist der Unterschied zwischen REDUX und MOBX?


Bevor wir uns mit dem Unterschied befassen, möchte ich Ihnen die Ähnlichkeiten zwischen MobX und Redux erläutern.

Beide Bibliotheken werden verwendet, um den Status in JavaScript-Anwendungen zu steuern. Sie sind nicht unbedingt mit einer Bibliothek wie Angular verknüpft. Sie werden auch in anderen Bibliotheken wie ReactJs und VueJs verwendet.

Wenn Sie sich für eine der Statusverwaltungslösungen entscheiden, wird keine Anbietersperre auftreten. Sie können jederzeit zu einer anderen Statusverwaltungslösung wechseln. Sie können ein Upgrade von MobX auf Redux oder von Redux auf MobX durchführen. Später werde ich Ihnen zeigen, wie das passiert.

Redux, entworfen von Dan Abramov und Andrew Clark, ist ein Derivat der Flux-Architektur. Im Gegensatz zu Flux wird ein Repository über mehrere verwendet, um den Status beizubehalten. Außerdem werden anstelle eines Dispatchers reine Funktionen verwendet, um den Status zu ändern. Wenn Sie mit dem Ablauf nicht vertraut sind und mit der Statusverwaltung noch nicht vertraut sind, machen Sie sich keine Sorgen über den letzten Absatz.

Redux wird von den Prinzipien der funktionalen Programmierung (FP) beeinflusst. FP kann in JavaScript ausgeführt werden, aber viele Menschen haben einen objektorientierten Hintergrund wie Java und haben Schwierigkeiten, die Prinzipien der funktionalen Programmierung überhaupt zu akzeptieren. Dies erklärt später, warum MobX als Anfänger möglicherweise einfacher zu erlernen ist.

Da Redux eine funktionale Programmierung enthält, werden reine Funktionen verwendet .
Eine reine Funktion ist eine Funktion, die Eingaben empfängt, Ausgaben zurückgibt und keine anderen Abhängigkeiten als dieselben Funktionen aufweist. Eine solche Funktion erzeugt immer den gleichen Ausgang mit dem gleichen Eingang und hat keine Nebenwirkungen. Mehr Details

(state, action) => newState

Ihr Redux-Status bleibt unverändert . Anstatt zu mutieren, geben Sie immer einen neuen Status zurück. Sie führen keine Zustandsmutationen durch und sind nicht von Objektreferenzen abhängig.


//     Redux,     
function addAuthor(state, action) {
  return state.authors.push(action.author);
}
//       
function addAuthor(state, action) {
  return [ ...state.authors, action.author ];
}

Und zu guter Letzt wird in idiomatischem Redux Ihr Status wie in einer Datenbank normalisiert . Entitäten verweisen nur durch ID aufeinander . Dies ist die beste Vorgehensweise. Obwohl dies nicht jeder tut, können Sie eine Bibliothek wie normalizr verwenden , um einen solchen normalisierten Zustand zu erreichen. Mit dem normalisierten Zustand können Sie einen flachen Zustand und Entitäten als eine einzige Quelle der Wahrheit beibehalten .

{
  post: {
    id: 'a',
    authorId: 'b',
    ...
  },
  author: {
    id: 'b',
    postIds: ['a', ...],
    ...
  }
}



Im Vergleich dazu wird Michel Weststratts MobX nicht nur von der objektorientierten Programmierung, sondern auch von der reaktiven Programmierung beeinflusst. Es hüllt Ihren Zustand in beobachtbare Objekte. Somit haben Sie alle Funktionen von " Observable " in Ihrem Bundesstaat. Daten können einfache Setter und Getter haben, aber Observable ermöglicht es Ihnen, Aktualisierungen nach Datenänderungen zu erhalten.

In Mobx ist Ihr Status volatil . Auf diese Weise ändern Sie den Status direkt:

function addAuthor(author) {
  this.authors.push(author);
}

Darüber hinaus bleiben Organisationen in einer (tief) verschachtelten Datenstruktur zueinander. Sie normalisieren Ihren Zustand nicht. Der Zustand bleibt denormalisiert und eingebettet.

{
  post: {
    id: 'a',
    ...
    author: {
      id: 'b',
      ...
    }
  }
}

Ein Repository gegen mehrere


In Redux speichern Sie Ihren gesamten Status in einem globalen Repository oder in einem globalen Status . Ein einzelnes Zustandsobjekt ist Ihre einzige Quelle der Wahrheit. Zahlreiche Getriebe hingegen ermöglichen es, einen unveränderlichen Zustand zu ändern.

Im Vergleich dazu verwendet MobX mehrere Repositorys. Wie bei Redux-Reduzierern können Sie die Trennung und Eroberung nach technischer Ebene, Domäne usw. anwenden. Sie können Ihre Domänenobjekte in separaten Repositorys speichern, aber Sie können auch den Anzeigestatus in Ihren Repositorys steuern. Am Ende platzieren Sie den Status, der für Ihre Anwendung am besten geeignet ist.

Technisch gesehen können Sie in Redux auch mehrere Repositorys haben. Niemand zwingt Sie, nur einen zu verwenden. Dies ist jedoch kein beworbener Anwendungsfall von Redux. Die Verwendung mehrerer Repositorys widerspricht den Best Practices. In Redux möchten Sie ein Repository haben, das über seine Reduzierungen auf globale Ereignisse reagiert.

Wie sieht die Implementierung aus?


Unter Redux sind zum Hinzufügen der Konfiguration einer Anwendung zu einem globalen Status die folgenden Codezeilen erforderlich.

const initialState = {
  users: [
    {
      name: 'Alex'
    },
    {
      name: 'Nik'
    }
  ]
};
// reducer
function users(state = initialState, action) {
  switch (action.type) {
  case 'USER_ADD':
    return { ...state, users: [ ...state.users, action.user ] };
  default:
    return state;
  }
}
// action
{ type: 'USER_ADD', user: user };

In MobX verwaltet der Speicher nur den Unterzustand (da der Reduzierer in Redux den Unterzustand steuert), Sie können den Status jedoch direkt ändern. Mit der Annotation @observable können Sie Statusänderungen beobachten.

class userStore{
@observable users = [
    {
      name: 'Nikita'
    }
  ];
}

Jetzt können Sie userStore.users.push (user) aufrufen. auf der Kopie des Ladens. Es wird jedoch empfohlen, dass Zustandsmutationen durch Aktion expliziter werden.

class userStore{
@observable users = [
    {
      name: 'Nikita'
    }
  ];
}
@action addUser = (user) => {
    this.users.push(user);
  }

Sie können es strikt anwenden, indem Sie MobX mit configure ({empceActions: true}) konfigurieren. Jetzt können Sie Ihren Status ändern, indem Sie userStore.addUser (user) aufrufen. auf der Kopie des Ladens.

Sie haben gesehen, wie Sie den Status sowohl auf Redux als auch auf MobX aktualisieren. In Redux ist Ihr Status schreibgeschützt . Sie können den Status nur mit expliziten Aktionen ändern . Im Gegensatz dazu umfasst der Status in MobX das Lesen und Schreiben. Sie können den Status direkt ändern, ohne Aktionen zu verwenden. Sie können jedoch explizite Aktionen mithilfe der Konfiguration von assertceActions auswählen.


Reaktionszustands-Lernkurve


Sowohl Redux als auch MobX werden hauptsächlich in React-Anwendungen verwendet. Dies sind jedoch eigenständige Statusverwaltungsbibliotheken, die ohne React überall verwendet werden können. Ihre Interaktionsbibliotheken erleichtern die Kombination mit Angular-Komponenten. Dies sind React -Redux für React + Redux und Mobx- React für React + MobX . Später werde ich erklären, wie beide im Angular-Komponentenbaum verwendet werden.

In jüngsten Diskussionen haben sich die Leute über die Lernkurve in Redux gestritten. Dies geschah häufig im Zusammenhang mit React: Die Leute lernten React und wollten bereits das Statusmanagement mit Redux verwenden. Die meisten Leute behaupten, dass React und Redux selbst eine gute Lernkurve haben, aber beide können überwältigend sein. Daher wird MobX eine Alternative sein, da es eher für Anfänger geeignet ist.

Ich würde jedoch neuen React-Benutzern einen anderen Ansatz vorschlagen, um mehr über das Statusmanagement im React-Ökosystem zu erfahren. Beginnen Sie mit dem Lernen Reagieren Sie mit Ihren eigenen lokalen Statusverwaltungsfunktionen in Komponenten. In einer React-Anwendung lernen Sie zunächst die React-Lebenszyklusmethoden kennen und erfahren, wie Sie lokale Zustände mit setState () und this.state verwalten. Ich kann diesen Lernpfad nur empfehlen. Andernfalls werden Sie schnell vom React-Ökosystem überwältigt. Am Ende werden Sie feststellen, dass die Verwaltung des (internen) Zustands der Komponenten kompliziert wird.

Redux oder MobX für Anfänger?


Wenn Sie sich mit Angular-Komponenten und der internen Statusverwaltung vertraut machen, können Sie eine Statusverwaltungsbibliothek auswählen, um Ihr Problem zu lösen. Nachdem ich beide Bibliotheken verwendet habe, würde ich sagen, dass MobX für Anfänger sehr praktisch sein kann. Wir haben bereits gesehen, dass MobX weniger Code benötigt, obwohl es einige magische Notizen verwendet, über die wir noch nichts wissen müssen.
Mit MobX müssen Sie nicht mit der funktionalen Programmierung vertraut sein. Begriffe wie Unveränderlichkeit können noch fremd sein.
— , JavaScript. , , - , , MobX.


Redux


Wenn Ihre Anwendung größer wird und mehrere Entwickler daran arbeiten, sollten Sie Redux verwenden. Von Natur aus verpflichtet er sich, explizite Maßnahmen zu ergreifen, um den Zustand zu ändern. Die Aktion hat einen Typ und eine Nutzlast, mit denen das Getriebe den Zustand ändern kann. Für das Entwicklungsteam ist es sehr einfach, auf diese Weise über Zustandsänderungen zu sprechen.

Redux bietet Ihnen eine vollständige Architektur für die Verwaltung des Status mit klaren Einschränkungen. Redux Erfolgsgeschichte .

Ein weiterer Vorteil von Redux ist die Verwendung auf der Serverseite. Da es sich um einfaches JavaScript handelt, können Sie den Status über das Netzwerk senden. Die Serialisierung und Deserialisierung eines Statusobjekts funktioniert sofort. Dies ist jedoch auch mit MobX möglich.

MobX ist weniger selbstbewusst, aber mit configure ({empceActions: true}) können Sie genauere Einschränkungen anwenden, wie in Redux. Deshalb würde ich nicht sagen, dass Sie MobX nicht zum Skalieren von Anwendungen verwenden können, aber Redux hat eine klare Möglichkeit, etwas zu tun. In der MobX-Dokumentation heißt es sogar: „ [MobX] sagt Ihnen nicht, wie Sie Ihren Code strukturieren, wo Sie den Status speichern oder wie Sie mit Ereignissen umgehen .“ Das Entwicklungsteam müsste zunächst eine Zustandsverwaltungsarchitektur erstellen.

Immerhin ist die Lernkurve für das Staatsmanagement nicht so steil. Wenn wir die Empfehlungen wiederholen, lernt ein Neuling bei React zunächst, wie man setState () und this.state richtig verwendet . Nach einer Weile werden Sie die Probleme verstehen , nur setState () zu verwenden.um den Status in der React-App beizubehalten. Bei der Suche nach einer Lösung stoßen Sie auf Statusverwaltungsbibliotheken wie MobX oder Redux. Aber welches soll man wählen? Da MobX weniger selbstbewusst ist, eine kleinere Vorlage hat und auf die gleiche Weise wie setState () verwendet werden kann, würde ich empfehlen, MobX in kleinen Projekten eine Chance zu geben. Sobald die Anwendung größer wird und die Anzahl der Teilnehmer steigt, sollten Sie erwägen, zusätzliche Einschränkungen in MobX anzuwenden oder Redux eine Chance zu geben. Ich mochte beide Bibliotheken. Auch wenn Sie am Ende keine davon verwenden, ist es sinnvoll, eine alternative Methode zur Verwaltung des Status zu finden.


Letzte Gedanken


Wann immer ich die Kommentare in der Diskussion von Redux gegen MobX lese, gibt es immer einen Kommentar: „ Redux hat zu viel Standard, Sie sollten stattdessen MobX verwenden. Ich konnte XXX Codezeilen löschen . " Der Kommentar mag wahr sein, aber niemand erwägt einen Kompromiss. Redux wird mit vielen Vorlagen wie MobX geliefert, da es für bestimmte Designeinschränkungen hinzugefügt wurde. Auf diese Weise können Sie über den Status Ihrer Anwendung nachdenken, auch wenn diese in größerem Maßstab vorliegt. Die ganze Zeremonie, die mit der Behandlung des Staates verbunden ist, ist nicht gerecht.

Die Redux-Bibliothek ist ziemlich klein. Meistens beschäftigen Sie sich nur mit einfachen JavaScript-Objekten und -Arrays.. Dies ist näher an Vanille-JavaScript als an MobX. In MobX werden Objekte und Arrays in beobachtbare Objekte eingeschlossen, die den größten Teil der Standardvorlage verbergen. Es basiert auf verborgenen Abstraktionen, in denen Magie vorkommt, aber es ist schwieriger, die grundlegenden Mechanismen zu verstehen. Redux macht es einfacher, mit einfachem JavaScript darüber zu sprechen. Dies erleichtert das Testen und Debuggen der Anwendung.

Außerdem müssen Sie noch einmal darüber nachdenken, woher wir im SPA kamen. Eine Reihe von einseitigen Frameworks und Anwendungsbibliotheken hatten dieselben Statusverwaltungsprobleme, die letztendlich mithilfe eines umfassenden Stream-Modells behoben wurden. Redux ist der Nachfolger dieses Ansatzes.

In MobX bewegt es sich wieder in die entgegengesetzte Richtung. Wir beginnen wieder, den Zustand direkt zu mutieren, ohne die funktionale Programmierung zu nutzen. Für einige Leute nähert sich dies wieder der bidirektionalen Datenbindung. Nach einiger Zeit können wieder dieselben Probleme auftreten, bevor eine Statusverwaltungsbibliothek wie Redux angezeigt wird. Das Zustandsmanagement ist über die Komponenten verteilt und endet in Unordnung.

Während Sie auf Redux eine festgelegte Zeremonie für die Einrichtung haben, ist MobX weniger selbstbewusst. Es wäre jedoch ratsam, das beste MobX-Erlebnis zu akzeptieren. Die Menschen müssen wissen, wie sie das Staatsmanagement organisieren können, um ihre Argumente darüber zu verbessern. Andernfalls neigen Menschen dazu, den Status direkt in den Komponenten zu ändern.

Beide Bibliotheken sind großartig. Obwohl Redux bereits gut etabliert ist, wird MobX zu einer praktikablen Alternative zum staatlichen Management.


Mehr Ressourcen


Vergleich von Michel Weststratt - Schöpfer von
MobX

All Articles