Haftungsausschluss
Sehr geehrter Leser! Wenn Sie keine Ahnung haben, was React und Redux sind, macht es keinen Sinn, weiterzulesen, weiterer technischer Unsinn. Um zu verstehen, wofür diese Notiz gedacht ist, muss ich ernsthaft mit diesen Bibliotheken arbeiten. Trotz der Tatsache, dass ich versuchen werde, klar zu schreiben, handelt es sich bei diesem Artikel nicht um einen Einstiegsartikel. Und dies ist eine persönliche Erfahrung und Meinung, die auf der Praxis basiert.
Was ist falsch an der Verwendung von Redux?
Dann habe ich beschlossen zu schreiben, aber was ist eigentlich falsch daran, Redux in meinem Projekt und Tausenden anderen zu verwenden? Ich schreibe seit April 2016 (drei Jahre) React / Redux-Anwendungen. Es ist Zeit, bereits einige interessante Dinge zu entdecken ... Und dann gab es Vorträge und Berichte, die sich speziell an Anfänger richteten, aber es gab keinen Rückblick für Erwachsene und keine Retrospektive. In der Zwischenzeit setzt jemand Sternchen in Pakete, die prüfen, ob Sie nicht 13 pro Stunde sind. Ich werde die Mauer der vorherrschenden Stereotypen durchbrechen.
Redux wird aber nicht benötigt!
Sie sagen, und in gewisser Weise werden Sie Recht haben. Sie können es seit 2018 nicht mehr verwenden - es gibt eine Menge Artikel zu diesem Thema im Internet, aber bis jetzt erhalten Sie mit der "Nichtbenutzung" eine Kollektivfarm. Im Folgenden wird klar, warum. Und die Anzahl der Alternativen ist nicht skalierbar und noch mehr.
Wir verwenden Redux, da es ein akzeptierter Standard ist (zumindest für die Reaktion). Die Vorhersehbarkeit und Zuverlässigkeit von Redux sind uns wichtig. Aber wir vermissen es ernsthaft, eigentlich darin
Anspruch
Um klar zu machen, was die Behauptung über die Punkte ist, müssen Sie wahrscheinlich zuerst in die Vergangenheit zurückkehren, zu den Ursprüngen, wie Sie möchten, nämlich die Dokumentation des glorreichen Redux öffnen und die Postulate lesen. Ich werde nur den ersten von ihnen betrachten. Wenn es für Sie interessant sein wird - teilen Sie die Kommentare mit, ich werde viele weitere Punkte analysieren.
Die einzige Quelle der Wahrheit ...
Hier haben wir einen Hinterhalt. Natürlich heißt es, dass es eine Geschichte geben kann, Redux erklärt auf diese Weise seinen Unterschied zur Flussarchitektur. Aber wenn Sie breiter schauen: Wird die Regel in einem realen Projekt eingehalten? Sie werden sagen: ganz. Ich deklariere (deklariere) 1 Seite, übertrage sie an den Anbieter und dann ...
Technisch wird der Prozess korrekt beschrieben. Aber ich kann sagen, dass Menschen Wahrnehmungs- und Logikverzerrungen ausgesetzt sind, und da Programmierer immer noch Menschen sind ... Nun, Sie verstehen, wohin ich führe (wenn Sie nicht verstanden haben: Programmierer neigen zu Wahrnehmungs-, Logik- usw. Verzerrungen).
Die Hauptverzerrung dabei ist, dass ich, wie viele meiner Kollegen, daran gewöhnt bin, dass es keine anderen gibt, wenn wir den Begriff "Speichern" nicht in Bezug auf etwas anderes als Redux verwenden.
Und hier kommt die Reaktion
Ein technisches Merkmal namens interner Zustand wollte auf dieses Postulat spucken. Es wird einfach an jedem geeigneten Ort ein Speicher vom Typ interner Zustand erstellt. Es gibt eine Komponente - es gibt einen Status, der über einen Mechanismus zum Aktualisieren und Beeinflussen der Komponente verfügt. Der Unterschied in der Verwendung (Speicherstatus, Aktualisierung und Broadcast-Änderungen) ist nahezu unsichtbar. Sie können Einwände erheben: Es ist nicht ganz klar, warum Ihnen der Komponentenstatus nicht gefällt. Er ist nicht wie Redakteure, wie können sie überhaupt verglichen werden! Es ist intern, welche Flags dort gespeichert werden sollen.
Verstehen Sie, dass sich das Wesentliche nicht dadurch ändert, dass Sie das Element umbenennen. Es gibt einen Vorschlaghammer Montag, dies macht es nicht zum Wochentag. Ja, beide Montage sind hart, andere Tage und Vorschlaghammer sind einfacher. Aber nach seinem Namen hört der Vorschlaghammer nicht auf, ein Schlaginstrument zu sein.
Das Ausmaß der Redux- und Zustandsreaktionskomponente ist unterschiedlich, aber die Essenz, wenn sie heute verwendet wird, ist eine.
Ich werde es so erklären: In den meisten Fällen gehen die Daten aus dem internen Zustand der Komponente über Requisiten an das Kind, aber egal wie offensichtlich es ist, Redux-Daten gehen, wenn sie in React integriert sind, auch über Requisiten an die Komponenten. Aus der Sicht der Komponente, die Requisiten akzeptiert, spielt es keine Rolle, was sich draußen befindet. Das heißt, für den Endbenutzer - diesen Redux-Speicher, diesen internen Status - ist derselbe.
Dieser interne Status hängt möglicherweise auch nicht von den Requisiten der Komponente ab, in der er deklariert ist. Dann bekommen wir Isolation, die einen solchen internen Zustand zu einem noch größeren Geschäft macht, als Sie sich vorstellen können.
Damit es wirklich intern ist, sollte es nur die Komponente betreffen, in der es deklariert ist, ohne dass die untergeordneten Komponenten undicht werden. Ist es schwierig Ganz, weil seine Bedeutung fast völlig verloren geht. Dies ist ein weiteres Zeichen dafür, dass der interne Status ein Geschäft ist. Schließlich haben wir einfach einen Punkt aus dem Zweck entfernt, „den Status zu speichern, Änderungen zu aktualisieren und zu senden“ - die Änderungen zu senden. Alles, der Staat ist verloren.
Das heißt, das Hauptproblem bei einem internen Status besteht darin, dass er mit Redux um Daten konkurriert, auf lange Sicht verliert und Mist macht. Wir haben alle Arten von Techniken wie das Aufheben des Status (dies ist der Zeitpunkt, an dem das Geschwister des Host-Elements benötigt wird, sodass der Status-Teil und die gesamte Logik der Arbeit damit dem übergeordneten Element übergeben werden, wobei viel Zeit für das Umschreiben und Testen der Arbeitslogik aufgewendet wird) usw. Fehler und Overhead treten auf in Verbesserungen und viel Freude. Dies ist all das Rauschen, das unsere Software in der Entwicklungsphase verdirbt. Wir haben noch keinen Umsatz erreicht, aber die Software ist schon so.
Das heißt, trotz aller Anzeichen und Probleme haben wir mehr als eine Geschichte und viele damit verbundene Probleme. Das Letzte wird wahrscheinlich das Folgende sein:
Ich liebe Redux auch für die Art von Devtools, die es hat. Als ich anfing, verwendeten wir einen Logger, der einfach alle Aktionen konsolidierte, ohne jedoch ein vollständiges Bild davon zu geben, was geschah. Nun - das ist der Hauptassistent und Freund. Bei React sind sie ebenfalls vertreten. Im Allgemeinen ist devtools der Grund, warum jeder Pubsub weit von Redux entfernt ist. Wie eine Ameise für einen Blauwal.
Probleme (es gibt keine DNA-Beweise):
- Das Ändern des internen Zustands durch React Devtools führt manchmal nicht zu einem Update oder dem gewünschten Ergebnis - ich sündige bei der Integration mit Redux.
- Der interne Zustand unterbricht den Zeitverlauf in Redux-Devtools. Die Superfunktion mit Zeitreisen, die über die Redux-Architektur verfügbar sind, funktioniert dank der reaktionsfähigen internen Zustandsarchitektur nicht. Der interne Zustand kümmerte sich einfach nicht um eine Änderung des Redux, er hat seinen eigenen Zustand. Timetravel funktioniert einfach nicht. Einige Elemente werden einfach nicht aktualisiert, teilweise aktualisiert usw. All dieses Epos mit asynchroner Codesynchronisation im Abfluss.
Ein Beispiel natürlich aus der Praxis gesaugt
Sie arbeiten an einem neuen Projekt für Sie, oder Ihr Kollege hat vor einem Jahr einige Funktionen geschrieben, und jetzt müssen Sie es erweitern. Im Allgemeinen besteht die Aufgabe darin, den Code eines anderen zu finalisieren. Sie beginnen zu untersuchen und verstehen, dass die Editoren keine Daten enthalten. Es gibt keine Aktionen, Reduzierungen im Code, die die Daten speichern, die Sie benötigen. Und du beginnst die Reise durch den Baum der Komponenten auf der Suche nach dem Schatz und findest sie (!!!) sogar ein paar Stücke. Sie fragen Kollegen, aber die Antwort ist Standard: Ich kann mich nicht erinnern, schneller an den Staat geschrieben zu haben, wir hatten keine Zeit und so weiter. Sie gehen zur Quelle und verstehen, dass der aktuelle Status keine Überarbeitung beinhaltet. Sie schreiben funktionierenden, getesteten Code neu, um Änderungen vorzunehmen und neue Funktionen hinzuzufügen.
Das Vorhandensein einer schädlichen Alternative in Form eines inneren Zustands tut seine schmutzige Tat. Immerhin ist es jetzt billig und es spielt keine Rolle, was in einem Jahr passiert.Nur wenige Metaphern
Es sieht aus wie schlechtes Essen - es scheint lecker und billig zu sein, aber nach ein oder drei Jahren hört der Magen-Darm-Trakt auf zu gehorchen und lebt sein eigenes Leben. Sie investieren viel Zeit und Geld in die Wiederherstellung Ihrer früheren Gesundheit und schaffen dies nicht immer.
Redux und React Internal State sind Wettbewerber als große und kleine Unternehmen in einer Nische. Das Hauptprodukt sind Daten und Einfluss. Software ist der Verbraucher ihrer Produkte. Es gibt viele Analogien, aber das Wesentliche bleibt dasselbe - wenn wir Software entwickeln, brauchen wir keinen Wettbewerb.
Wir sind die „Diktatoren“ des Programmcodes, und jeglicher Wettbewerb sollte unterdrückt werden, der freie Markt sollte verboten werden und die Planwirtschaft und das staatliche Monopol sollten den Verbraucher dominieren.Ähm, etwas langweilte mich. Im Allgemeinen sollte alles nach Plan verlaufen. Wir haben Sprints, Releases und mehr, und die Software hat begrenzte Kosten und eine Lebensdauer / Markteintritt. Dies ist sehr wichtig, und wir können den Aufstand auf dem Schiff, den Aufstand der Bibliotheken, nicht zulassen.
Die Schlussfolgerung ist einfach.
Verwenden Sie keine anderen Repositorys mit Redux. Ausnahmen können nur sehr Einzelfälle machen. Zum Beispiel Komponenten, die im Prinzip nicht durch Redux ohne die entsprechende Schicht gesteuert werden und diese nicht beeinflussen.
Beispiel
Ich habe das eigenständige Modul in einer Filiale entwickelt und das Geschäft in einer anderen umgestaltet. Im Allgemeinen ist mein Ansatz zur Verwaltung des Geschäfts und des Status ein separates Thema für die Veröffentlichung. Ich habe mit dem Refactoring des Moduls begonnen, aber zum Zeitpunkt des Beginns und des Endes des Schreibens des Moduls ist das Refactoring des Tests und des Assistenten nicht verschwunden. Refactoring ist umfangreich und erfordert einen durchdachten Rückgriff, der geplant werden muss - im Allgemeinen können Sie nicht einfach ein Refactoring durchführen.
Da ich über die bevorstehenden Änderungen im Geschäft Bescheid wusste, habe ich es nicht verwendet, um eine neue Funktion zu entwickeln. Dies würde die Kosten für die zeitweise Aktualisierung abgebrochener Umgestaltungen und Tests erhöhen.
Was ich getan habe: Ich habe mich für ein Minimum an Daten angemeldet. Daten und ihre Struktur haben nicht unter Refactoring gelitten, der Code, der sie generiert hat, hat gelitten, wurde gespeichert usw. Ich habe kein Byte an die Editoren geschrieben. Ich überprüfe, ob der Benutzer angemeldet ist und noch ein paar Felder.
Für meine Bedürfnisse habe ich PubSub mit Kanälen und einer einfachen API gewaschen. Ja, ja, Pubsab. Mangel an normalen schmerzhaften Schmerzen. Zeitreise - Schmerz. Im Allgemeinen plane ich, eine Erweiterung für Chrome in Form von Devtools zu schreiben, und es ist möglich, die Neuimplementierung als Konkurrent von Redux auf dem Github zu veröffentlichen. Ich habe eine Menge Beschwerden über Redux, die ich in diesem Artikel nicht ansprechen werde, aber PubSub hat sie praktisch nicht. Neben der Tatsache, dass ich mich an Redux Logger erinnerte ...
Das Modul verfügt also über einen eigenen Speicher, eine eigene Verbindung zum Server.
Das heißt, Redux wirkt sich überhaupt nicht auf das Modul aus, kann diesen Speicher praktisch nicht beeinflussen (es gibt nur drei Felder im Abonnement), aber das Modul und PubSub wirken sich in keiner Weise auf Redux aus. Diese Trennung schließt den Wettbewerb aus.
Die Frage "Wo sollen die Daten gespeichert werden?" Bei der Entwicklung des Moduls bin ich noch nie darauf gestoßen. Aber wenn es um Redux gegen internen Zustand geht - für viele stellt sich diese Frage fast ständig. Ich habe beschlossen, diese Frage ein für alle Mal zu beantworten.
Meine architektonische Meinung ist:
Speichern Sie Daten nur in Redux (alles in allem, sogar "intern"). Wenn sie mit Ihrem Reaktionsprojekt als Haupt-Repository verbunden sind, verwenden Sie keine Repositorys, die mit diesem konkurrieren. Dies erhöht die Zuverlässigkeit und Wirkung dieser Bibliothek und ihrer Devtools (Zeiterfassung und Verfolgung aller Daten in Schritten beschleunigen die Entwicklung und Suche nach möglichen Problemen - synchrone Änderungen sind steiler und leichter asynchron).
Vielleicht lohnt es sich, eine Bibliothek hinzuzufügen, die den internen Zustand vollständig von der Entwicklung ausschließt? Oder ersetzt der interne Zustand zum Beispiel durch eine Auswahl aus Redux? Ich habe vor einem solchen Jahr angefangen, einen zu schreiben, bin zu 90 Prozent fertig geworden und habe sogar einen Bericht erstellt. Was sagst du Brauchen Sie die?
Ich hoffe dir hat diese Notiz gefallen :)