Es überrascht niemanden, dass JavaScript ist überall.
Hier bei Imaginary Cloud, die meisten Projekte, an denen wir beteiligt sind, verwenden es als Hauptsprache. Mein letztes Projekt war ein ziemlich umfangreicher Antrag, an dem die üblichen Schuldigen beteiligt waren JavaScript-Ökosystem. Wir haben ein React-Frontend und einen Node.js Backend-Stack verwendet.
Als wir für dieses Projekt einen Stack definieren mussten, da es viel visuelle Präsentation und 3D-Modellierung beinhaltet, bot sich React in Bezug auf die Frontend-Technologie als eine einfache Wahl an.
Leider war zu dieser Zeit keine klare Strategie für die Staatsverwaltung definiert. Im Zuge der Weiterentwicklung des Projekts wurde es zu einem Problem, weshalb das Team beschloss, die gesamte Logik im Zusammenhang mit der Zustandsverwaltung auf eine Klasse zu migrieren, die sich als Singleton präsentierte. Das würde bei all dem Speicher und den Ereignissen helfen, die mit dem Status zusammenhängen. Kurzfristig war diese Lösung in Ordnung, aber irgendwann würde sie seinen Nutzen übersteigen und es wurde ein Plan in die Wege geleitet, um eine bessere Alternative zu finden. Sie kam in Form von Redux, unterstützt durch die Einführung von Redux-Werkzeugsatz, früher bekannt als Redux Starter Kit.
Redux ist ein State-Container für JavaScript-Anwendungen, mit dem Sie den natürlichen unidirektionalen React-Datenfluss umgehen können. Das ist möglich, da er über eine Informationsquelle verfügt, die Sie in Ihrer gesamten Anwendung einsehen können, ohne dass Sie als Grundlage für andere Komponenten einen Drilldownstate durchführen müssen. Es ermöglicht Ihnen jedoch auch, mithilfe vordefinierter Aktionen Änderungen vorzunehmen und gleichzeitig eine Historie solcher Aktionen und Mutationen zu führen, die während des Testens abgerufen werden kann.
Als Facebook React der Welt vorstellte, war ihnen bereits klar, wie Requisiten zu einer großen Hürde werden können, wenn sie ein bestimmtes Maß an Komplexität erreichen. Um dieses Problem zu lösen, führten sie neben React ein Konzept namens Flux ein, das beschreibt, wie ein Store in Verbindung mit React funktionieren sollte. Redux basiert, wie wir heute wissen, lediglich auf einem Machbarkeitsnachweis, der von Dan Abramov gehackt wurde, während er an den Flux-Prinzipien für React Europe herumbastelte.
Redux wird in großen Anwendungen eingesetzt wo eine Interaktion mit einer Komponente Änderungen auf die gesamte Seite übertragen könnte. Um diese Art der Kommunikation zwischen den Komponenten zu erleichtern, können Sie einfach den Store aufrufen, anstatt Callbacks auf der obersten Ebene der Anwendung erstellen zu müssen. In meinem aktuellen Projekt macht Redux Sinn, weil die Anwendung so weit eskaliert war, dass Requisiten, die sich auf ihren Status bezogen, über mehrere Ebenen von Komponenten weitergegeben wurden, was wiederum das Lesen und Debuggen des Codes erschwerte.
Redux sah aus wie ein Geschenk des Himmels. als wir anfingen, alten Code auf diese neue Funktion zu migrieren. Es hat das gemacht Code sieht schicker aus, es war extrem intuitiv zu verstehen und Die Anzahl der Requisiten, die in der Anwendung herumschwirren, wurde drastisch reduziert. Aber es war nicht perfekt. Die Natur von Reducern stellt ein Problem dar, wenn man das Abrufen von Informationen in ihnen miteinbezieht, und das ist etwas, mit dem sich die Redux-Community schon sehr lange befasst.
Reduktoren sind laut Dokumentation theoretisch reine Funktionen selbst.
Bei gleichen Argumenten sollte es den nächsten Zustand berechnen und zurückgeben. Keine Überraschungen. Keine Nebenwirkungen. Keine API-Aufrufe. Keine Mutationen. Nur eine Berechnung.
Also, wo solltest du wenden Sie asynchrone Aufrufe in Redux an?
Die Aktionen sollten die unmittelbare Antwort sein, aber die grundlegende Implementierung von Aktionen ist nichts weiter als ein einfaches JavaScript-Objekt, das Sie verwenden, um Informationen an Ihren Shop weiterzuleiten. Aus diesem Grund hat sich die Community mehrere Middlewares ausgedacht, die stattdessen die gesamte Logik in Funktionen zusammenfassen, die das natürliche Verhalten des Shops nachahmen.
Wie bei allem in der Programmierung es gibt keine Einheitslösung. Sie sollten also auf jeden Fall recherchieren, welche Middleware am besten zu Ihrem Problem passt. Die erste in der Dokumentation vorgeschlagene Lösung lautet Redux Think. Mit dieser Middleware können Sie Aktionen als mehr als einfache Objekte erstellen. Diese neuen Aktionen können andere Aktionen, andere Thunks und auch asynchrone Operationen ausführen in ihnen. Aber in letzter Zeit haben andere Middleware begonnen, an Bedeutung zu gewinnen, wie Redux-Saga und Redux-Beobachtbar haben unterschiedliche Anwendungsfälle, aber eines haben sie alle gemeinsam, nämlich ein sehr aktives Repositorium und eine blühende Community, die dahinter steht.
Von allen gängigen Lösungen für dieses Problem Redux Think ist am leichtesten zu verstehen. Es ist auch in technischer Hinsicht ziemlich zugänglich und derzeit ist es gemäß der Redux-Dokumentation die empfohlene Methode, um mit dieser Situation umzugehen.
Wir fangen hier an:
Dadurch erhalten Sie eine neue App mit React mit allen Redux-Modulen, die wir für dieses kurze Tutorial benötigt haben. Wir werden auch mit dem arbeiten Woof Bot API-Dienst.
Als Erstes müssen Sie einen Dog Slice einrichten, in dem Sie alle Informationen zu Ihrer Hunde-API-Antwort aufbewahren.
Wir haben unsere Aktionen:
und Selektoren:
Wie würden Sie das normalerweise mit der API und dem Store hin und her implementieren? Ich würde das alles in eine einbauen useEffect-Haken, ähnlich wie dieser:
Was machen wir hier?
Alternativ erhalten wir möglicherweise eine Fehlermeldung von der API, die den Flow in Schritt 4 stoppt und den Ladestatus auf Fehler setzt.
Das funktioniert und das ist ok. Es hat aber auch mehrere Nachteile. Hauptsächlich bringt es zu viel Logik in die Komponente. Sie ist nicht wiederverwendbar, und wenn Sie woanders auf diese Informationen zugreifen möchten, müssen Sie immer sicherstellen, dass diese Komponente zuerst geladen wird.
Jetzt mit Thunks:
Die Komponentenlogik sieht so aus:
Wir müssen eine neue FetchBreeds-Aktion erstellen, die der Logik, die wir zuvor in der Komponente hatten, sehr ähnlich sieht:
Diese einfache Ortsänderung im Code behebt die meisten Probleme, die wir zuvor hatten. Wir haben den Code von der Komponente abstrahiert und diesen speziellen Teil der Logik in der gesamten Codebasis wiederverwendbar gemacht. Diese Informationen sind nicht mehr an das Mounten der Komponente gebunden, sodass Sie jetzt eine neue FetchBreeds-Aktion ausführen können und die Daten werden geladen.
Dies ermöglicht es uns auch, Thunks zu verketten, falls wir eine kompliziertere Logik in unseren Aktionen benötigen. Wir können auch direkt auf den Bundesstaat zugreifen, anstatt Selektoren zu benötigen. Sie sollten jedoch weiterhin Selektoren verwenden, um sicherzustellen, dass sich Änderungen an Redux nicht auf Ihre Thunks auswirken.
Hängt von der Situation ab. Genauso wie Sie nicht für alles einen Löffel verwenden können, muss die Lösung auf der Grundlage des Problems ausgewählt werden und nicht umgekehrt.
In den letzten Problemen, mit denen ich konfrontiert war, war Thunks mehr als genug, um alle meine Randfälle zu erfüllen. Aber vielleicht benötigen Sie in Ihrem Fall eine spezifischere Lösung.
Recherchieren Sie, halten Sie sich auf dem Laufenden und Sie haben immer das beste Tool an Ihrer Seite.
Fanden Sie diesen Artikel hilfreich? Diese könnten dir auch gefallen!
Your everyday web developer who likes to hide in the backend. Javascript and Ruby are my jam. I still fumble with Docker and my builds break quite often.
People who read this post, also found these interesting:
.webp)
.webp)
%20(2).webp)
