javascript - example - mapstatetoprops ejemplo

React-Redux: ¿Deben mantenerse todos los estados componentes en la Tienda Redux

Question

Digamos que tengo una palanca simple:

Cuando hago clic en el botón, el componente Color cambia entre rojo y azul

Podría lograr este resultado haciendo algo como esto.

index.js

Button: onClick={()=>{dispatch(changeColor())}}
Color: this.props.color ? blue : red

container.js

connect(mapStateToProps)(indexPage)

action_creator.js

function changeColor(){
 return {type: ''CHANGE_COLOR''}
}

reducer.js

switch(){
case ''CHANGE_COLOR'':
return {color: true}

pero este es un montón de código para escribir para algo que podría haber logrado en 5 segundos con jQuery, algunas clases y algunos css ...

Entonces, supongo que lo que realmente pregunto es, ¿qué estoy haciendo mal aquí?

Answer 1

Con el fin de resaltar el excelente enlace provisto por @ AR7, y porque ese enlace retrocedió un tiempo:

Use Reaccionar para un estado efímero que no es importante para la aplicación a nivel mundial y que no muta de manera compleja. Por ejemplo, una alternancia en algún elemento de la IU, un estado de entrada de formulario. Use Redux para un estado que importa globalmente o que está mutado de formas complejas. Por ejemplo, usuarios en caché o un borrador posterior.

A veces, querrá pasar del estado Redux al estado Reaccionar (cuando almacenar algo en Redux se vuelve 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.

Dan Abramov: https://github.com/reactjs/redux/issues/1287#issuecomment-175351978

Answer 2

Redux está destinado principalmente al "estado de la aplicación". Es decir, cualquier cosa relacionada con la lógica de su aplicación. La vista construida encima es un reflejo de ese estado, pero no tiene que usar exclusivamente ese contenedor de estado para todo lo que hace.

Simplemente haga estas preguntas: ¿Es este estado importante para el resto de la aplicación? ¿Se comportarán otras partes de la aplicación de manera diferente en función de ese estado? En muchos casos menores, ese no será el caso. Elija un menú desplegable: el hecho de que esté abierto o cerrado probablemente no tendrá un efecto en otras partes de la aplicación. Por lo tanto, conectarlo a su tienda probablemente sea excesivo. Ciertamente es una opción válida, pero realmente no le brinda ningún beneficio. Es mejor usar this.state y llamarlo un día.

En su ejemplo particular, ¿se alterna el color de ese botón para hacer alguna diferencia en otras partes de la aplicación? Si se trata de una especie de activación / desactivación global para una parte importante de su aplicación, definitivamente pertenece a la tienda. Pero si solo está cambiando el color de un botón cuando hace clic en el botón, puede dejar el estado del color definido localmente. La acción de hacer clic en el botón puede tener otros efectos que requieren un despacho de acción, pero eso es independiente de la simple pregunta de qué color debería ser.

En general, trate de mantener el estado de su aplicación lo más pequeño posible. No tienes que meter todo allí. Hazlo cuando sea necesario o tiene mucho sentido mantener algo allí. O si te hace la vida más fácil cuando usas Dev Tools. Pero no sobrecargues demasiado su importancia.

Answer 3

Sí, vale la pena esforzarse por almacenar todos los estados de los componentes en Redux . Si lo hace, se beneficiará de muchas características de Redux, como la depuración de viajes en el tiempo y los informes de errores reproducibles. Si no lo hace, esas características podrían ser completamente inutilizables .

Cada vez que no almacene un cambio de estado del componente en Redux, ese cambio se pierde por completo de la pila de cambios de Redux y la interfaz de usuario de su aplicación no estará sincronizada con la tienda. Si esto no es importante para usted, pregúntese por qué usar Redux. ¡Su aplicación será menos compleja sin ella!

Por razones de rendimiento, es posible que desee recurrir a this.setState() para cualquier cosa que despache muchas acciones repetidamente. Por ejemplo: almacenar el estado de un campo de entrada en Redux cada vez que el usuario escribe una clave puede dar como resultado un bajo rendimiento. Puede resolver esto tratándolo como una transacción: una vez que la acción del usuario está "confirmada", guarde el estado final en Redux.

Su publicación original menciona que la forma de Redux es "un montón de código para escribir". Sí, pero puede usar abstracciones para patrones comunes como el estado del componente local.

Answer 4

Preguntas frecuentes de Redux: Estado organizador
Esta parte del documento oficial de Redux respondió bien a su pregunta.

Usar el estado del componente local está bien . Como desarrollador, es su trabajo determinar qué tipos de estado conforman su aplicación y dónde debe vivir cada parte del estado. Encuentre un saldo que funcione para usted y vaya con él.

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

• ¿Otras partes de la aplicación se preocupan por estos datos?
• ¿Necesita poder crear más datos derivados basados ​​en estos datos originales?
• ¿Se están utilizando los mismos datos para manejar múltiples componentes?
• ¿Tiene algún valor poder restaurar este estado en un punto dado en el tiempo (es decir, 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)?