¿Por qué los documentos de React recomiendan hacer AJAX en componentDidMount, no en componentWillMount?

102

El título lo dice todo. Entiendo por qué componentDidMountes apropiado para cualquier cosa que requiera acceso DOM, pero una solicitud AJAX no necesariamente o normalmente lo necesita.

¿Lo que da?

reactjs

— Alan H.
fuente

@FurkanO Creo que se refería al acceso a los elementos DOM representados por el componente. Y tiene toda la razón porque si intentara acceder a dichos elementos componentWillMountfallaría dado que el componente ... no se montó.

— ZekeDroid

@AlanH. Eliminé mi pregunta, por supuesto que tiene acceso a dom en componentDidMount. Esta es una regla, nada que explicar al respecto. Gracias.

— FurkanO

En mi opinión, la razón por la que llamamos a la función Ajax después de componentDidMount es que primero debemos asegurarnos de que el elemento se esté procesando sin problemas al principio. Después de eso, podemos hacer una llamada ajax. Si llamamos a ajax primero y ocurre un error, causará problemas al renderizar

— Faris Rayhan

Respuestas:

componentDidMountes para efectos secundarios. Agregar oyentes de eventos, AJAX, mutar el DOM, etc.

componentWillMountrara vez es útil; especialmente si le importa la representación del lado del servidor (agregar detectores de eventos causa errores y fugas, y muchas otras cosas que pueden salir mal).

Se habla de eliminar componentWillMountcomponentes de la clase, ya que tiene el mismo propósito que el constructor. Permanecerá en los createClasscomponentes.

— Bandido
fuente

Agregar detectores de eventos provoca errores y fugas todo el tiempo en el servidor, o solo en componentWillMount? Realmente no veo la distinción.

— Alan H.

@Alan: si está utilizando React tanto en el lado del cliente como en el lado del servidor, encontrará que cualquier cosa dentro componentWillMountse ejecutará en un render del lado del servidor. Mientras que si estuviera usando componentDidMount, eso solo se ejecutaría en el lado del cliente. Como resultado, poner cosas componentWillMountque realicen interacciones externas o se unan a eventos, etc., no es una gran idea. Si no tiene planes de renderizar sus componentes en el lado del servidor, todavía no es una buena idea solo para la posible portabilidad del código. Todo esto está fuera de la razón principal por la que es malo, que se explica en la respuesta de @daniula.

— Mike Driver

componentWillMount se ejecuta en el servidor, pero componentWillUnmount (donde se eliminan los oyentes) no. Esto haría que agregara oyentes y nunca los limpiara.

— Brigand

Las personas del equipo central de React están considerando eliminar componentWillMount de versiones futuras.

— cchamberlain

@AnkitSinghaniya rompería la representación del servidor y las pruebas unitarias superficiales.

— Brigand

Yo también tuve el mismo problema al principio. Decidí intentar hacer solicitudes, componentWillMountpero terminé en varios pequeños problemas.

Estaba activando el renderizado cuando la llamada ajax finaliza con nuevos datos. En algún momento, la renderización del componente tomó más tiempo que la respuesta del servidor y en este punto la devolución de llamada de ajax estaba activando la renderización en el componente desmontado. Este es un caso de borde, pero probablemente hay más, por lo que es más seguro seguir componentDidMount.

— daniula
fuente

Bien gracias. Pensé que podría ser algo así, pero tienes razón, es sorprendente que la solicitud ajax pueda finalizar antes de que lo haga el render.

— Alan H.

@daniula ¿Estás seguro? ¿Cómo puede finalizar la solicitud AJAX antes de renderizar?

— Leon Grapenthin

Este es el mundo asincrónico del navegador. Nunca debe asumir que una función siempre será más rápida que el resto. Como mencioné, es un caso extremo y probablemente significa que debe optimizar su proceso de renderizado, pero usar el método de ciclo de vida adecuado le hará la vida mucho más fácil en este punto.

— daniula

El constructor de la clase @SooChengKoh ES6 es equivalente a componentWillMount, por lo que aún debe seguir usándolo componentDidMountpara sus llamadas ajax.

— daniula

@SooChengKoh - Definitivamente no debería hacer nada en el constructor que lleve al estado que se debe establecer, que conducirá a condiciones de carrera en el cliente y el servidor. Nunca debe llamar setStatea un constructor de componentes y no tiene forma de determinar cuándo se completará la llamada AJAX. twitter.com/dan_abramov/status/576453138598723585

— cchamberlain

De acuerdo con la configuración de la documentación, el estado componentWillMountno activará una nueva renderización. Si la llamada AJAX no se está bloqueando y devuelve un mensaje Promiseque actualiza el estado del componente en caso de éxito, hay posibilidades de que la respuesta llegue una vez que se haya procesado el componente. Como componentWillMountno desencadena una repetición, no tendrá el comportamiento que esperaba, que es el componente que se representa con los datos solicitados.

Si usa cualquiera de las bibliotecas de flujo y los datos solicitados terminan en la tienda a la que está conectado el componente (o heredan de un componente conectado), esto no será un problema, ya que la recepción de esos datos, muy probablemente, cambiará los accesorios. finalmente.

— gabriel.g
fuente

componentWillMountno activa una re-renderización solo porque se define un nuevo estado antes de la primera renderización. Pero si setStatese llama en una devolución de llamada AJAX, definitivamente se llamará después del primer renderizado y activará un nuevo renderizado.

— webdif