Mastering UseEffect in React

¡Vamos! Hola, chicos, bienvenidos. Bienvenidos a cómo no usar UseEffect. Oh, UseEffect es un poco travieso, así que vamos a echarle un vistazo y ver cómo podemos usarlo de la manera correcta y las cosas que no deberíamos hacer.

Entonces, como saben, mi nombre es Mohamed, Soy Ingeniero de Software Senior Frontend en IO. Estoy aquí porque estoy hambriento de React y JavaScript, así que vamos a ello.

Entonces, nuestro viaje. Nuestro viaje comienza con un poco de historia, y luego responderemos tres preguntas. ¿Qué, por qué y cuándo? Estas son preguntas críticas para UseEffect, porque basándonos en estas preguntas, vamos a considerar algunas situaciones y algunas soluciones para esas situaciones. Así que esto es complicado, tenlo en cuenta.

Entonces, historia. Alrededor de 2019, React 16.8, introdujeron la evaluación de Hooks. Entonces, la cosa es, el Hook UseEffect se introdujo en ese momento. De hecho, desde que estábamos migrando a Hooks en Hooks Flingy, fue de alguna manera un reemplazo para el desmontaje de componentes y también la actualización de componentes en componentes de clase. Así que al final del día, efectivamente, código mucho más limpio en los componentes Hook.

Entonces, primero, ¿qué es? Como saben, UseEffect es solo un hook. Tiene dos parámetros, un callback y una dependencia. Es mejor renombrar callback a configuración porque es de alguna manera una configuración para tu efecto. De hecho, UseEffect es como una navaja suiza, así que debes tener cuidado. Entonces, un hook que se ejecuta bajo ciertas condiciones. Entonces, bajo algunas condiciones que vamos a aprender, ejecuta tu callback una vez que React monta el componente, una vez. Tan pronto como detecta algunos cambios en las dependencias, tiene sentido, tenemos un array de dependencias allí, así que tan pronto como uno de ellos ha cambiado, y el otro es en cada renderizado. Estas son tres situaciones en las que un hook, un React en realidad va a llamar a tu callback. El hook use effect.

Entonces, la cosa acerca de useEffect es, ¿por qué lo tenemos? De hecho, sí, porque te permite realizar algunos efectos secundarios, por ejemplo, obtener data, temporizadores, cosas de JavaScript y más. Así que consideremos el primer callback de useEffect llamado por React. El primero es, tan pronto como React monta el componente una vez, supongo que todos están familiarizados con eso. Entonces, si pasas el segundo parámetro, un array vacío, va a ejecutar tu callback una vez, y siempre que el componente se monte en el DOM. Entonces, la cosa es, en este caso estamos obteniendo algunos artículos. Sí, tiene sentido.

Entonces, vamos a obtener algunas entidades del back end, de nuestros puntos finales, agarrarlo, llevarlo al front end y renderizarlo en consecuencia. Entonces, el segundo es, tan pronto como detecta algunos cambios en las dependencias. Entonces, podríamos tener algunas dependencias para nuestro useEffect. Category ID en este caso. Tenemos la página de artículos, necesitamos el Category ID en este caso. Así que cada Category ID basado en ese Category ID deberíamos buscar nuestros artículos, ¿verdad? De nuevo, tiene sentido. Entonces, Category ID sería una de las dependencias y deberíamos buscar los artículos en consecuencia. Así que estoy usando Category ID en el cuerpo de mi useEffect.

