Você provavelmente vai querer / precisar dos dois juntos em seu aplicativo. Comece com redux-promessa para tarefas assíncronas de produção de promessa de rotina e, em seguida, amplie para adicionar Thunks (ou Sagas, etc.) conforme a complexidade aumenta :
- Quando a vida é simples, e você está apenas fazendo um trabalho assíncrono básico com criadores que retornam uma única promessa, então
redux-promise
irá melhorar sua vida e simplificar isso, rápido e fácil. (Resumindo, em vez de você precisar pensar em 'desembrulhar' suas promessas quando elas forem resolvidas, em seguida, escrever / despachar os resultados, redux-promessa (-middleware) cuida de todas essas coisas chatas para você.)
- Mas, a vida fica mais complexa quando:
- Talvez o seu criador de ação queira produzir várias promessas, que você deseja despachar como ações separadas para redutores separados.
- Ou você tem algum pré-processamento complexo e lógica condicional para gerenciar, antes de decidir como e para onde enviar os resultados?
Nesses casos, o benefício de redux-thunk
é permitir que você encapsule a complexidade dentro de seu criador de ação .
Mas observe que se o Thunk produz e despacha promessas, você vai querer usar as duas bibliotecas juntas :
- o Thunk iria compor a (s) ação (ões) original (is) e despachá-las
redux-promise
trataria então de desembrulhar no (s) redutor (es) as promessas individuais geradas por seu Thunk, para evitar o clichê que isso implica. (Você poderia fazer tudo no Thunks, com promise.then(unwrapAndDispatchResult).catch(unwrapAndDispatchError)
... mas por que faria?)
Outra maneira simples de resumir a diferença nos casos de uso: o início vs. o fim do ciclo de ação Redux :
- Thunks são para o início de seu fluxo Redux: se você precisa criar uma ação complexa, ou encapsular alguma lógica de criação de ação complicada, mantendo-a fora de seus componentes e definitivamente fora de redutores.
redux-promise
é para o fim do seu fluxo, uma vez que tudo foi reduzido a promessas simples, e você só quer desembrulhá-las e armazenar seu valor resolvido / rejeitado na loja
NOTAS / REFS:
- Acho
redux-promise-middleware
que é uma implementação mais completa e compreensível da ideia por trás do original redux-promise
. Está em desenvolvimento ativo e também é complementado por redux-promise-reducer
.
- existem middlewares semelhantes adicionais disponíveis para compor / sequenciar suas ações complexas: um muito popular é
redux-saga
, que é muito semelhante redux-thunk
, mas é baseado na sintaxe de funções geradoras. Novamente, você provavelmente o usaria em conjunto com redux-promise
.
- Aqui está um ótimo artigo comparando diretamente várias opções de composição assíncrona, incluindo thunk e redux-promessa-middleware. (TL; DR: "Redux Promise Middleware reduz bastante o boilerplate em comparação com algumas das outras opções" ... "Acho que gosto do Saga para aplicativos mais complexos (leia:" usa ") e Redux Promise Middleware para todo o resto." )
- Observe que há um caso importante em que você pode pensar que precisa despachar várias ações, mas realmente não precisa, e pode manter as coisas simples simples. É aí que você deseja que vários redutores reajam à sua chamada assíncrona. Porém, não há razão para que vários redutores não possam monitorar um único tipo de ação. Você simplesmente quer ter certeza de que sua equipe sabe que você está usando essa convenção, para que eles não presumam que apenas um único redutor (com um nome relacionado) pode lidar com uma determinada ação.