react example español reactjs redux redux-form

reactjs - example - react-redux



Estoy usando Redux. ¿Debo administrar el estado de entrada controlado en la tienda de Redux o usar setState en el nivel de componente? (4)

He estado tratando de descubrir la mejor forma de administrar mis formularios de reacción. Intenté utilizar el cambio en para iniciar una acción y actualizar mi tienda de reducción con mis datos de formulario. También he intentado crear un estado local y cuando se envía mi formulario, activé, activé y actualicé el almacén redux.

¿Cómo debo administrar mi estado de entrada controlada?


  1. Puede usar el estado propio del componente. Y luego tomar ese estado y darle como argumento a la acción. Esa es más o menos la "forma de reacción" tal como se describe en React Docs .

  2. También puedes ver Redux Form . Hace básicamente lo que describió y vincula las entradas de formulario con el estado de Redux.

La primera forma básicamente implica que estás haciendo todo manualmente: máximo control y máxima repetición. La segunda forma significa que está permitiendo que el componente de orden superior haga todo el trabajo por usted. Y luego está todo en el medio. Hay varios paquetes que he visto que simplifican un aspecto específico de la administración de formularios:

  1. Formularios de reacción : proporciona un conjunto de componentes auxiliares para simplificar el procesamiento y la validación de formularios.

  2. Reaccionar esquema JSON : permite construir un formulario HTML a partir de un esquema JSON.

  3. Formsy React - Como dice la descripción: "Esta extensión para React JS pretende ser ese" punto ideal "entre la flexibilidad y la reutilización".

Actualización: parece que hoy Redux Form está siendo reemplazado por:

  1. Reaccionar formulario final

Y un contendiente más importante en el espacio que vale la pena mirar es:

  1. Formik

Me gusta esta respuesta de uno de los coautores de Redux: https://github.com/reactjs/redux/issues/1287

Usa React para el estado efímero que no importa a la aplicación globalmente y no muta de formas complejas. Por ejemplo, alternar en algún elemento de UI, un estado de entrada de formulario. Use Redux para el estado que importa globalmente o está mutado de maneras complejas. Por ejemplo, usuarios almacenados en caché o un borrador posterior.

Algunas veces querrá pasar del estado Redux al estado React (cuando almacenar algo en Redux se torna incómodo) o al revés (cuando más componentes necesitan tener acceso a algún estado que solía ser local).

La regla de oro es: hacer lo que sea menos incómodo.

Es decir, si está seguro de que su forma no afectará el estado global o necesita mantenerse después de que su componente esté desmontado, entonces mantenga el estado de reacción.


Personalmente, recomiendo mantener todo en el estado de Redux y alejarse del estado de componentes locales. Esto es esencialmente porque si comienzas a mirar a ui como una función del estado, puedes hacer pruebas completas sin navegador y puedes aprovechar para mantener una referencia del historial de estado completo (como en, qué contenían sus entradas, qué diálogos estaban abiertos, etc. , cuando se produjo un error, no el estado en el que se encontraba desde el principio de los tiempos, para el usuario con fines de depuración. Tweet relacionado del reino de clojure

editado para agregar: aquí es donde nosotros y nuestra compañía hermana nos estamos moviendo en términos de nuestras aplicaciones de producción y cómo manejamos redux / state / ui


TL; DR

Está bien usar lo que le parezca más adecuado para su aplicación (Fuente: documentos de Redux )

Algunas reglas comunes para determinar qué tipo de datos se deben poner en Redux:

  • ¿Cuidan otras partes de la aplicación estos datos?
  • ¿Necesita poder crear más datos derivados basados ​​en estos datos originales?
  • ¿Se están usando los mismos datos para controlar múltiples componentes?
  • ¿Hay algún valor para usted en poder restaurar este estado a un punto dado en el tiempo (es decir, la depuración del viaje en el tiempo)?
  • ¿Desea almacenar en caché los datos (es decir, usar lo que está en estado si ya está allí en lugar de volver a solicitarlo)?

Estas preguntas pueden ayudarlo a identificar fácilmente el enfoque que sería mejor para su aplicación. Aquí están mis puntos de vista y enfoques que uso en mis aplicaciones (para formularios):

Estado local

  • Útil cuando mi formulario no tiene relación con otros componentes de la IU. Simplemente capture los datos de input (s) input (s) y los envía. Utilizo esto la mayor parte del tiempo para formas simples.
  • No veo mucho caso de uso en el viaje en el tiempo al depurar el flujo de entrada de mi formulario (a menos que algún otro componente de UI dependa de esto).

Estado de Redux

  • Útil cuando el formulario tiene que actualizar algún otro componente de UI en mi aplicación (al igual que el enlace bidireccional ).
  • Utilizo esto cuando mi (s) input (s) de formulario hace que otros componentes se render dependiendo de lo que el usuario ingresa.