Lo que pasa es que useEffect es lo que sucedió después del primer renderizado, ¿verdad? Esta es la llamada inicial, el renderizado inicial, y luego ejecuta el useEffect. Tan pronto como cambia el Category ID, va a renderizar de nuevo el árbol, y de nuevo, useEffect. ¿Por qué de nuevo useEffect? Porque una de nuestras dependencias ha cambiado. Y el otro, último, pero no menos importante, para ser honesto, lo que sucedió en cada renderizado. Oh, ya sabes, encontrar... Encontrar un caso de uso para esto podría ser un poco complicado. En algunos casos raros, podrías usarlo, pero de todos modos, está ahí. Como ya habrás notado, no hay una segunda dependencia. Así que significa que el array de dependencias está indefinido, así que no hay nada ahí. Como sabes, indefinido y array vacío son dos cosas diferentes que no son iguales entre sí. Entonces, como ves, el primer renderizado tiene sentido. Va a ejecutar useEffect, ¿verdad? Pero aquí, tan pronto como establezco uno de mis estados, lo que lleva a un rerenderizado, entonces va a, de nuevo, renderizar mi componente. Todo el componente se va a rerenderizar. Tres, añades todo el componente y rerenderizas. Cuatro, llamando al useEffect. Y no le importan las dependencias porque no hay dependencias. Va a ejecutarlo en cada solicitud de renderizado por React. Entonces, en este caso, setCount causó eso. En otros casos, podría ser un cambio de propiedad o lo que sea que se te ocurra. Entonces, ¿por qué lo necesitamos? En primer lugar, no se recomienda ejecutar efectos secundarios en el cuerpo del componente. Supongo que ya lo hemos notado un poco durante las cosas que te estaba contando en la diapositiva anterior, que tan pronto como cambias algo en tu componente, React va a rerenderizar tu componente, tu componente de función. Así que va a ejecutarlo de arriba a abajo, de arriba a abajo, de arriba a abajo, ¿verdad? Así que si pones algo, por ejemplo, buscando artículos en el cuerpo de tu componente, tan pronto como cambias algo, podría no estar incluso relacionado con los artículos.

Va a recordar esa función, recordar esa función, recordar esa función, buscar artículos en este caso. Lo cual no tiene sentido, ¿verdad? Porque queremos buscar artículos una vez. Por ejemplo, no hay un ID de categoría, pero si hay un ID de categoría, queremos renderizar, ya sabes, obtener nuevos artículos del backend bajo una condición, que es que el ID de la categoría ha cambiado. Así que en otros casos, no necesitamos.

Hay una razón de react. Y una razón de UX detrás de la escena, vamos a, ya sabes, profundizar en esos también. Así que, en primer lugar, quiero que entiendas el bucle de eventos, en este caso. ¿Cuándo ejecuta React el callback? Está conectado al bucle de eventos bajo el capó. ¿Y qué es eso? La cosa es que el bucle de eventos es un mecanismo en JavaScript para manejar cosas asíncronas, ejecutando JavaScript y casi todo en JavaScript depende del bucle de eventos.

¿Cómo funciona? Echa un vistazo a la pila de llamadas. Supongamos que estamos ejecutando una función llamada main. En la función main, podríamos tener setTimeout. Podríamos tener un fetch. ¿Qué son estos? Los llamamos Web APIs. Las Web APIs son algo que no son, tal vez es mejor decir que tal vez no son parte de la cosa de JavaScript o es algo que deberíamos solicitar fuera. Es mejor decir. Así que una de las Web APIs podría ser setTimeout. Una de ellas podría ser fetch. Así que cada vez que, ya sabes, solicitamos un setTimeout, hay una duración. Tan pronto como pasa la duración, hay una callbackFunction para setTimeout, ¿verdad? Lo va a empujar a la cola, que es la cola de tareas. Esto es importante porque la cola de tareas juega un papel importante en este caso. Así que el bucle de eventos, tan pronto como ve algo en la cola de tareas y la pila de colores está vacía, va a sacarlo y ponerlo en la pila de colores y ejecutarlo. Pero también hay otra cola, la cola de microtareas. La cola de microtareas es un poco complicada porque en primer lugar la cola de microtareas es responsable de las promesas, ¿verdad? Así que tenemos la cola de microtareas y la cola de tareas. La cola de tareas es para los setTimeouts y la cola de microtareas es para las promesas. Pero hay una diferencia entre estos dos y es que de la cola de tareas, recoge uno por uno, pero de la cola de microtareas, recoge hasta la finalización. ¿Verdad? Así que juega una parte importante en nuestra cosa. Así que voy a hacerte una pregunta de entrevista, ¿cuál de estos, ya sabes, cuál hace que el hilo principal se bloquee? Quiero bloquear el hilo principal, lo cual no tiene sentido, pero de todos modos, ¿cuál lo hace? Basándonos en lo que acabamos de hablar, Promise lo hace. ¿Por qué? Porque tan pronto como se crea, llama al bucle en este caso, llama al bucle y crea una nueva promesa. De nuevo, bucle crea una nueva promesa, ¿verdad? Porque es un bucle infinito en este caso, pero la cosa es que, ya que el bucle de eventos de Java Script, intenta, ya sabes, completar toda la cola y estamos añadiendo a esa cola todo el tiempo.

