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

Por lo que sé y corregirme si me equivoco, redux-thunk es un middleware que nos ayuda a distribuir funciones asíncronas y depurar valores en la acción misma, mientras que cuando usé redux-promise no podía crear funciones asíncronas sin implementar la mía propia mecanismo como Action lanza 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 sería suficiente apegarse a redux-thunk?

redux-thunk permite a los creadores de acciones 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 enviar acciones de forma asincrónica o condicional. redux-thunktambién le permite enviar varias veces dentro de un creador de acciones. Si elige uno, el otro o ambos, depende completamente de sus necesidades / estilo.

Es probable que desee / necesite ambos juntos en su aplicación. Comience con redux-promise para tareas asincrónicas 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 única promesa, entonces redux-promisemejorarás tu vida y simplificarás eso, rápido y fácil. (En pocas palabras, en lugar de tener que pensar en 'desenvolver' sus promesas cuando se resuelven, luego escribir / enviar los resultados, redux-promise (-middleware) se encarga de todas esas cosas aburridas por 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 separar reductores?
  • ¿O tiene que gestionar un preprocesamiento complejo y una lógica condicional antes de decidir cómo y dónde enviar los resultados?

En esos casos, el beneficio de redux-thunkes que le permite encapsular la complejidad dentro de su creador de acciones .

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

• el Thunk compondría las acciones originales y las enviaría
• redux-promiseluego se encargaría de desenvolver en el (los) reductor (es) las promesas individuales generadas por su Thunk, para evitar la repetición que eso implica. (En cambio, podrías hacer todo en Thunks, con promise.then(unwrapAndDispatchResult).catch(unwrapAndDispatchError)... pero ¿por qué lo harías?)

Otra forma sencilla 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 retorcida de creación de acciones, manteniéndola fuera de sus componentes y definitivamente fuera de los reductores.
• redux-promisees 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:

• Encuentro redux-promise-middlewareque es una implementación más completa y comprensible de la idea detrás del original redux-promise. Está en desarrollo activo y también se complementa muy bien con redux-promise-reducer.
• Hay middlewares similares adicionales disponibles para componer / secuenciar sus acciones complejas: uno muy popular es redux-saga, que es muy similar redux-thunk, pero se basa en la sintaxis de las funciones del generador. Nuevamente, 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 el texto estándar 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 enviar varias acciones, pero en realidad no es así, y puede simplificar las cosas simples. Ahí es donde solo desea que varios reductores reaccionen a su llamada asíncrona. Pero no hay ninguna razón por la que varios reductores no puedan monitorear un solo tipo de acción. Simplemente querrá asegurarse de que su equipo sepa que está utilizando esa convención, para que no asuman que solo un reductor (con un nombre relacionado) puede manejar una acción determinada.

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

ReduxPromise devuelve una promesa como carga útil cuando se envía 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 a dispatch.

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