Was ist der Unterschied zwischen Redux-Thunk und Redux-Promise?

Soweit ich weiß und korrigiere mich, wenn ich falsch liege, redux-thunk ist eine Middleware, die uns dabei hilft, asynchrone Funktionen und Debug-Werte in der Aktion selbst zu verteilen, während ich sie verwendet habe Redux-Versprechen Ich konnte keine asynchronen Funktionen erstellen, ohne meinen eigenen Mechanismus zu implementieren, da Action eine Ausnahme auslöst und nur einfache Objekte versendet.

Was sind die Hauptunterschiede zwischen diesen beiden Paketen? Gibt es Vorteile bei der Verwendung beider Pakete in einer einzelnen Seitenreaktions-App oder würde es ausreichen, bei Redux-Thunk zu bleiben?

redux-thunk Ermöglicht Ihren Aktionserstellern, eine Funktion zurückzugeben:

function myAction(payload){
    return function(dispatch){
        // use dispatch as you please
    }
}

redux-promise ermöglicht es ihnen, ein Versprechen zu erwidern:

function myAction(payload){
    return new Promise(function(resolve, reject){
        resolve(someData); // redux-promise will dispatch someData
    });
}

Beide Bibliotheken sind nützlich, wenn Sie Aktionen asynchron oder bedingt auslösen müssen. redux-thunk Außerdem können Sie innerhalb eines Aktionserstellers mehrmals versenden. Ob Sie sich für das eine, das andere oder beide entscheiden, hängt ganz von Ihren Bedürfnissen/Ihrem Stil ab.

Sie werden wahrscheinlich beides zusammen in Ihrer App wollen/brauchen. Beginnen Sie mit Redux-Promise für routinemäßige, Versprechen erzeugende asynchrone Aufgaben und skalieren Sie dann, um mit zunehmender Komplexität Thunks (oder Sagas usw.) hinzuzufügen:

• Wenn das Leben einfach ist und Sie nur einfache asynchrone Arbeit mit Entwicklern leisten, die ein einziges Versprechen einhalten, dann redux-promise wird Ihr Leben verbessern und vereinfachen, schnell und einfach. (Kurz gesagt: Redux-promise(-middleware) erledigt all diese langweiligen Dinge für Sie, anstatt darüber nachzudenken, wie Sie Ihre Versprechen auspacken, wenn sie aufgelöst werden, und dann die Ergebnisse zu schreiben/zu versenden.)
• Aber das Leben wird komplexer, wenn:
• Vielleicht möchte Ihr Aktionsersteller mehrere Versprechen erstellen, die Sie als separate Aktionen an separate Reduzierer senden möchten?
• Oder müssen Sie eine komplexe Vorverarbeitung und bedingte Logik verwalten, bevor Sie entscheiden, wie und wohin die Ergebnisse gesendet werden sollen?

In diesen Fällen der Vorteil von redux-thunk ist, dass es Ihnen ermöglicht, Komplexität in Ihrem Aktionsersteller zu kapseln.

Aber beachten Sie das Wenn Ihr Thunk Versprechen produziert und versendet, sollten Sie beide Bibliotheken zusammen verwenden:

• Der Thunk würde die ursprüngliche(n) Aktion(en) verfassen und sie versenden
• redux-promise würde sich dann um das Auspacken der einzelnen Versprechen, die von Ihrem Thunk generiert wurden, bei den Reduzierern kümmern, um den damit verbundenen Boilerplate zu vermeiden. (Du könnte Machen Sie stattdessen alles in Thunks mit promise.then(unwrapAndDispatchResult).catch(unwrapAndDispatchError)… aber warum solltest du?)

Eine weitere einfache Möglichkeit, den Unterschied in den Anwendungsfällen zusammenzufassen: der Anfang vs. das Ende des Redux-Aktionszyklus:

• Thunks sind für die Anfang Ihres Redux-Flows: Wenn Sie eine komplexe Aktion erstellen oder eine knifflige Aktionserstellungslogik kapseln müssen, halten Sie diese aus Ihren Komponenten und auf jeden Fall aus Reduzierern heraus.
• redux-promise ist für die Ende Ihres Ablaufs, sobald alles auf einfache Versprechen reduziert wurde und Sie sie nur noch auspacken und ihren gelösten/abgelehnten Wert im Speicher speichern möchten

HINWEISE/REFS:

• ich finde redux-promise-middleware um eine vollständigere und verständlichere Umsetzung der Idee hinter dem Original zu sein redux-promise. Es befindet sich in der aktiven Entwicklung und wird auch gut ergänzt durch redux-promise-reducer.
• Für die Erstellung/Sequenzierung Ihrer komplexen Aktionen stehen weitere ähnliche Middlewares zur Verfügung: Eine sehr beliebte ist redux-sagawas sehr ähnlich ist redux-thunk, basiert aber auf der Syntax von Generatorfunktionen. Auch hier würden Sie es wahrscheinlich in Verbindung mit verwenden redux-promiseweil Sagen Versprechungen hervorbringen, die Sie nicht auspacken und manuell mit Unmengen von Boilerplate verarbeiten müssen …
• Hier ist ein großartiger Artikel Direkter Vergleich verschiedener asynchroner Kompositionsoptionen, einschließlich Thunk und Redux-Promise-Middleware. (TL;DR: „Redux Promise Middleware reduziert den Boilerplate im Vergleich zu einigen anderen Optionen erheblich.“ … „Ich glaube, dass mir Saga für komplexere Anwendungen gefällt (sprich: „verwendet“), und Redux Promise Middleware für alles andere.“)
• Beachten Sie, dass es einen wichtigen Fall gibt, in dem Sie vielleicht denken, dass Sie mehrere Aktionen auslösen müssen, dies aber wirklich nicht tun, und Sie können einfache Dinge einfach halten. In diesem Fall möchten Sie lediglich, dass mehrere Reduzierer auf einen einzelnen asynchronen Aufruf reagieren, und neigen dazu, mehrere Aktionen an diese mehreren Reduzierer zu senden. Aber, Es gibt überhaupt keinen Grund, warum mehrere Reduzierer nicht einen einzelnen Aktionstyp überwachen können. Sie möchten lediglich sicherstellen, dass Ihr Team weiß, dass Sie diese Konvention verwenden, damit es nicht davon ausgeht, dass nur ein einzelner Reduzierer (mit einem zugehörigen Namen) eine bestimmte Aktion verarbeiten kann.

Vollständige Offenlegung: Ich bin relativ neu in der Redux-Entwicklung und habe selbst mit dieser Frage zu kämpfen. Ich werde die prägnanteste Antwort, die ich gefunden habe, umschreiben:

ReduxPromise gibt ein Versprechen als Nutzlast zurück, wenn eine Aktion ausgelöst wird, und dann arbeitet die ReduxPromise-Middleware daran, dieses Versprechen aufzulösen und das Ergebnis an den Reduzierer zu übergeben.

ReduxThunk hingegen zwingt den Aktionsersteller, mit der tatsächlichen Weiterleitung des Aktionsobjekts an die Reduzierer zu warten, bis der Versand aufgerufen wird.

Hier ist ein Link zum Tutorial, in dem ich diese Informationen gefunden habe: https://blog.tighten.co/react-101-part-4-firebase.