Understanding React: ciclo de vida de los componentes

React proporciona a los desarrolladores muchos métodos o "ganchos" que se llaman durante el ciclo de vida de un componente, lo que nos permite actualizar la interfaz de usuario y el estado de la aplicación. Saber cuándo usar cuál de ellos es crucial para comprender adecuadamente cómo trabajar con React.

Actualizar:

React 16.3 introdujo dos métodos de ciclo de vida más y depravó algunos de ellos, asegúrese de verificar el seguimiento en https://medium.com/@baphemot/understanding-react-react-16-3-component-life- ciclo-23129bc7a705

constructor

los constructores son la base de OOP: esta es una función especial que se llamará cada vez que se cree un nuevo objeto. Es muy importante llamar a una función especial super en los casos en que nuestra clase extiende cualquier otra clase que también tenga un constructor definido. Llamar a esta función especial llamará al constructor de nuestra clase padre y le permitirá inicializarse. Es por eso que tenemos acceso a this.props solo después de que inicialmente lo llamamos super.

Como se mencionó, los constructores son perfectos para configurar nuestro Componente: cree cualquier campo (variables que comiencen con esto) o inicialice el estado según los accesorios recibidos.

Este es también el único lugar donde se espera que cambie / establezca el estado sobrescribiendo directamente los campos this.state. En todos los demás casos, recuerde usar this.setState

HACER

  • establecer estado inicial
  • si no usa la sintaxis de propiedades de clase: prepare todos los campos de clase y las funciones de enlace que se pasarán como devoluciones de llamada

NO

  • causar efectos secundarios (llamadas AJAX, etc.)

en desuso - componentWillMount

Este es un caso de alguna manera especial: componentWillMount no difiere mucho del constructor; también se llama una vez en el ciclo de vida inicial de montaje. Históricamente, hubo algunas razones para usar el constructor componentWillMountover. Vea este problema de react-redux, pero tenga en cuenta que la práctica descrita allí está en desuso.

Muchos se verán tentados a usar esta función para enviar una solicitud para obtener datos y esperar que los datos estén disponibles antes de que el renderizado inicial esté listo. Este no es el caso: si bien la solicitud se inicializará antes del procesamiento, no podrá finalizar antes de que se llame al procesamiento.

Además, con los cambios en React Fiber (posterior a la versión beta de React 16), esta función podría terminar siendo llamada varias veces antes de que se llame al render inicial, por lo que podría provocar múltiples efectos secundarios. Debido a este hecho, no se recomienda utilizar esta función para operaciones que causen efectos secundarios.

Es importante tener en cuenta que se llama a esta función cuando se utiliza la representación del lado del servidor mientras que es contraparte: en este caso, no se llamará a componentDidMount en el servidor sino en el cliente. Entonces, si se desea algún efecto secundario en la parte del servidor, esta función debe usarse como una excepción.

Un setState utilizado en esta función es "libre" y no activará una nueva representación.

HACER

  • actualizar estado a través de this.setState
  • realizar la optimización de última hora
  • causar efectos secundarios (llamadas AJAX, etc.) solo en caso de representación del lado del servidor

NO

  • causar efectos secundarios (llamadas AJAX, etc.) en el lado del cliente

en desuso - componentWillReceiveProps (nextProps)

Se llamará a esta función en cada ciclo de vida de la actualización causada por cambios en los accesorios (representación del componente principal) y se le pasará un mapa de objetos de todos los accesorios aprobados, sin importar si el valor del accesorio ha cambiado o no desde la recuperación previa. fase de renderizado

Esta función es ideal si tiene un componente cuyas partes de estado dependen de los apoyos pasados ​​del componente principal, ya que llamar a this.setState aquí no causará una llamada de representación adicional.

Tenga en cuenta que debido al hecho de que la función se llama con todos los accesorios, incluso aquellos que no cambiaron, se espera que los desarrolladores implementen una verificación para determinar si el valor real ha cambiado, por ejemplo:

componentWillReceiveProps (nextProps) {
  if (nextProps.myProp! == this.props.myProps) {
    // nextProps.myProp tiene un valor diferente al de nuestro accesorio actual
    // para que podamos realizar algunos cálculos basados ​​en el nuevo valor
  }
}

Debido al hecho de que con React Fiber (posterior a 16 beta), esta función se puede llamar varias veces antes de que se llame realmente a la función de renderizado, no se recomienda utilizar aquí ninguna operación que cause efectos secundarios.

HACER

  • sincronizar el estado con los accesorios

NO

  • causar efectos secundarios (llamadas AJAX, etc.)

shouldComponentUpdate (nextProps, nextState, nextContext)

Por defecto, todos los Componentes basados ​​en clases se volverán a representar cada vez que cambien los accesorios que reciban, su estado o contexto. Si volver a representar el componente requiere un gran cálculo (por ejemplo, generar un gráfico) o no se recomienda por alguna razón de rendimiento, el desarrollador tiene acceso a una función especial que se llamará en el ciclo de actualización.

Esta función se llamará internamente con los siguientes valores de accesorios, estado y objeto. El desarrollador puede usarlos para verificar que el cambio requiera una nueva representación o no y devolver falso para evitar que se produzca la nueva representación. En otro caso, se espera que devuelva verdadero.

HACER

  • utilizar para aumentar el rendimiento de componentes de bajo rendimiento

NO

  • causar efectos secundarios (llamadas AJAX, etc.)
  • llame a esto.setState

en desuso - componentWillUpdate (nextProps, nextState)

