Esta es el arreglo más acertada que encomtrarás compartir, sin embargo obsérvala pausadamente y analiza si es compatible a tu trabajo.
Solución:
Citando la entrada de preguntas frecuentes de Redux sobre “cómo dividir la lógica comercial entre creadores de acciones y reductores”:
No hay una respuesta única y clara sobre exactamente qué piezas de lógica deben ir en un reductor o en un creador de acciones.
Si pones toda la lógica en el creador de acciones, terminas con objetos de acción voluminosos que declaran las actualizaciones del estado. Los reductores se vuelven puros, tontos, agregan esto, eliminan eso, actualizan estas funciones. Serán fáciles de componer. Pero no gran parte de su lógica comercial estará allí. Si pones más lógica en el reductor, terminas con objetos de acción agradables y delgados, la mayor parte de tu lógica de datos en un solo lugar, pero tus reductores son más difíciles de componer ya que es posible que necesites información de otras ramas. Terminas con grandes reductores o reductores que toman argumentos adicionales de más arriba en el estado.
Es válido enviar una acción que los reductores ignoran, y también es válido inspeccionar el estado primero y decidir no enviar una acción. En última instancia, todo se reduce a lo que te hace sentir cómodo.
Aquí hay una respuesta obstinada que va en contra de las recomendaciones de redux.
TL;DR Ninguno
Respuesta más larga: en los llamados acción asíncrona invocado desde software intermedio. En la comunidad redux se le conoce como “thunk” o “saga”.
Primero, algunas definiciones:
- acción: un objeto simple
type: 'ACTION_TYPE', payload: data - creador de acción: una función que devuelve acción.
- acción asíncrona: una función que se llama desde software intermedio.
- creador de acciones asíncronas: una función que devuelve acción asíncrona
- software intermedio: una función que puede manejar todas las acciones, enviar otras acciones y tiene acceso al estado de la tienda.
Entonces, ¿desde dónde llamamos a la lógica de negocios?
Si miras detenidamente, notarás que no necesitamos acción asíncrona y creador de acciones asíncronas. Podemos tener un simple acción que se maneja directamente en el software intermedio.
En software intermedio podemos tener un dedicado manipulador para cada acción. Este manipulador se comporta como acción asíncrona pero no lo llamamos así. llamémoslo interactuador.
Así que una nueva definición:
interactuador: una abstracción de lo que es esencialmente acción asíncrona en redux, pero no específico de redux. Interactor obtiene datos, llama a la lógica empresarial y envía “acciones” de resultados.
middleware = (...) =>
// if(action.type == 'HIGH_LEVEL')
interactors[action.name]( dispatch, params: action.payload )
const interactors =
async highLevelAction( dispatch, params )
dispatch( loading: true );
const data = await api.getData(params.someId);
const processed = myPureLogic(data);
dispatch( loading: false, data: processed );
Cómo enviarlo:
dispatch( type: 'HIGH_LEVEL', name: 'highLevelAction', someId: 1 )
Como se mencionó, hay varias formas de realizar esta acción según su caso de uso. Lo que puedo hacer es enumerar lo que parece más apropiado al especular sobre su caso de uso.
1. Lógica dentro del Componente.
El estado que mantiene la condición se puede incorporar al componente asignando el estado a accesorios usando connect de reaccionar-redux
También importa la acción en este archivo de componente y asigna la acción a los accesorios también.
El siguiente ejemplo demuestra cómo trae el estado y la acción al archivo de componentes. Cómo lo usa depende de usted. Lo he puesto en un contexto simple. Así que puedes invocar myFunction() en el punto que desee realizar la lógica.
MiComponente.js
import React, Component from 'react'
import connect from 'react-redux'
import onCheckboxClick from 'path/to/action'
class MyComponent extends Component
myFunction()
const theConditiion, onCheckboxClick = this.props
if (theConditiion)
onCheckboxClick(itemId: 'someItemid')
render()
//...
const mapStateToProps = (state) => (
theCondition: state.wherever.the.data.lives.in.store
)
export default connect(
mapStateToProps,
onCheckboxClick
)(MyComponent)
Por lo tanto, puede eliminar las comprobaciones condicionales que tiene actualmente dentro de su función onCheckboxClick para el ejemplo anterior.
2. Poner la lógica dentro del middleware.
El siguiente ejemplo demuestra cómo puede enviar acciones, pero primero, ‘atrapar’ un tipo particular de acción, dado que una condición es truepuede hacer una llamada API y enviar más acciones, si falsesimplemente pase la acción al siguiente middleware.
miMiddleware.js
const onCheckboxClick = store => next => action => {
if (action.type == 'CHECKBOX_CLICK')
let theConditiion = store.getState().wherever.the.data.lives.in.store
if (theConditiion)
// 1. make the api call here, or,
// 2. dispatch an action specific to handling api calls.
// E.g. Create another middleware to catch action type `API_CALL`
// This middleware can then handle all api calls, and dispatch actions for api requests, responses and errors.
const newAction = ...action, type: 'API_CALL'
store.dispatch(newAction)
// When you use store.dispatch(), the action will be passed back to the top of the middleware chain.
return next(action) // this will pass the action to the next middleware in the chain.
export default onCheckboxClick
Esta es una descripción general amplia para ayudarlo a pensar qué funciona mejor. Tenga en cuenta que, a medida que se desarrolla su aplicación, notará dónde se puede convertir la lógica repetida en sus propias funciones.
Agradecemos que desees añadir valor a nuestra información dando tu veteranía en las reseñas.