Nunca termina. Pero en setTimeout, es un poco diferente. ¿Por qué? Porque tan pronto como elige uno, el navegador va a repintar toda la página y elegir otro. Esta es la parte complicada. Entonces, ¿por qué lo mencioné? Porque esta es la pregunta ahora. Entonces, basándonos en esta descripción, ¿useEffect ejecuta su callback de forma sincrónica o asíncrona? ¿Cuál de los dos? Entonces, la respuesta es de forma asíncrona. ¿Por qué lo hace de forma asíncrona? Porque quiere permitir que el navegador renderice y muestre algo al usuario y no bloquee el hilo principal, ¿verdad? Y darle al usuario la oportunidad de ver quizás una carga o algo. Y luego, con la API Web y SetTimeout y las magias detrás de eso, obtener la información y renderizarla y presentársela al usuario.

Genial. UseEffect ejecuta su callback de forma asíncrona. ¿Por qué? Respuesta simple. Porque utiliza una cola de tareas detrás de escena. No voy a decir SetTimeout porque SetTimeout, no es del todo preciso. Hay una pequeña diferencia entre SetTimeout y otra cosa que llamo ZeroTimeout.

Sabes, porque hay cuatro milisegundos de diferencia entre ejecutar un callback usando SetTimeout sin un intervalo, que es cero en este caso, y ZeroTimeout, que utiliza un canal de mensajes detrás de escena. De hecho, el código fuente de React también utiliza un canal de mensajes detrás de escena. Puedes echar un vistazo a su paquete de programador del código fuente de React en línea alrededor del 586.

Si sigues estas líneas, verás que hay una comprobación de prioridad para setImmediate, y luego messageChannel, luego busca SetTimeout, ¿verdad? Así que la razón de UX era esa. Así que el renderizado inicial de React, pintado del navegador, use effect tan pronto como estableces un estado, React renderiza, y el navegador pinta. Así que esta es la razón de UX, que useEffect se ejecuta de forma asíncrona inmediatamente, pero de forma asíncrona. Inmediatamente, significa que la duración es de cero milisegundos, como hablamos.

¿Existe alguna versión sincrónica de useEffect? Sí, la hay. useLayoutEffect es la versión sincrónica de useEffect. Como ves, aquí está nuestro useEffect después del pintado del navegador, pero antes de eso está nuestro useLayoutEffect. Eso es muy importante. Así que también hay una razón de ref detrás de escena. Entonces, como sabes, podríamos querer tener una referencia a uno de nuestros elementos. Dado que React ejecuta todo de arriba a abajo, así que sin el useEffect aquí, no tenemos acceso al elemento creado. En algunos no modernos, ¿puedo decir modernos, o nuevos frameworks como SolidJS y cosas así, sí, puedes tener acceso antes de eso porque el compilador lo hace detrás de escena. Pero en React, dado que todo se ejecuta de arriba a abajo, es un poco diferente, así que necesitamos useEffect para obtener una instancia del elemento. Así que todo está adjunto al cuerpo, así que tienen una referencia al elemento. Así que pueden darte la propiedad actual. Así que situaciones y soluciones. La primera, la llamo bucle desagradable. Supongo que de vez en cuando te das cuenta de que en tu pestaña de red, este es un segmento de tiempo de un segundo. Ahora mismo hay 28 solicitudes. ¿Por qué? Porque estás estableciendo un estado que actualiza una dependencia. Solo echa un vistazo a tus dependencias.

O a veces estableciendo un estado en un useEffect sin array de dependencia. Sí, asegúrate. La primera vez, se renderiza, ya sabes, no es un bucle infinito, pero se renderiza uno tras otro. Sabemos por qué no es un bucle infinito, debido al bucle de eventos y setTimeout y taskQueue seleccionando uno por uno. Pero establecer un estado en un useEffect sin array de dependencia, puede causar este problema, estos bucles desagradables.

