reactjs - qué - react js

¿Por qué no se debe utilizar componentWillMount?

Question

La activación de una llamada al servidor para obtener datos en el método del ciclo de vida de componentes de WillMount es una mala práctica

Y por qué es mejor usar componentDidMount.

Answer 1

Para citar a @Dan Abramov

En futuras versiones de React, esperamos que componentWillMount se active más de una vez en algunos casos, por lo que debería usar componentDidMount para las solicitudes de red.

Lea más here .

Answer 2

Según entiendo, una de las razones más importantes tiene que ver con establecer las expectativas correctas para que los desarrolladores lean el código.

Si usamos componentWillMount es tentador pensar que la recuperación tiene tiempo de suceder, entonces el componente "hizo" el montaje, y luego ocurrirá el primer renderizado. Pero eso no es el caso. Si hacemos una llamada asíncrona (como una llamada a la API con promesas), el componente ejecutará realmente el render antes de que la recuperación pueda volver y establecer el estado del componente (o cambiar el estado de Redux, o lo que sea).

Si en su lugar usamos componentDidMount , entonces está claro que el componente se procesará al menos una vez antes de recuperar cualquier dato (porque el componente ya se montó). Entonces, por extensión, también está claro que tenemos que manejar el estado inicial de manera que el componente no se rompa en el primer procesamiento ("vacío").

Answer 3

componentDidMount es el mejor lugar para poner llamadas a buscar datos, por dos razones:

1. El uso de componentDidMount deja claro que los datos no se cargarán hasta después del procesamiento inicial. Debe configurar correctamente el estado inicial, por lo que no obtiene undefined estado undefined que cause errores.

2. Si necesita renderizar su aplicación en el servidor, se llamará a componentWillMount dos veces (en el servidor y nuevamente en el cliente), lo que probablemente no sea lo que desea. Poner el código de carga de datos en componentDidMount asegurará que los datos solo se obtengan del cliente. En general, no debe agregar efectos secundarios a componentWillMount .

Answer 4

ACTUALIZACIÓN - mayo / 2018
Hay una nueva característica para reaccionar en un progreso de trabajo llamado representación asíncrona .
A partir de la v16.3.2 estos métodos no son "seguros" de usar:

• componentWillMount
• componentWillReceiveProps
• componentWillUpdate

Puedes leer más sobre esto en los docs .

Como regla general , no use componentWillMount (si usa la sintaxis de class es6). usa el método constructor lugar.
Este método de ciclo de vida es bueno para una inicialización del estado de sincronización.
componentDidMount por otro lado, es bueno para la manipulación de estado asíncrono.

Por que
Bueno, cuando realiza una solicitud asíncrona en el constructor / componentWillMount WillMount lo hace antes de render se llame al render , para cuando la operación asíncrona haya finalizado, es probable render método de render ya haya terminado y no haya ningún punto para establecer el "estado inicial" en esta etapa. ¿eso?.
No estoy seguro de que este sea su caso aquí, pero la mayoría de los casos en que los desarrolladores desean iniciar el estado asincrónicamente en componentWillMount es para evitar una segunda llamada de render . pero no se puede evitar, como se mencionó anteriormente, el render se disparará de todos modos antes de que finalice la operación asíncrona.
Por lo tanto, el mejor momento para llamar a una operación asíncrona es después de que un render haya llamado y el componente esté montado (podría montar null o un <div/> vacío) y luego recuperar sus datos, establecer el estado y hacer que se vuelvan a representar respectivamente.

Answer 5

El ciclo de vida del montaje del componente es

• constructor()
• componentWillMount () / UNSAFE_componentWillMount () (reacciona 16)
• hacer()
• componentDidMount ()

El constructor y el componente montarán la llamada antes de la llamada render (), que es responsable de la representación de la página.

Aquí se inicializa el estado en Constructor y se llama a api en componentDidMount debido a llamadas asíncronas.

ComponentWillMount fue bueno para el estado inicializado antes de ES6 cuando el constructor no estaba allí. Pero ahora ComponentWillMount no sirve para nada y el equipo de reaccionar lo está pensando después de reaccionar 17.

Además de lo anterior, reaccionar se ha movido para reaccionar a la arquitectura de fibra , para evitar representaciones innecesarias y mejorar el rendimiento, la reacción ha decidido alejarse de los métodos componentWillMount, componentWillReciveProps y componentWillUpdate.