web-dev-qa-db-fra.com

Quelle est la différence entre redux-thunk et redux-promise?

Autant que je sache et me corrige si je me trompe, redux-thunk est un middleware qui nous aide à répartir les valeurs asynchrones et les valeurs de débogage dans l'action elle-même lorsque je l'utilisais promesse redux Je ne pouvais pas créer de fonctions asynchrones sans implémenter mon propre mécanisme car Action levait une exception consistant à ne distribuer que des objets simples.

Quelles sont les principales différences entre ces deux packages? Y a-t-il des avantages à utiliser les deux packages dans une seule page? Réagir à l'application ou s'en tenir à redux-thunk serait suffisant?

reactjsreduxredux-thunkredux-promise
81
rash.tay

redux-thunk permet aux créateurs d’action de renvoyer une fonction:

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

redux-promise leur permet de retourner une promesse:

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

Les deux bibliothèques sont utiles si vous devez envoyer une action de manière asynchrone ou conditionnelle. redux-thunk vous permet également d’envoyer plusieurs fois au sein d’un même créateur d’action. Que vous choisissiez l’un, l’autre ou les deux dépend entièrement de vos besoins/de votre style.

104
VonD

Vous voudrez probablement/aurez besoin des deux ensemble dans votre application. Commencez par redux-promise pour les tâches asynchrones de routine générant des promesses, puis redimensionnez-vous pour ajouter des thunks (ou des sagas, etc.) à mesure que la complexité augmente :

  • Lorsque la vie est simple et que vous effectuez un travail asynchrone de base avec des créateurs qui ne renvoient qu'une seule promesse, alors redux-promise Améliorera votre vie et la simplifiera rapidement et facilement. (En un mot, au lieu que vous ayez besoin de penser à "défaire" vos promesses quand elles se résolvent, puis à écrire/distribuer les résultats, redux-promise (-middleware) s'occupe de tout ce qui est ennuyeux pour vous.)
  • Mais la vie devient plus complexe quand:
    • Peut-être que votre créateur d’action souhaite faire plusieurs promesses que vous souhaitez envoyer en tant qu’actions distinctes pour séparer les réducteurs?
    • Ou encore, vous avez une logique conditionnelle et de prétraitement complexe à gérer avant de décider comment et où distribuer les résultats?

Dans ces cas, l'avantage de redux-thunk Est qu'il vous permet d'encapsuler la complexité à l'intérieur de votre créateur d'action .

Mais notez que si votre Thunk produit et envoie des promesses, vous voudrez utiliser les deux bibliothèques ensemble:

  • le Thunk composerait la ou les actions originales et les enverrait
  • redux-promise Se chargerait alors de déballer chez le (s) réducteur (s) la ou les promesse (s) individuelle (s) générée (s) par votre Thunk, afin d’éviter toute confusion. (Vous pouvez faites plutôt tout en thunks, avec promise.then(unwrapAndDispatchResult).catch(unwrapAndDispatchError)... mais pourquoi le feriez-vous?)

Un autre moyen simple de résumer la différence entre les cas d'utilisation: le début par rapport à la fin du cycle d'action Redux :

  • Les thunks sont pour le commencement de votre flux Redux: si vous devez créer une action complexe ou encapsuler une logique de création d'action épouvantable, en la gardant hors de vos composants, et certainement pas dans des réducteurs.
  • redux-promise Est pour le fin de votre flux, une fois que tout a été ramené à de simples promesses, et que vous voulez juste les décompresser et stocker leur valeur résolue/rejetée dans le magasin.

NOTES/REFS:

  • Je trouve que redux-promise-middleware Est une implémentation plus complète et compréhensible de l'idée qui sous-tend l'original redux-promise. Il est en développement actif et est également bien complété par redux-promise-reducer.
  • il existe d'autres middlewares similaires disponibles pour la composition/le séquençage de vos actions complexes: l'un des plus populaires est redux-saga, qui est très similaire à redux-thunk, mais qui repose sur la syntaxe des fonctions du générateur. Encore une fois, vous l'utiliserez probablement avec redux-promise.
  • Voici un excellent article comparant directement diverses options de composition asynchrone, y compris thunk et middleware redux-promise. (TL; DR: "Redux Promise Middleware réduit considérablement le contraste entre les options" ... "Je pense que j'aime Saga pour des applications plus complexes = (lire: "utilise"), et Redux Promise Middleware pour tout le reste. ")
  • Notez qu'il existe un cas important où vous pouvez penser que vous devez envoyer plusieurs actions, mais ce n'est pas le cas et vous pouvez garder des choses simples. C'est là que vous voulez simplement que plusieurs réducteurs réagissent à votre appel asynchrone. Mais, il n'y a aucune raison pour que plusieurs réducteurs ne puissent pas surveiller un seul type d'action. Vous voulez simplement vous assurer que votre équipe sait que vous utilisez cette convention, afin qu'ils ne Ne supposez pas qu’un seul réducteur (avec un nom associé) peut gérer une action donnée.
73
XML

Divulgation complète: Je suis relativement nouveau dans le développement de Redux et je me suis débattu avec cette question. Je vais paraphraser la réponse la plus succincte que j'ai trouvée:

ReduxPromise renvoie une promesse en tant que charge utile lorsqu'une action est envoyée, puis le middleware ReduxPromise fonctionne pour résoudre cette promesse et transmettre le résultat au réducteur.

De son côté, ReduxThunk oblige le créateur d’action à retarder la distribution de l’objet action aux réducteurs jusqu’à ce que la répartition soit appelée.

Voici un lien vers le tutoriel où j'ai trouvé cette information: https://blog.tighten.co/react-101-part-4-firebase .

21
lgants