Así que si echas un vistazo a este fragmento, este fragmento, puedes ver eso. Así que estamos empezando desde arriba, obteniendo artículos, estableciendo artículos aquí. Los artículos son una de nuestras dependencias. Y voilà. Así que la pregunta es, los artículos son iguales a los artículos, chicos. Ya sabes, el contenido es igual al otro. Ambos contienen el artículo uno, el artículo dos, el artículo uno, el artículo dos. Pero la parte complicada en este caso es que los objetos son tipos de referencia. No son tipos primitivos. No son iguales entre sí, ¿verdad? Así que si quieres aprender más, echa un vistazo a esta pregunta. Podría ser una pregunta de entrevista. ¿Cuándo ejecuta React el callback en estos casos? Considerémoslo juntos. Use effect sin array de dependencia. Vamos, pan comido. Lo sabemos. Con un array de dependencia vacío. Me parece bien. ¿Pero qué? ¿Qué es esto? Así que la cosa es, ya sabes, tenemos tipos primitivos y tipos de referencia. ¿Y qué hace React detrás de la escena? Simplemente compara los valores. Mi pregunta es, ¿es la cadena de React igual a la cadena de React? Por supuesto. Así que vamos al siguiente. Así que respondámoslo primero. Así que son iguales entre sí. Significa que nuestras dependencias no han cambiado, así que va a ejecutarlo una vez. Y, ya sabes, component did mount.

De alguna manera, component se montó. Entonces useEffect, el último, una de nuestras dependencias es loca. Es un objeto que contiene la etiqueta React. ¿Qué pasa con este caso? Para nada. Significa que objeto es igual a objeto. No, no son iguales en absoluto porque hacen referencia a diferentes partes de la memoria. Entonces, en este caso, lo va a ejecutar en cada renderizado. Entonces significa que este es exactamente como el primero y estos dos son iguales entre sí. ¿Por qué el último? Porque dos objetos no son iguales entre sí.

Segundo, lo llamo nasty async. Entonces, estamos obteniendo artículos, ¿verdad? Así que quiero mostrar mis habilidades de codificación para dejarme usar la sintaxis async y hacerlo más elegante. ¿Es un buen truco? En este caso, no, para nada, porque no va a funcionar. Basado en la especificación de la función async, las funciones async siempre devuelven una promesa. ¿A quién le importa? Deja que devuelva una promesa. No me importa, pero deberías preocuparte porque hay una función de limpieza detrás de la escena como sabes. Deberías devolver una función, no una promesa. Entonces, en este caso, si tienes una declaración de retorno, ¿qué hace? ¿Qué hace tu llamada de retorno? Devuelve una función. Bien. ¿Qué pasa con este caso? Estoy devolviendo uno, pero no, no es el uno porque en realidad, estás devolviendo una promesa que esa función sería el resultado de esa promesa. Así que no es lo que React busca. Entonces, poner async no es el uno. ¿Cómo arreglarlo? Sí, fácilmente. Solo envuélvelo con una función async. Es cierto que no podemos hacerlo async y tener una espera, pero podemos llamar a funciones async de todos modos. Entonces, lo voy a llamar normalmente, y tenemos funciones de limpieza en este caso, que funcionan.

Tres, nasty JavaScript. Chicos, si quieren hacer algo fuera del ciclo de, o ciclo de renderizado de React, por ejemplo, manipulación tonta o agregar oyentes de eventos al cuerpo o algo así, o a veces temporizadores, no va a funcionar porque van a aplicar esos cambios, pero ¿quién va a revertirlo tan pronto como desmontes el componente? Por eso está la función de limpieza, ¿verdad? Así que ten en cuenta que usa la función de limpieza. Si hiciste el fondo rojo, solo, si es blanco o algo así, incluso si limpias los cambios que hiciste. Entonces, si es un oyente de eventos, ten en cuenta que deberías eliminarlo. Si es un setInterval, ten en cuenta que deberías limpiarlo.

Estado desagradable. Este es interesante. Echa un vistazo. Estoy intentando filtrar mis artículos, ¿verdad? Tengo artículos filtrados. Tengo artículos en el montaje de componentes, voy a tomar todos los artículos. Y tan pronto como cambie la búsqueda o los artículos, los voy a filtrar en base a esta palabra clave de búsqueda. Pero lo cierto es que puedes hacer todas estas cosas sin un useEffect. Como sabes, este useEffect, este es un useEffect, ¿verdad? Causa retraso e incluso bucles detrás de escena. Así que usemos otro método. Entonces, ¿cuál es la solución? Pan comido. Usa memo. Porque memo se ejecuta... Estoy escribiendo 11 en este caso en el primer renderizado si las dependencias han cambiado. Porque en el primer renderizado, todas las dependencias se consideran que han cambiado. Así que te va a traer memorización y va a eliminar un useEffect para ti. Solo ten en cuenta que, cada vez que veas un useEffect en tu componente, podrías necesitar considerarlo porque puedes arreglarlo fácilmente sin el useEffect, porque no lo necesitas. Correcto.

