reactjs - script - react helmet sync

ReactJS: ¿Por qué pasar el estado inicial del componente un accesorio es un antipatrón?

Question

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).

Answer 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".