reactjs - script - react helmet sync
ReactJS: ¿Por qué pasar el estado inicial del componente un accesorio es un antipatrón? (1)
Descargo de responsabilidad : cuando respondí esta pregunta, estaba aprendiendo / tratando de implementar Vanilla Flux y estaba un poco escéptico al respecto. Más tarde migré todo a Redux. Entonces, un consejo: solo ve con Redux o MobX. Es probable que ya ni siquiera necesite la respuesta a esta pregunta (excepto la ciencia).
Pasar el estado inicial a un componente como
prop
es un antipatrón porque el método
getInitialState
solo se llama la primera vez que se procesa el componente.
Nunca mas.
Lo que significa que, si vuelve a representar ese componente pasando un valor
diferente
como
prop
, el componente no reaccionará en consecuencia, porque el componente mantendrá el estado desde la primera vez que se procesó.
Es muy propenso a errores.
Y esto es lo que debes hacer:
Intenta hacer que tus componentes sean lo más apáticos posible. Los componentes sin estado son más fáciles de probar porque representan una salida basada en una entrada . Tan simple como eso.
Pero bueno ... mis datos de componentes cambian ... no puedo hacerlos apátridas
Sí, puedes, para la mayoría de ellos.
Para hacer eso, seleccione un componente externo para ser el titular del estado.
Con su ejemplo, podría crear un componente de
Dashboard
que contenga los datos y un componente
Widget
que no tenga ningún estado.
El
Dashboard
es responsable de obtener todos los datos y luego representar múltiples
Widgets
que reciben todo lo que necesitan a través de
props
.
Pero mis widgets tienen algún estado ... el usuario puede configurarlos. ¿Cómo los hago apátridas?
Su
Widget
puede exponer eventos que, cuando se manejan, hacen que el estado contenido en el
Dashboard
cambie, lo que hace que cada
Widget
se vuelva a procesar.
Usted crea "eventos" en su
Widget
al tener
props
que reciben una función.
Bien, ahora, Dashboard mantiene el estado, pero ¿cómo le paso el estado inicial?
Tienes dos opciones.
La más recomendada es que realice una llamada Ajax en el método
getInitialState
del
Dashboard
para obtener el estado inicial del servidor.
También puede usar
Flux
, que es una forma más sofisticada para administrar datos.
Flux es más un patrón, más que una implementación.
Puede usar Flux puro con la implementación de Facebook del
Dispatcher
, pero puede usar implementaciones de terceros como
Redux
,
Alt
o
Fluxxor
.
Alternativamente, puede pasar este estado inicial como
prop
al
Dashboard
, declarando explícitamente que este es solo el estado inicial ... como
initialData
, por ejemplo.
Sin embargo, si elige esta ruta, no puede pasarle un estado inicial diferente más adelante, porque "recordará" el estado después del primer renderizado.
OBS
No tienes toda la razón en tus definiciones.
El estado
se usa para almacenar datos mutables, es decir, datos que van a cambiar durante el ciclo de vida del componente.
Los cambios en el estado deben realizarse a través del método
setState
y harán que el componente se vuelva a representar.
Los accesorios se utilizan para pasar datos imbatibles a los componentes. No deben cambiar durante el ciclo de vida del componente. Los componentes que solo usan accesorios no tienen estado.
This es una fuente relevante sobre "cómo pasar el estado inicial a los componentes".
He creado un pequeño panel de ReactJS con la ayuda de SocketIO para actualizaciones en vivo. Aunque tengo la actualización del tablero, me molesta que no estoy muy seguro de haberlo hecho correctamente.
Lo que más me molesta son los
accesorios en getInitialState como publicación antipatrón
.
Creé un tablero que recibe actualizaciones en vivo de un servidor, que no requiere interacción del usuario más allá de cargar la página.
Por lo que he leído,
this.state
debería contener cosas que determinarán si el componente se debe volver a representar, y
this.props
... Todavía no lo sé.
Sin embargo, cuando inicialmente llama a
React.render(<MyComponent />, ...)
, solo puede pasar accesorios.
En mi caso, obtengo todos los datos del servidor, por lo que los accesorios iniciales terminan en este
this.state
todos modos.
Entonces, todos mis componentes tienen algo como esto:
getInitialState: function() {
return {
progress: this.props.progress,
latest_update: this.props.latest_update,
nearest_center: this.props.nearest_center
}
}
Lo cual, a menos que haya malinterpretado la publicación de blog mencionada anteriormente, es un antipatrón.
Pero no veo otra forma de inyectar el estado en el Componente, y no entiendo por qué es un antipatrón a menos que vuelva a etiquetar todos mis accesorios para anteponerles la
initial
.
En todo caso, siento
que es
un antipatrón porque ahora tengo que hacer un seguimiento de más variables que antes (las que anteponen las
initial
y las que no).