Cinco, llamada de evento desagradable. A veces estás utilizando efectos de uso para encargarte de llamar a eventos parentales. En este caso, quiero llamar a abrir y cerrar en base a estos abiertos, ¿verdad? Pero lo cierto es, ¿no podrías cortar esta parte y simplemente ponerla en HandleClick? Va a funcionar, ¿verdad? Echa un vistazo al resultado. Acabo de eliminar el callback de uso y lo puse aquí. Lo cierto es que ahora es bastante sencillo y fácil. Permíteme contarte lo que pasó. Podría ser un poco confuso. Echa un vistazo. Aquí, useEffect, causa, ejecución, abrir, cerrar, y la pintura del navegador sucedió, ¿verdad? Entonces, lo cierto es que, si lo cambias, todo, estos renderizados de React no sucederán. Y abrir, cerrar, la cosa vendrá aquí. Tan pronto como establezcas este estado, se llamaría a abrir, cerrar y el renderizado de React y la pintura del navegador. Menos useEffect, más legible, y además no tienes un renderizado extra de React allí.

Nasty Fetch. Entonces, este es el último. Nasty Fetch. A veces, estás intentando buscar algo, ¿verdad? En este caso, artículos. Y creo que he considerado todo, ¿verdad? Pero no, no es correcto. No he considerado la carga, vamos a agregar la carga. Entonces, tengo un estado de carga aquí. Sí, antes de buscar artículos, carga verdadera. Después de eso, carga falsa, ¿verdad? ¿Pero qué pasa con la condición de carrera? Ya sabes, alguien podría hacer clic cambiando categorías y podría suceder una condición de carrera, ¿verdad? Entonces, vamos a agregar la lógica de la condición de carrera. Entonces, la lógica de la condición de carrera, puedes hacerlo fácilmente. Una variable es cancelada verdadera. Si se cancela, no establezcas nuestros artículos. Significa que si alguien juega con los artículos, va a funcionar normalmente. Entonces, el tipo verá el último clic de ID de categoría. Pero el problema aquí es que esta solicitud de búsqueda ha sido enviada y está esperando la respuesta, vamos a cancelarla también. La solicitud en sí. Entonces, puedo usar el controlador de aborto. Tengo un controlador de aborto y puedo pasarlo como una señal a mi función de búsqueda y en mi función de limpieza, puedo abortarlo. Entonces, significa que si la categoría ha cambiado, va a cancelar la solicitud anterior. Pero chicos, echen un vistazo, mi useEffect tiene alrededor de 20 líneas de código. ¿Puedo optimizarlo de alguna manera? Sí, ¿por qué no usas use query? Entonces, en menos de 10 líneas puedes tener todo en un solo paquete y también almacenamiento en caché y cosas, incluso cancelando. Entonces, puedes reemplazarlo con react query 10 stack. Gracias por 10 stack. Entonces, tenemos use query, puedes usar react query y tener todo listo para usar, genial. Pero, ¿no hay una solución mejor? Sí, la hay. ¿Por qué no usar next.js y renderizar todo a medida que avanzas? Entonces, significa que puedes obtener cosas con next.js o incluso otros frameworks meta que existen. Puedes obtener artículos de antemano en el lado del servidor y pasarlo a los clientes y renderizarlo e incluso tener SSR. ¿Hay una solución aún mejor? Sí, componentes de servidor. Lo introdujeron recientemente y renderizarás todo en el lado del servidor y lo moverás a los clientes. Sí, la hidratación todavía está ahí, pero de todos modos, va a hacer tu vida más fácil y la estructura del código se renderizará a medida que avanzas. Gracias. Entonces, si quieres aprender más sobre esos efectos, Dan Abramov en su blog web ya escribió un documento completo en overreacted.io, una guía completa para usar efectos. Los documentos oficiales también están ahí. Y Jack Archibald, hay una charla sobre el bucle de eventos del navegador web. Te recomiendo encarecidamente, si quieres aprender más sobre el bucle de eventos, si fue un poco confuso para ti. Y gracias. Feliz hacking.