Si la función shouldComponentUpdate no está implementada, o si decidió que el componente debería actualizarse en este ciclo de renderizado, se llamará a otra función del ciclo de vida. Esta función se usa comúnmente para realizar sincronizaciones de estado y accesorios para cuando partes de su estado se basan en accesorios.

En los casos en que se implemente shouldComponentUpdate, esta función se puede usar en lugar de componentWillReceiveProps, ya que solo se llamará cuando el componente se vuelva a representar.

De manera similar a todas las demás funciones de componentWill *, esta función podría terminar llamada varias veces antes de renderizar, por lo que no se recomienda realizar operaciones que causen efectos secundarios aquí.

HACER

  • sincronizar el estado con los accesorios

NO

  • causar efectos secundarios (llamadas AJAX, etc.)

componentDidUpdate (prevProps, prevState, prevContext)

Se llamará a esta función una vez finalizado el renderizado en cada uno de los ciclos de renderizado. Esto significa que puede estar seguro de que el componente y todos sus subcomponentes se han representado correctamente.

Debido al hecho de que esta es la única función que se garantiza que se invocará solo una vez en cada ciclo de representación, se recomienda utilizar esta función para cualquier operación que cause efectos secundarios. De manera similar a componentWillUpdate y componentWillReceiveProps, esta función se llama con mapas de objetos de accesorios, estado y contexto anteriores, incluso si no se produjo un cambio real en esos valores. Debido a eso, se espera que los desarrolladores verifiquen manualmente si el valor dado cambió y solo luego realizan varias operaciones de actualización:

componentDidUpdate (prevProps) {
  if (prevProps.myProps! == this.props.myProp) {
    // this.props.myProp tiene un valor diferente
    // podemos realizar cualquier operación que
    // necesita el nuevo valor y / o causa efectos secundarios
    // como llamadas AJAX con el nuevo valor: this.props.myProp
  }
}

HACER

  • causar efectos secundarios (llamadas AJAX, etc.)

NO

  • llame a this.setState ya que dará como resultado una nueva representación

Una excepción a la regla anterior es actualizar el estado en función de alguna propiedad DOM que solo se puede calcular una vez que un componente se ha vuelto a representar (por ejemplo, posición / dimensiones de algunos nodos DOM). Tenga mucho cuidado para evitar la actualización si el valor no cambió, ya que podría dar lugar a un bucle de representación.

componentDidCatch (errorString, errorInfo)

Una nueva adición en React 16: este método de ciclo de vida es especial en la forma en que puede reaccionar a los eventos que ocurren en el componente secundario, específicamente a cualquier error no detectado que ocurra en cualquiera de los componentes secundarios.

Con esta adición, puede hacer que su elemento padre maneje el error, por ejemplo, configurando la información del error en el estado y devolviendo el mensaje apropiado en su representación, o iniciando sesión en el sistema de informes, por ejemplo:

componentDidCatch (errorString, errorInfo) {
  this.setState ({
    error: errorString
  });
  ErrorLoggingTool.log (errorInfo);
}
render () {
  if (this.state.error) devuelve 
  regreso (
    // renderizar salida de componente normal
  );
}

Cuando ocurre un error, la función se llamará con:

  • errorString: el mensaje .toString () del error
  • errorInfo: un objeto con un solo componente de campo Stack que representa el seguimiento de la pila hasta donde ocurrió el error, por ejemplo:
en Thrower
    en div (creado por la aplicación)
    en la aplicación

componentDidMount

Esta función se llamará solo una vez en el ciclo de vida completo de un componente dado y se llamará señaliza que el componente, y todos sus subcomponentes, se representan correctamente.

Dado que se garantiza que esta función se invocará solo una vez, es un candidato perfecto para realizar operaciones que causen efectos secundarios, como solicitudes AJAX.

HACER

  • causar efectos secundarios (llamadas AJAX, etc.)

NO

  • llame a this.setState ya que dará como resultado una nueva representación

Una excepción a la regla anterior es actualizar el estado en función de alguna propiedad DOM que solo se puede calcular una vez que un componente se ha vuelto a representar (por ejemplo, posición / dimensiones de algunos nodos DOM). Tenga mucho cuidado para evitar la actualización si el valor no cambió, ya que podría dar lugar a un bucle de representación.

componentWillUnmount

Utilice esta función para "limpiar" después del componente si aprovecha los temporizadores (setTimeout, setInterval), abre sockets o realiza cualquier operación que necesitemos cerrar / eliminar cuando ya no sea necesario.

HACER

  • eliminar los temporizadores u oyentes creados en la vida útil del componente

NO

  • llame a this.setState, inicie nuevos oyentes o temporizadores

Ciclos de componentes

Hay varias razones por las que un componente puede volver a renderizarse, y en cada una de ellas se llaman diferentes funciones que permiten al desarrollador actualizar ciertas partes del Componente.

Creación de componentes

El primer ciclo es la creación del componente, que generalmente ocurre la primera vez que se encuentra un componente en el árbol JSX analizado:

Re-renderización de componentes debido a la re-representación del componente padre

Reprocesamiento de componentes debido a cambios internos (por ejemplo, una llamada a this.setState ())

Reprocesamiento de componentes debido a una llamada a this.forceUpdate

Reprocesamiento de componentes debido a la captura de un error

Introducido en React 16 como "ErrorBoundaries". Un componente puede definir una capa especial que puede detectar errores y proporcionar un nuevo método de ciclo de vida, componentDidCatch, que permite a los desarrolladores proporcionar acciones de reparación automática para la recuperación o el manejo correcto de los errores.

Un agradecimiento a @James_k_nelson, quien recientemente publicó un simulador componentWillReceiveProps, que puede encontrar y jugar en https://reactarmory.com/guides/lifecycle-simulators