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

Question

Pour autant que je sache et corrigez-moi si je me trompe, redux-thunk est un intergiciel qui nous aide à dispatcher des fonctions asynchrones et à déboguer les valeurs dans l'action elle-même, alors que lorsque j'ai utilisé redux-promesse Je n'ai pas pu créer de fonctions asynchrones sans mettre en œuvre mon propre mécanisme, car Action lève une exception en ne distribuant que des objets simples.

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

Answer 1

redux-thunk permet à vos créateurs d'actions de retourner une fonction :

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

redux-promise leur permet de renvoyer une promesse :

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

Ces deux bibliothèques sont utiles si vous avez besoin de répartir une action de manière asynchrone ou conditionnelle. redux-thunk vous permet également de procéder à plusieurs envois au sein d'un même créateur d'action. Le choix de l'un, de l'autre ou des deux dépend entièrement de vos besoins et de votre style.

Answer 2

Vous aurez probablement besoin des deux dans votre application. Commencez avec redux-promise pour les tâches asynchrones de routine produisant des promesses, puis ajoutez des Thunks (ou des Sagas, etc.) lorsque la complexité augmente. :

• Lorsque la vie est simple, et que vous ne faites que du travail asynchrone de base avec des créateurs qui renvoient une seule promesse, alors redux-promise améliorera votre vie et vous simplifiera la tâche, rapidement et facilement. (En bref, au lieu de devoir penser à "déballer" vos promesses lorsqu'elles sont résolues, puis à écrire/dispatcher les résultats, redux-promise(-middleware) s'occupe de toutes ces choses ennuyeuses pour vous).
• Mais, la vie devient plus complexe quand :
  • Peut-être que votre créateur d'action veut produire plusieurs promesses, que vous voulez distribuer comme des actions séparées à des réducteurs séparés ?
  • Ou bien, vous devez gérer un prétraitement complexe et une logique conditionnelle avant de décider comment et où envoyer les résultats ?

Dans ces cas-là, l'avantage de redux-thunk c'est qu'il vous permet d'encapsuler la complexité dans votre créateur d'actions. .

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

• le Thunk composerait la ou les actions originales et les distribuerait
• redux-promise s'occuperait alors de déballer au niveau du (des) réducteur(s) la (les) promesse(s) individuelle(s) générée(s) par votre Thunk, pour éviter le boilerplate que cela implique. (Vous pourrait au lieu de tout faire en Thunks, avec promise.then(unwrapAndDispatchResult).catch(unwrapAndDispatchError) ... mais pourquoi le feriez-vous ?)

---

Une autre façon simple de résumer la différence entre les cas d'utilisation : le début et la fin du cycle d'action de Redux :

• Les thunks sont pour les débutant de votre flux Redux : si vous avez besoin de créer une action complexe, ou d'encapsuler une logique de création d'action complexe, le fait de la garder en dehors de votre componateur peut vous aider. en la gardant hors de vos composants, et définitivement hors 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éballer et stocker leur valeur résolue/rejetée dans le store

NOTES/REFS :

• Je trouve redux-promise-middleware pour être une mise en œuvre plus complète et plus compréhensible de l'idée derrière l'original redux-promise . Il fait l'objet d'un développement actif et est également bien complété par redux-promise-reducer .
• il existe d'autres intergiciels similaires pour composer/séquencer vos actions complexes : l'un d'entre eux, très populaire, est le suivant redux-saga qui est très similaire à redux-thunk mais il est basé sur la syntaxe des fonctions de générateur. Encore une fois, vous l'utiliserez probablement en conjonction avec redux-promise .
• Voici un excellent article comparer directement les différentes options de composition asynchrone, y compris thunk et redux-promise-middleware. (TL;DR : "Redux Promise Middleware réduit le boilerplate de manière assez spectaculaire par rapport à certaines des autres options" ... "Je pense que je préfère Saga pour les 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 avez besoin de répartir plusieurs actions, mais ce n'est pas vraiment le cas, et vous pouvez garder les choses simples. C'est le cas lorsque 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 contrôler un seul type d'action. Vous devez simplement vous assurer que votre équipe sait que vous utilisez cette convention, afin qu'elle ne suppose pas qu'un seul réducteur (avec un nom apparenté) peut traiter une action donnée.

Answer 3

Divulgation complète : je suis relativement nouveau dans le développement de Redux et j'ai moi-même eu du mal à répondre à 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 distribuée, et ensuite le middleware ReduxPromise travaille pour résoudre cette promesse et passer le résultat au reducer.

ReduxThunk, d'un autre côté, force le créateur de l'action à retarder l'envoi de l'objet de l'action aux réducteurs jusqu'à ce que le dispatch soit appelé.

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