reactjs - receive - react lifecycle diagram
¿Cuál es la diferencia entre componentWillMount y componentDidMount en ReactJS? (6)
Miré la documentación de Facebook en ( React.Component ) y menciona cómo se invoca componentWillMount en el cliente / servidor, mientras que componentDidMount se invoca solo en el cliente. ¿Qué hace componentWillMount al servidor?
El método del
constructor
no es
el mismo que el de
componentWillMount
.
Según el autor de Redux, es arriesgado enviar acciones desde el constructor porque puede provocar la mutación del estado durante el renderizado.
Sin embargo, el envío desde
componentWillMount
está bien.
del problema de github :
Esto sucede cuando dispatch () dentro del constructor de un componente causa un setState () dentro de otro componente. React realiza un seguimiento del "propietario actual" para tales advertencias, y cree que estamos llamando a setState () dentro del constructor cuando técnicamente el constructor causa un setState () dentro de alguna otra parte de la aplicación. No creo que debamos manejar esto, es solo Reaccionar haciendo todo lo posible para hacer su trabajo. La solución es, como notó correctamente, despachar () dentro de componentWillMount () en su lugar.
Para agregar a lo que dijo FakeRainBrigand, se llama a
componentWillMount
cuando se procesa React en el servidor y en el cliente, pero
componentDidMount
solo se llama en el cliente.
Según la documentación ( https://facebook.github.io/react/docs/react-component.html )
Los métodos con el prefijo will se llaman justo antes de que algo suceda y
Los métodos con el prefijo did se denominan correctamente después de que sucede algo.
componentWillMount https://daveceddia.com/where-fetch-data-componentwillmount-vs-componentdidmount/
Sin embargo, hay un "problema": una llamada asincrónica para recuperar datos no volverá antes de que ocurra el render. Esto significa que el componente se renderizará con datos vacíos al menos una vez.
No hay forma de "pausar" la representación para esperar a que lleguen los datos. No puede devolver una promesa de componentWillMount o disputar un setTimeout de alguna manera.
nuestro componente no tendrá acceso a la interfaz de usuario nativa (DOM, etc.). Tampoco tendremos acceso a los referidos de niños, porque aún no se han creado. El componentWillMount () es una oportunidad para manejar la configuración, actualizar nuestro estado y, en general, prepararnos para el primer render. Esto significa que podemos comenzar a realizar cálculos o procesos basados en los valores prop.
componentWillMount es esencialmente el constructor. Puede establecer propiedades de instancia que no afecten el renderizado, extraer datos de una tienda de forma sincrónica y setState con él, y otro código libre de efectos secundarios simple que debe ejecutar al configurar su componente.
Raramente se necesita, y para nada con las clases de ES6.
componentWillMount
se realiza antes del
render
INICIAL de un componente, y se utiliza para evaluar los accesorios y hacer cualquier lógica adicional en función de ellos (generalmente también para actualizar el estado), y como tal se puede realizar en el servidor para obtener el primer lado del servidor marcado prestado.
componentDidMount
se realiza DESPUÉS del
render
inicial cuando se ha actualizado el DOM (pero de manera crucial ANTES de que esta actualización del DOM esté pintada en el navegador, lo que le permite realizar todo tipo de interacciones avanzadas con el DOM mismo).
Por supuesto, esto solo puede suceder en el navegador en sí y, por lo tanto, no ocurre como parte de SSR, ya que el servidor solo puede generar marcado y no el DOM en sí, esto se hace después de que se envía al navegador si se usa SSR
¿Interacciones avanzadas con el DOM que dices?
¿Qué? ... Sí, en este punto porque el DOM se ha actualizado (pero el usuario todavía no ha visto la actualización en el navegador) es posible interceptar la pintura real en la pantalla usando
window.requestAnimationFrame
y luego hacer cosas como mida los elementos DOM reales que se generarán, a los que puede realizar más cambios de estado, súper útil, por ejemplo, animando a una altura de un elemento que tiene contenidos de longitud variable desconocidos (ya que ahora puede medir el contenido y asignar una altura al animación), o para evitar flash de escenarios de contenido durante algún cambio de estado.
Sin embargo, tenga mucho cuidado para proteger los cambios de estado en cualquier
componentDid...
ya que de lo contrario puede causar un bucle infinito porque un cambio de estado también causará una nueva representación y, por lo tanto, otro
componentDid...
y sigue y sigue y sigue