5 Gründe, warum Sie Redux in React-Anwendungen vergessen sollten

Ich arbeite seit fast 3 Jahren mit React, habe sowohl Redux als auch MobX verwendet und habe jetzt eine Frage. Warum ist die überwiegende Mehrheit der Front-End-Entwickler weiterhin der festen Überzeugung, dass Redux + Redux Saga + Reselect + 100500 andere Bibliotheken, die das Leben erleichtern, die beste Lösung sind? Ich werde 4 Argumente für die Verwendung von MobX anstelle von Redux im nächsten Projekt angeben.

Mit MobX können Sie immer saubereren Code schreiben


Lassen Sie uns zwei Code-Teile speichern, die dasselbe tun. So sieht der Reduzierer in Redux aus:

Bild

Um den Status zu ändern, müssen Sie in der Terminologie des Editors eine Aktion aufrufen:

Bild

In den meisten Fällen (nicht immer, aber dies sind die „Best Practices“, die in vielen Projekten verwendet werden) müssen Sie ein solches Boilerplate schreiben :

Bild

Dann muss der Store initialisiert werden (dies muss nur einmal durchgeführt werden, aber immer noch):

Bild

Und wirf unser initialisiertes Gate über den Provider weiter in die Anwendung (auch ein einmaliger Vorgang):

Bild

Jetzt können Sie einige Vorgänge mit Daten in Ihren Komponenten ausführen:

Bild

Es stellt sich heraus, dass im Fall von Redux, um die Daten in Ihrem Speicher zu ändern, Sie einige Funktionen aufrufen müssen, die ein neues Statusobjekt erstellen ... Für mich persönlich klingt dies wie völliger Unsinn. Schauen wir uns die gleiche Funktionalität an, die MobX bietet. Unsere Seite:

Bild

Und dann können Sie es in der Komponente verwenden:

Bild

Ja, das ist richtig, anstatt einiger Funktionen, die Objekte modifizieren, können Sie den klassischen OOP-Ansatz mit Klassen, ihren Eigenschaften und Methoden verwenden. Haben Sie keine Angst vor den enthaltenen Dekoratoren (@), sondern fügen Sie lediglich die Funktionen hinzu, die zum Nachverfolgen von Datenänderungen erforderlich sind. Übrigens wird in Angularjs ein ähnlicher Ansatz mit Klassen zum Speichern von Daten verwendet (Bildschirm von hier angle.io/start/data ):

Bild

Mit MobX können Sie weniger Code schreiben


Schauen Sie sich dazu einfach die obigen Beispiele an. Und jetzt können Sie sich endlich darauf konzentrieren, die Geschäftslogik der Anwendung zu schreiben, anstatt ein endloses Boilerplate zu schreiben, was eine gute Nachricht ist.

Drittens Leistungsoptimierung


Wenn Sie sich die obigen Beispiele ansehen, können Sie sehen, dass ich im Fall von MobX keine reine Komponente verwendet habe und dies kein Fehler ist. In diesem Fall ist keine Optimierung erforderlich, da Ihre Komponente nur dann neu gerendert wird, wenn sich die darin verwendeten Daten ändern. Und ja, Sie können Pure Components, shouldComponentUpdate und was Sie sonst noch in diesen Fällen verwenden, vergessen. Im Idealfall sollte jede Ihrer Komponenten, die nicht HOC ist und einige Daten aus dem Speicher verwendet, beobachtbar sein, und dann werden Sie Probleme mit der Optimierung für immer vergessen.

Viertens - weniger Abhängigkeiten


Jeder, der Redux verwendet, sollte aus erster Hand wissen, dass viele „wundervolle“ Bibliotheken enthalten sind. Und es ist gut, wenn es sich nur um einen Thunk handelt, oder vielleicht ist es auch so, dass die Entwickler dem Pfad des Lichts der Dunkelheit folgen und Redux Saga, Reslect und eine Reihe seltsamer Bibliotheken verwenden möchten, die Ihren Code nicht nur langsamer, sondern auch schwieriger zu verstehen machen. Und einige kleinere Funktionen zu beenden oder einen Fehler in dieser Arbeit zu finden, wird unglaublich schwierig und lang sein. MobX ist die ultimative Lösung, da keine zusätzlichen Bibliotheken erforderlich sind, werden Sie all dieser Reize beraubt, sodass die Geschäftslogik Ihrer Anwendung sauber bleibt, wie die Träne eines Babys.

UPD. Danke MaZaAa

Der fünfte Grund ist die Möglichkeit, setState zu verlassen


setState hat eine Reihe von Nachteilen (eine kurze Übersetzung des Artikels, die hier im Original zu lesen ist ):

1. Es ist asynchron.


Dies kann zu unerwartetem Verhalten führen:

Bild

Auf dem obigen Bildschirm sollte die Warnung 2 gewesen sein, aber da setState asynchron ist, erfolgt sie später.

2. setState führt zu unnötigen Komponenten-Renderern:


a. Es wird auch dann gerendert, wenn der neue Wert == der alte Wert ist.
B. Es gibt Situationen, in denen eine Statusänderung zu keiner Änderung führt, z. B. wenn Bedingungen für die Anzeige des Status vorliegen, in denen. Auf dem Screenshot unten ist beim Rendern ein Klick aufgetreten, obwohl die Daten aufgrund der fasle: -Bedingung nicht gerendert werden sollten

Bild

. Manchmal spielen die von setState aktualisierten Daten beim DOM-Rendering überhaupt keine Rolle (z. B. Timer). Und trotzdem wird die Komponente gerendert.

3. setState ist bei weitem nicht für alle Fälle geeignet.


Es gibt Komponenten, die Hooks / Methoden des Komponentenlebenszyklus verwenden. In diesem Fall wird nicht nur ein zusätzlicher Renderer ausgeführt, sondern diese Ereignisse (Hooks) werden jedes Mal gleichzeitig aufgerufen, was zu merkwürdigem Verhalten führen kann.

Die Verwendung von MobX schützt Sie vor diesen Nachteilen, da Sie setState vollständig aufgeben können:

Bild

Wenn Sie mit etwas nicht einverstanden sind oder ich etwas nicht verstehe, geben Sie in den Kommentaren Gegenargumente an. Link zur Sandbox, aus der Screenshots von MobX stammen: codesandbox.io/s/mobxreact-s7db5 , c Redux: codesandbox.io/s/oj7px08qy9

Jetzt auch beliebt: