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

Soweit ich weiß und mich korrigiere, wenn ich falsch liege , ist Redux-Thunk eine Middleware, die uns hilft, Async-Funktionen und Debug-Werte in der Aktion selbst zu versenden, während ich bei Verwendung von Redux-Versprechen keine Async-Funktionen erstellen konnte, ohne meine eigenen zu implementieren Mechanismus als Aktion löst eine Ausnahme aus, bei der nur einfache Objekte versendet werden.

Was sind die Hauptunterschiede zwischen diesen beiden Paketen? Gibt es irgendwelche Vorteile, wenn Sie beide Pakete in einer App für die Reaktion auf eine einzelne Seite verwenden oder wenn Sie sich an Redux-Thunk halten?

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 zurückzugeben:

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

Beide Bibliotheken sind nützlich, wenn Sie die Aktion asynchron oder bedingt auslösen müssen. redux-thunkAuß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 beide zusammen in Ihrer App wollen / brauchen. Beginnen Sie mit Redux-Versprechen für routinemäßige asynchrone Aufgaben, die Versprechen versprechen, und skalieren Sie dann, um Thunks (oder Sagas usw.) hinzuzufügen, wenn die Komplexität zunimmt :

• Wenn das Leben einfach ist und Sie nur grundlegende asynchrone Arbeit mit Entwicklern leisten, die ein einziges Versprechen zurückgeben, redux-promiseverbessern Sie Ihr Leben und vereinfachen dies schnell und einfach. (Kurz gesagt, anstatt dass Sie darüber nachdenken müssen, Ihre Versprechen auszupacken, wenn sie gelöst werden, und dann die Ergebnisse zu schreiben / zu versenden, kümmert sich redux-versprechen (-middleware) um all das langweilige Zeug für Sie.)
• Das Leben wird jedoch komplexer, wenn:
  • Vielleicht möchte Ihr Aktionsersteller mehrere Versprechen erstellen, die Sie als separate Aktionen an separate Reduzierer senden möchten?
  • Oder Sie müssen eine komplexe Vorverarbeitungs- und Bedingungslogik verwalten, bevor Sie entscheiden, wie und wo die Ergebnisse versendet werden sollen.

In diesen Fällen besteht der Vorteil redux-thunkdarin, dass Sie die Komplexität in Ihrem Aktionsersteller zusammenfassen können .

Beachten Sie jedoch, dass Sie beide Bibliotheken zusammen verwenden möchten , wenn Ihr Thunk Versprechen erstellt und versendet :

• Der Thunk würde die ursprüngliche (n) Aktion (en) zusammenstellen und sie versenden
• redux-promisewürde dann das Auspacken der von Ihrem Thunk generierten individuellen Versprechen an den Reduzierern handhaben, um die damit verbundene Kesselplatte zu vermeiden. (Sie könnten stattdessen alles in Thunks machen, mit promise.then(unwrapAndDispatchResult).catch(unwrapAndDispatchError)... aber warum sollten Sie?)

Eine weitere einfache Möglichkeit, den Unterschied in den Anwendungsfällen zusammenzufassen: Beginn und Ende des Redux-Aktionszyklus :

• Thunks sind für den Beginn Ihres Redux-Flusses gedacht : Wenn Sie eine komplexe Aktion erstellen oder eine knorrige Logik zur Erstellung von Aktionen kapseln müssen, halten Sie sie von Ihren Komponenten und definitiv von Reduzierern fern.
• redux-promiseist für das Ende Ihres Flusses, wenn alles auf einfache Versprechen reduziert wurde und Sie sie nur auspacken und ihren aufgelösten / abgelehnten Wert im Geschäft speichern möchten

  ---

ANMERKUNGEN / REFS:

• Ich finde redux-promise-middleware, dass die Idee hinter dem Original vollständiger und verständlicher umgesetzt wird redux-promise. Es befindet sich in der aktiven Entwicklung und wird auch gut ergänzt durch redux-promise-reducer.
• Es gibt zusätzliche ähnliche Middlewares zum Erstellen / Sequenzieren Ihrer komplexen Aktionen: Eine sehr beliebte ist redux-saga, die sehr ähnlich ist redux-thunk, aber auf der Syntax der Generatorfunktionen basiert. Auch hier würden Sie es wahrscheinlich in Verbindung mit verwenden redux-promise.
• Hier ist ein großartiger Artikel , in dem verschiedene asynchrone Kompositionsoptionen direkt verglichen werden, einschließlich Thunk- und Redux-Promise-Middleware. (TL; DR: "Redux Promise Middleware reduziert die Boilerplate im Vergleich zu einigen anderen Optionen ziemlich dramatisch" ... "Ich glaube, ich mag Saga für komplexere Anwendungen (lesen Sie:" verwendet ") und Redux Promise Middleware für alles andere." )
• Beachten Sie, dass es einen wichtigen Fall gibt, in dem Sie möglicherweise denken, dass Sie mehrere Aktionen auslösen müssen, dies jedoch nicht, und Sie können einfache Dinge einfach halten. Hier möchten Sie nur, dass mehrere Reduzierungen auf Ihren asynchronen Anruf reagieren. Es gibt jedoch überhaupt keinen Grund, warum mehrere Reduzierungen einen einzelnen Aktionstyp nicht überwachen können. Sie möchten einfach sicherstellen, dass Ihr Team weiß, dass Sie diese Konvention verwenden, damit nicht davon ausgegangen wird, dass nur ein einziger Reduzierer (mit einem verwandten Namen) eine bestimmte Aktion ausführen 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 umschreiben, die ich gefunden habe:

ReduxPromise gibt ein Versprechen als Nutzlast zurück, wenn eine Aktion ausgelöst wird. Anschließend löst die ReduxPromise-Middleware dieses Versprechen und leitet das Ergebnis an den Reduzierer weiter.

ReduxThunk hingegen zwingt den Aktionsersteller, das tatsächliche Versenden des Aktionsobjekts an die Reduzierer zu unterbrechen, bis der Versand aufgerufen wird.

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