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

Autant que je sache et corrige-moi si je me trompe, redux-thunk est un middleware qui nous aide à distribuer la fonction async et à déboguer les valeurs dans l'action elle-même, tandis que lorsque j'ai utilisé redux-promise, je ne pouvais pas créer de fonctions asynchrones sans implémenter les miennes mécanisme comme Action lève une exception de distribution uniquement 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 application de réaction sur une seule page ou à s'en tenir à redux-thunk serait suffisant?

redux-thunk permet à vos créateurs d'actions 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 répartir l'action de manière asynchrone ou conditionnelle. redux-thunkvous permet également d'envoyer plusieurs fois au sein d'un créateur d'action. Que vous choisissiez l'un, l'autre ou les deux dépend entièrement de vos besoins / style.

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

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

Dans ces cas, l'avantage de redux-thunkest 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 l'action ou les actions originales et les enverrait
• redux-promisese chargerait alors de déballer au (x) réducteur (s) la ou les promesses individuelles générées par votre Thunk, pour éviter le passe-partout que cela implique. (Vous pourriez à la place tout faire à Thunks, avec promise.then(unwrapAndDispatchResult).catch(unwrapAndDispatchError)... mais pourquoi le feriez-vous?)

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

• Thunks sont pour le début de votre flux Redux: si vous avez besoin de créer une action complexe, ou d'encapsuler une logique de création d'action épineuse, en la gardant hors de vos composants et définitivement hors des réducteurs.
• redux-promisec'est pour la fin de votre flux, une fois que tout a été réduit à de simples promesses, et que vous voulez simplement les déballer et stocker leur valeur résolue / rejetée dans le magasin

  ---

REMARQUES / RÉFÉRENCES:

• Je trouve redux-promise-middlewareêtre une mise en œuvre plus complète et compréhensible de l'idée derrière l'original redux-promise. Il est en cours de développement actif et est également bien complété parredux-promise-reducer .
• il existe des middlewares similaires supplémentaires disponibles pour composer / séquencer vos actions complexes: l'un est très populaire redux-saga, qui est très similaire à redux-thunk, mais est basé sur la syntaxe des fonctions génératrices. Encore une fois, vous l'utiliserez probablement en conjonction avec redux-promise.
• Voici un excellent article comparant directement diverses options de composition asynchrone, y compris thunk et redux-promise-middleware. (TL; DR: "Redux Promise Middleware réduit considérablement le passe-partout par rapport à certaines des autres options" ... "Je pense que j'aime Saga pour les applications plus complexes (lire:" utilise "), et Redux Promise Middleware pour tout le reste." )
• Notez qu'il existe un cas important dans lequel vous pensez peut-être devoir envoyer plusieurs actions, mais ce n'est vraiment pas le cas, et vous pouvez garder les choses simples 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 laquelle plusieurs réducteurs ne peuvent pas surveiller un seul type d'action. Vous voudrez simplement vous assurer que votre équipe sait que vous utilisez cette convention, afin de ne pas supposer qu'un seul réducteur (avec un nom associé) peut gérer une action donnée.

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

ReduxThunk, d'un autre côté, force le créateur d'action à ne pas envoyer réellement 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é ces informations: https://blog.tighten.co/react-101-part-4-firebase .