He estado siguiendo los consejos ampliamente dados de aprender el desarrollo de React mediante el primer componente de dominioprops, encapsulando el estado de la IU en el nivel de componentethis.state y pasarlo selectivamente a través del árbol de componentes. Ha sido una experiencia esclarecedora. He llegado a apreciar el poder del patrón de diseño de vista sin estado y siento que he podido lograr resultados sólidos y bien organizados utilizando estas técnicas.

Continuando, ahora estoy tratando de incorporar una administración estatal más sofisticada usandoredux. Pero a medida que avanzo por la complejidad e integroredux En mis aplicaciones, me encuentro confrontando las siguientes observaciones sobre cómo ha evolucionado mi código. Algunos de estos desarrollos parecen razonables, pero otros me hacen cuestionar si estoy haciendo las cosas "bien".

1) Action Creators como el nexo de los negocios y la lógica de la interfaz de usuario

Me parece que gran parte de la lógica que se implementó previamente en las funciones del ciclo de vida de ReactcomponentDidUpdate etc., y enonTouch/onPress manejadores, ahora se implementa encreadores de acción. Esto parece ser un desarrollo positivo, ya que mantiene "todo en el mismo lugar" y permite realizar pruebas unitarias.

Pregunta: ¿Es una buena práctica concentrar la lógica empresarial en una red de creadores de acción bastante intrincados?

2) Ahuecadoreducers

Como corolario al # 1 anterior, encuentro que mireducers y sus correspondientesaction Los objetos se han convertido en una lista de hecho de establecedores que hacen poco más que actualizar el almacén de estado con los valores transmitidos, de esta manera:

case types.SAVE_ORDER: 
  return Object.assign({}, state, {
    order: action.order,
  });

Una gran parte de la razón de esto es quereducers se supone que sonfunciones puras y, por lo tanto, estoy limitado en lo que puedo hacer con ellos (por ejemplo, sin procesamiento asíncrono). Además, los reductores solo pueden operar en sus respectivas subsecciones del estado de la tienda. Dado que gran parte de la complejidad de mi aplicación ya reside necesariamente en elcreadores de acción, Me resulta difícil justificar migrar arbitrariamente la complejidad areducers simplemente por el hecho de hacer que "se vean útiles".

Pregunta: ¿Es normal y una práctica aceptable tener repetitivo?reducers esa función simplemente como setters glorificados al estado de tienda redux?

3)redux-thunk en todos lados

He preguntado por separado en SO por quéredux-thunk incluso es necesario (en lugar de llamar a los creadores de acciones estándar dentro de las devoluciones de llamada / funciones de utilidad asíncronas). He sido señalado a estoresponder por Dan Abramov, que proporciona una explicación muy satisfactoria (escalabilidad visual, representación del lado del servidor y muchas otras razones).

Habiendo aceptado la necesidad deredux-thunk, Encuentro que la mayoría de miscreadores de acción necesita realizar acciones asincrónicas, necesita acceso agetStateodispatch Múltiples cambios en el estado. Como resultado he estado regresando 'thunks'ampliamente.

Pregunta: ¿Es normal que una aplicación redux dependa ampliamente dethunk'ed creadores de acción, y rara vez para disparar una acción de objeto estándar directamente?

4) Redux como globalthis.state

En el análisis final, parece que mi aplicaciónredux tienda ha evolucionado para parecerse efectivamente a un globalthis.state. Se podría pensar que mantiene todo el estado de la aplicación enthis.state en el componente de contenedor más externo, pero sin el inevitable desastre que viene al pasar dichostate abajo a través de capas anidadas deprops, y cualquier cambio hace una copia de seguridad del árbol de componentes a través de un nido de ratas demanipulador funciones

Pregunta: Esredux ¿La herramienta correcta para usar en una tienda de estado global? ¿Existen alternativas por ahí que se comporten más comoreaccionarincorporadothis.state, lo que permite que un estado de aplicación global se propague a través de componentes de reacción sin estado y se actualice desde toda la aplicación a través de una 'centralita' centralizada, sin la red aparentemente interminable de repeticiones, constantes yswitch declaraciones que vienen con la adopciónredux?

5) ¿Un solo tipo de acción? Esta pregunta de seguimiento está inspirada en uno de los comentarios publicados.

Pregunta: ¿Podría uno legítimamente (con toda seriedad, no solo demostrar un punto descaradamente) usar redux con precisamente un tipo de acción?

Ejemplo: creador de acciones:

export function someActionCreator(various_params){
  return (dispatch, getState => {
    // ... business logic here ....
    asyncIfThisIfThat().then(val => {
      dispatch({
        // type: 'UPDATE_STATE', // Don't even bother setting a type 
        order: val
      })
    })
  )
}

El único estuche reductor universal:

export default function app(state = initialState, action = {}) {
  return Object.assign({}, state, action)
  // Just unconditionally merge into state!
}

Me parece que esto proporcionaría un objeto de estado con alcance global que se asigna automáticamente aconnectcomponentes ed, y uno que se beneficia de todas las ventajas del estado inmutable e interoperable con Reactprops. En este esquema,dispatch efectivamente se convierte en un globalsetState.

Nota: Por favor, no tome esta pregunta mal, esto ciertamente no es una crítica deredux. Como estudiante, obviamente no estoy en posición de juzgar una tecnología respaldada por la experiencia de miles y el apoyo de millones. No tengo dudas de su valor en el contexto correcto.

Solo estoy sintiendo el olor de un patrón cuestionable en mi propio código y me pregunto qué, si algo estoy haciendo mal, o si estoy usando la herramienta adecuada para la tarea.