Ich versuche, mehrere Aktionen auf folgende Weise zu verketten:
A. Benutzerdaten in die Datenbank hochladen
B. Verwenden Sie gepostete Daten, um Elasticsearch nach Ergebnissen abzufragen
(Ich mache A und B parallel)
B1. Mit den Ergebnissen aus ES fragen Sie die ursprüngliche Datenbank nach Ergebnissen aus zwei Tabellen ab B2. Navigieren Sie zur neuen Seite und aktualisieren Sie die Benutzeroberfläche
Ich verwende gerade Thunks, um über meinen Code nachzudenken, aber ich fand auch, dass dieses asynchrone Muster extrem ausführlich ist:
%Vor%dies zusammen mit "requestRecipes" und "receiveRecipes", wie andere Action-Ersteller, scheint ziemlich viel zu sein, nur um einen asynchronen Aufruf zu machen. (eine Anfrage-, eine Empfangs- und eine Abruffunktion)
Zusammenfassung: Wenn Sie 2-3 asynchrone Aktionen verketten, deren Ausgänge voneinander abhängen (ich muss promistifizieren, wenn möglich), gibt es dann ein effizienteres Mittel, ohne 3 Funktionen für jeden Async-Aufruf zu schreiben?
Ich denke, es musste einen Weg geben. Ich bin Musterabgleich aus den Redux-Dokumenten und wurde bald sehr überwältigt von den Funktionen, die ich erstellt habe
vielen Dank für die Rückmeldung!
Sie können redux-saga anstelle von redux-thunk verwenden, um dies einfacher zu erreichen. redux-saga lässt Sie Ihre Arbeit mit Generatoren beschreiben und ist einfacher zu verstehen.
Der erste Schritt besteht darin, zu beschreiben, wie Sie Ihre Daten an redux übergeben, ohne sich um Dienste oder asynchrone Dinge zu sorgen.
Aktionen
%Vor%Reduzierer
%Vor%Services
Wir brauchen auch die Rezept-API. Wenn Sie redux-saga verwenden, besteht die einfachste Möglichkeit, einen Service zu deklarieren, darin, eine (reine) Funktion zu erstellen, die die Anfrage als Argument liest und ein Promise zurückgibt.
Jetzt müssen wir Aktionen und Dienste verbinden. Hier kommt redux-saga ins Spiel.
Und das ist es! Immer wenn eine Komponente eine Aktion RECIPES.REQUEST sendet, wird die Saga verbunden und der asynchrone Workflow wird verarbeitet.
Was ist toll mit redux-saga ist, dass Sie einfach asynchrone Effekte verketten und Aktionen während des Workflows versenden können.
Basierend auf Ihrer Beschreibung liegt die einzige Zeit, zu der Sie Ihre Benutzeroberfläche tatsächlich aktualisieren, am Ende all dieser asynchronen Vorgänge (B1).
Wenn Sie die Ergebnisse der vorhergehenden Async-Aufrufe nicht verwenden, um den Anwendungsstatus zu ändern / Ihre Benutzeroberfläche zu aktualisieren, was bringt diese feinkörnige Aktion?
Natürlich gibt es Dinge wie "loading / request started" und "finally loading / request stopped", aber es scheint mir, dass Sie in Ihrem Fall nur die verketteten Async-Aufrufe außerhalb von redux (in irgendeiner Art) ausführen können API-Ebene) und verwenden nur eine Aktion. Diese Aktion löst eine "REQUEST_STARTED" aus, ruft dann die API-Schicht auf, die die DB-Aufrufe und ElasticSearch-Anforderung usw. ausführt, und sendet dann entweder "REQUEST_SUCCESS" oder "REQUEST_FAILURE" basierend auf dem Ergebnis der Zusage, die geben wird Sie die Daten, die Sie benötigen, um Ihre Benutzeroberfläche zu aktualisieren.
Auf diese Weise betrifft der Zustand in redux nur EINEN Nebeneffekt, anstatt die Implementierungsdetails Ihrer angeketteten Aufrufe. Außerdem wird Ihre Aktion viel einfacher, da sie nur die Ergebnisse eines Async-Aufrufs behandelt.
Tags und Links reactjs redux redux-thunk