reactjs - react - redux thunk vs saga

¿Cuál es la diferencia entre redux-thunk y redux-promise?

Question

Hasta donde sé y corregirme si estoy equivocado, redux-thunk es un middleware que nos ayuda a despachar la función asincrónica y depurar valores en la acción misma, mientras que cuando utilicé redux-promise no pude crear funciones asincrónicas sin implementar la mía. Mecanismo como Acción arroja una excepción de despachar solo objetos simples.

¿Cuáles son las principales diferencias entre estos dos paquetes? ¿Hay algún beneficio de usar ambos paquetes en una aplicación de reacción de una sola página o apegarse a redux-thunk sería suficiente?

Answer 1

Probablemente querrá / necesitará ambos juntos en su aplicación. Comience con redux-promise para tareas asíncronas de producción de promesas de rutina y luego escale para agregar Thunks (o Sagas, etc.) a medida que aumenta la complejidad :

• Cuando la vida es simple, y solo estás haciendo un trabajo asincrónico básico con creadores que devuelven una sola promesa, entonces redux-promise mejorará tu vida y simplificará eso, de manera rápida y fácil. (En pocas palabras, en lugar de que necesite pensar en ''desenvolver'' sus promesas cuando se resuelvan, luego escribir / enviar los resultados, redux-promise (-middleware) se encarga de todas esas cosas aburridas para usted).
• Pero, la vida se vuelve más compleja cuando:
  • ¿Quizás su creador de acciones quiere producir varias promesas, que desea enviar como acciones separadas para reducir los reductores?
  • ¿O tiene que administrar un complejo procesamiento previo y una lógica condicional antes de decidir cómo y dónde enviar los resultados?

En esos casos, el beneficio de redux-thunk es que te permite encapsular la complejidad dentro de tu creador de acción .

Pero tenga en cuenta que si su Thunk produce y envía promesas, entonces querrá usar ambas bibliotecas juntas :

• Thunk compondría las acciones originales y las enviaría
• redux-promise se encargaría de desenvolver en el (los) reductor (es) la (s) promesa (s) individual (es) generada por su Thunk, para evitar la barrera que conlleva. (En su lugar, podría hacer todo en Thunks, con promise.then(unwrapAndDispatchResult).catch(unwrapAndDispatchError) ... pero ¿por qué lo haría?)

Otra forma simple de resumir la diferencia en los casos de uso: el comienzo frente al final del ciclo de acción de Redux :

• Los Thunks son para el comienzo de su flujo de Redux: si necesita crear una acción compleja, o encapsular alguna lógica de creación de acción retorcida, manteniéndola fuera de sus componentes y definitivamente fuera de los reductores.
• redux-promise es para el final de su flujo, una vez que todo se ha reducido a simples promesas, y solo desea desenvolverlas y almacenar su valor resuelto / rechazado en la tienda

NOTAS / REFS:

• Creo que redux-promise-middleware es una implementación más completa y comprensible de la idea detrás del redux-promise original. Está en desarrollo activo, y también se complementa muy bien con redux-promise-reducer .
• hay otros middlewares similares disponibles para componer / secuenciar sus acciones complejas: una muy popular es redux-saga , que es muy similar a redux-thunk , pero se basa en la sintaxis de las funciones del generador. De nuevo, es probable que lo use junto con redux-promise .
• Aquí hay un gran artículo que compara directamente varias opciones de composición asíncrona, incluidos thunk y redux-promise-middleware. (TL; DR: "Redux Promise Middleware reduce drásticamente las repeticiones frente a algunas de las otras opciones" ... "Creo que me gusta Saga para aplicaciones más complejas (léase:" usos ") y Redux Promise Middleware para todo lo demás". )
• Tenga en cuenta que hay un caso importante en el que puede pensar que necesita despachar múltiples acciones, pero realmente no lo hace, y puede mantener las cosas simples simples. Ahí es donde solo desea que múltiples reductores reaccionen a su llamada asíncrona. Pero no hay ninguna razón por la cual los reductores múltiples no puedan monitorear un solo tipo de acción. Simplemente querrás asegurarte de que tu equipo sepa que estás usando esa convención, para que no asuman que un solo reductor (con un nombre relacionado) puede manejar una acción determinada.

Answer 2

Revelación completa: soy relativamente nuevo en el desarrollo de Redux y tuve problemas con esta pregunta. Parafrasearé la respuesta más sucinta que encontré:

ReduxPromise devuelve una promesa como carga útil cuando se despacha una acción, y luego el middleware ReduxPromise trabaja para resolver esa promesa y pasar el resultado al reductor.

ReduxThunk, por otro lado, obliga al creador de la acción a retrasar el envío del objeto de acción a los reductores hasta que se llame el despacho.

Aquí hay un enlace al tutorial donde encontré esta información: https://blog.tighten.co/react-101-part-4-firebase .

Answer 3

redux-thunk permite a tus creadores de acción devolver una función:

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

redux-promise les permite devolver una promesa:

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

Ambas bibliotecas son útiles si necesita distribuir acciones de forma asincrónica o condicional. redux-thunk también te permite enviar varias veces dentro de un creador de acción. Ya sea que elija uno, el otro o ambos dependen completamente de sus necesidades / estilo.