sagas reducer react que all javascript redux redux-thunk

javascript - reducer - redux-< sagas



¿Puedo enviar varias acciones sin el middleware de Redux Thunk? (3)

De hecho, mostrar y ocultar la notificación parece ser un buen caso de uso para Thunks.

La respuesta de David describe la forma "predeterminada" de hacer varias actualizaciones en respuesta a algo: manejarlo desde diferentes reductores. Más a menudo esto es lo que quieres hacer.

A veces (como con las notificaciones) puede ser un inconveniente. Describo cómo puede elegir entre enviar una o varias acciones en mi respuesta a esta pregunta .

En caso de que cuando decida enviar varias acciones, solo hágalo de forma secuencial desde sus componentes o use Redux Thunk. Tenga en cuenta que si Redux Thunk le parece misterioso, debe indeed antes de usarlo. Sólo proporciona beneficios en términos de organización de código; en realidad no es diferente a ejecutar dispatch() dos veces seguidas.

Dicho esto, con Redux Thunk el envío de varias acciones se ve así:

function increment() { return { type: ''INCREMENT'' } } function incrementTwice() { return dispatch => { dispatch(increment()) dispatch(increment()) } } store.dispatch(increment()) incrementTwice()(store.dispatch) // doesn’t require redux-thunk but looks ugly store.dispatch(incrementTwice()) // requires redux-thunk but looks nice

El uso de Redux Thunk no tendrá ningún problema de rendimiento. Es solo una buena forma de llamar a funciones a las que puede entregar su dispatch para que puedan hacerlo tantas veces como lo deseen.

Leí que Redux Thunk es la forma confiable de administrar acciones / solicitudes asíncronas. No hay mucho sobre el despacho de acciones por otras acciones.

¿Qué hay de despachar acciones sincrónicas? No estoy seguro de los problemas de rendimiento del enfoque de Thunk, pero ¿puedo simplemente enviar acciones dentro de otro creador de acción sin definir la función dentro?

Me parece que el uso de redux thunk es innecesario para esta necesidad.


Es un error pensar en acciones para indicar cambios como uno a uno. De hecho, son muchos a muchos. Recuerda que todas las acciones son llamadas sobre todos los reductores.

Por ejemplo, una sola acción puede desencadenar varios cambios de estado:

function firstReducer(state, action) { switch (action.type) { case ACTION_X: // handle action x } } function secondReducer(state, action) { switch (action.type) { case ACTION_X: // handle action x } } function thirdReducer(state, action) { switch (action.type) { case ACTION_X: // handle action x } }

A la inversa, el mismo cambio de estado puede resultar de dos acciones diferentes.

function firstReducer(state, action) { switch (action.type) { case ACTION_X: case ACTION_Y: // handle action x and y in the same manner } }

Puede parecer extraño manejar dos acciones de la misma manera, pero esto es solo en el contexto de un solo reductor. Otros reductores son libres de manejarlos de manera diferente.

function secondReducer(state, action) { switch (action.type) { case ACTION_X: // handle action x case ACTION_Y: // handle action y } } function thirdReducer(state, action) { switch (action.type) { case ACTION_X: // handle action x default: // ignore action y } }

Con esta relación de muchos a muchos, simplemente no es necesario tener una jerarquía de acciones. Si tiene creadores de acciones que activan varias acciones síncronas, su código se vuelve más complejo y más difícil de razonar.


Si this lo logra, entonces sí, usando:

store.dispatch(action1, action2)

Tal vez +1 en github?