Patrones de Rendimiento de React que Fallan en Aplicaciones de Producción de Larga Duración

Hola a todos. Soy Himanshu, y hoy quiero hablar sobre los patrones de rendimiento de React que se descomponen en aplicaciones de producción de larga duración. Estos son errores que he notado en mi propio trabajo que no aparecieron en la etapa de pruebas, que pasaron las revisiones de código, y que surgieron en Muchas veces, estos se convirtieron en errores que no podíamos replicar y causarían problemas más adelante. Y ese es el conocimiento que voy a discutir con ustedes ahora mismo.

Así que estos son cinco errores, pero todos comparten el mismo modelo mental. Y mostraré una demostración de todos estos y veremos cómo impactan las aplicaciones de producción y por qué. Así que hay cinco. Está la fuga de memoria. Están los cierres de cola. Está el uso de callback, que causa cierres de cola. Hay condiciones de carrera, y hay dependencias circulares. Así que discutamos primero el modelo mental. Este modelo mental es algo que me gustaría que todos ustedes se llevaran. Si hay una cosa que se llevan de esta sesión, asegúrense de que sea esto. Y lo que el modelo mental nos dice es que cada renderizado es una instantánea en React.

Básicamente, cada vez que un componente se renderiza, React toma una instantánea de todos los estados, los valores, los manejadores, todo. Y permanecen congelados en ese punto del tiempo. Lo que esto significa es, digamos que inicializas un event listener o una función o un uso de callback o cualquier cosa para ese caso. Se cierra y utiliza los términos y los valores que estaban en el momento de registrar la función, no cuando se ejecuta. Entraremos en ejemplos y explicaré lo que esto significa, pero me aseguraré de que esto quede grabado en nosotros.

Así que entremos en el primero, la fuga de memoria. Ahora, ¿qué significa esto? Bueno, muchas veces usamos event listeners Muchas veces usamos event listeners, ¿verdad? Tenemos event listeners en clics, podemos tenerlo en desplazamiento, podemos tenerlo en entrada de mouse, muchas cosas. Un error que a menudo termina siendo pasado por alto es no tener una limpieza. Y esto es algo que he visto que muchos ingenieros confían y pasa muy fácilmente las revisiones de código porque es algo tan menor que terminamos pasando por alto. Nos enfocamos tanto en los problemas mayores que esto termina pasando.

Y la razón por la que sucede es que, en entornos de staging o en entornos de pruebas, refrescamos las páginas mucho. Los event listeners se limpian como tal, pero en producción lo que he notado es que la gente podría tener tu aplicación o tu pestaña abierta durante horas o días a veces, ¿verdad? Y todos estos event listeners separados pueden seguir acumulándose, causando problemas de memoria. Eventualmente lleva a una ralentización de la aplicación o fallos aleatorios, entiendes el punto.

Así que aquí hay un poco más de esto, ¿verdad? Así que si ves aquí, tengo un componente que he montado. Es un código muy simple que he escrito. Así que hay un componente y simplemente he añadido un event listener aquí. Te lo mostraré. Así que hay un event listener en click que solo registra el valor. Así que si ves, cada vez que hago clic tengo la consola aquí y registra. Así que de todos modos, déjame mostrarlo. Hago clic, registra. Hago clic, registra. Parece bien, ¿verdad?

Digamos que lo desmonto. Ahora lo monto de nuevo. Ves que ahora los click listeners activos son dos. Así que cada vez que hago clic, hay dos registros. Y digamos que monto, monto, monto, ya sabes, unas cuantas veces. Ahora si ves cada clic está registrando cinco veces. Ahora imagina esto en un escenario del mundo real. Tienes un event listener en click o en hover, que tal vez añade algún CSS o abre un modal, podría ser cualquier cosa, ¿verdad? Ahora muchas veces estas acciones nuestras son idempotentes. Así que no importa si el listener se activa una vez o 10 veces, el resultado final será el mismo.

Así que no se detectará tan fácilmente, a menos que estés modificando algunos estados, ¿verdad? Pero lo que termina sucediendo si ves aquí, todos estos listeners, permanecerán en la memoria. Incluso si voy a otra pestaña, regreso, ves que todavía está allí porque la aplicación está ejecutándose, ¿verdad? Incluso si el componente se ha desmontado. Imagina cientos de estos o miles, ralentizarán tu sistema hasta el punto en que necesitará fallar. Hay más veces que tu componente podría montar o desmontar para crear el impacto.

Así que déjame restablecer los listeners por ahora. ¿Y cómo lo solucionamos? Quiero decir, es una solución bastante simple. Cada vez que tengas un listener, deberías tener una limpieza, ¿verdad? Así que la mayoría de las veces tenemos estos listeners y useEffects. Así que deberíamos asegurarnos de que siempre tengas una función de limpieza escrita. UseEffects nos proporciona eso, ¿verdad? Podemos usar esto. Y no es solo para event listeners. Es para muchos otros listeners también. Podría haber alguna conexión WebSocket que hayas configurado, o una conexión relacionada con WebRTC. Hemos enfrentado estos, ¿verdad? Y eso es lo que quería compartir.

¿Puedes ver solo una solución? Y ahora si lo desmonto, hay cero listeners activos. Lo monto de nuevo, hay uno. Desmonto cero. Si sigo haciendo clic, no pasa nada. Si monto de nuevo, cada clic, obtengo solo uno. Así que el error era solo una línea de código. La solución es solo una línea de código, pero impacta a miles, si no millones de usuarios. Solo una sola línea, ¿verdad? Y causa choques aleatorios de la aplicación y afecta la experiencia del usuario. Así que eso es algo a tener en cuenta. Así que déjame solo restablecer los listeners, y pasemos a la siguiente parte, cierres obsoletos.

Ahora, este es engañoso, porque he notado en nuestro caso de uso también, teníamos un componente en el que teníamos dos listeners diferentes. Uno era un listener de clic, y el otro era el listener en la pulsación de tecla, que realizaría la misma acción, pero estaban separados. Y debido a eso, estaban llamando a la, digamos, acción principal usando dos funciones diferentes. Sucede mucho cuando tienes una base de código grande, ¿verdad? Así que lo que terminó sucediendo es que el clic del mouse, el listener para eso, estaba usando valores de una ubicación diferente, y la pulsación de la tecla enter estaba usando de una ubicación diferente, lo cual está bien, ¿verdad? Deberían estar obteniendo los mismos valores, llamarían a sus propias funciones, realizarían sus efectos secundarios, y luego realizarían la acción común. Pero el problema que estaba allí era en la pulsación de tecla, el valor que estaba obteniendo, lo estaba leyendo de un estado, y deberías saber, nuevamente, el mismo modelo mental. Siempre que defines un listener o cualquier cosa en React, capturará el valor de los estados que existen en ese punto particular. ¿Verdad? Así que cuando el listener fue registrado, capturó los valores en ese punto. Así que cuando se ejecutó, idealmente debería haber tomado los valores más recientes, pero no lo hizo, ¿verdad? Tomó los valores antiguos. Y fue algo que no notamos porque el efecto secundario fue mío. Pero más adelante, cuando nos dimos cuenta, fue cuando descubrimos que, está bien, esto puede impactar. El impacto podría ser peor, ¿verdad? Porque podrías tener muchas acciones siendo realizadas sobre él, tal vez algún conteo de valores, o tal vez algunos datos analíticos, y eso se corromperá, y podrías no darte cuenta. Así que veamos un ejemplo.

Así que aquí, si ves, solo tengo un botón que incrementa un contador, y tengo un listener añadido en enter. Digamos que lo incremento a 6 y presiono enter. Así que ves, el atajo de tecla enter vio el valor 0, pero el estado real era 6. ¿Por qué? Te mostraré el código. Es bastante estándar, ¿verdad? Solo tengo un estado y uso un efecto de un manejador que en la pulsación de tecla enter, registraría el valor. ¿Ves el error? El error está aquí en las dependencias, no tengo nada mencionado, ¿verdad? Es un array de dependencias vacío. Así que básicamente significa que este efecto se ejecutará solo una vez cuando el componente se monte. Cuando el componente se monta, el valor del estado es 0. Así que no importa cuántas veces lo incremente, el valor del estado cambiará, pero esta función, la función que definimos dentro del efecto, siempre, siempre verá 0, no importa qué. ¿Cuál es la solución? Hay muchas maneras de solucionarlo. Una de esas maneras es simplemente usar un ref, ¿verdad? Hay dos maneras, en realidad, muchas más para ser honesto, pero una manera limpia que descubrí es usar un ref. Así que si ves, he creado un ref, ¿verdad? Y en el efecto, solo he puesto una dependencia en el estado, cada vez que cambia, el valor del ref cambiará, ¿verdad? Así que cuando presionas enter, básicamente solo tomará ese valor. Otra opción podría ser cambiar el array de dependencias y agregar el estado aquí, pero la razón por la que no se recomienda aquí es que cada vez que el valor de este estado cambia, el listener será destruido y se creará un nuevo listener. Eso es mucho trabajo extra. Solo usa refs para este propósito exacto. Déjame mostrarte ahora. Aquí estamos haciendo el código corregido, que es este. Así que digamos que lo aumento a seis y presiono enter, ves, lee el valor correcto, es tan simple como eso.

Así que deberíamos saber cuándo usar estados, cuándo usar refs y si nuestro código está causando valores obsoletos, porque muchas veces, podría estar a seis funciones de profundidad o siete componentes de profundidad. Y aunque no deberías usar props realmente mucho, pero tal vez estés usando, ya sabes, valores de un estado en diferentes componentes y esperas que funcionen juntos, pero las cosas podrían romperse. Pero sí, lleguemos a la tercera parte, la línea de use callback. La razón por la que llamo a esto una mentira es que esencialmente estás mintiendo a React si estás enfrentando este problema. Y he visto este problema surgir más veces de las que me gustaría admitir tanto, ya sabes, cuando he estado codificándolo o alguien en mi equipo en varias bases de código, varios lugares donde lo he hecho, ¿verdad? Lo he visto aparecer, no solo en proyectos normales, ya sabes, sino en aplicaciones de producción.

Lo que sucede es que muchas veces cuando escribimos código, especialmente en la era de la IA, ya sabes, ¿verdad? Usamos todos estos use callback, use memo y todos estos eran arrays de dependencias para optimizar nuestras aplicaciones. Sin embargo, las versiones recientes de React, ya sabes, y Nix manejan mucho de esto por nosotros. Pero seamos realistas, la mayoría de las bases de código aún no se han migrado a las últimas versiones, ¿verdad? Así que lo que termina sucediendo es que podrías haber hecho esto tú mismo. Escribimos código como este, ya sabes, tenemos algunos filtros. Cuando haces clic en filtrar, haces clic en fetch. Básicamente, obtiene los datos. Y para esta función, podrías tener un simple use callback, ¿verdad? Algo como esto, que obtendría datos de la API.

Y aquí en el array de dependencias, si notas aquí también, solo tenemos cambios de estado de filtro, que podrían cambiar, ¿verdad? Actualmente es alfa, podemos cambiarlo a beta, gamma o delta. Y esta función básicamente obtendría los datos aquí. Si ves, tenemos un array de dependencias vacío. ¿Qué significa eso? Significa que la función capturará el valor del filtro en el momento en que fue registrada, que es alfa. Así que incluso si lo cambias a beta, esta función no se recreará porque hemos dicho, pero está en un use callback para no recrear la función. ¿Y cuándo debería recrearse? Nunca. Es un array de dependencias vacío, ¿verdad? Se creará al montar. Ese es el problema. Ahora, este es un ejemplo muy simplista, pero a menudo lo que sucede es que usamos funciones, que, ya sabes, usan muchos estados diferentes muchas subfunciones diferentes, todo eso.

Y lo ponemos en un use callback. Y en el array de dependencias, ponemos dos o tres dependencias que sentimos que son correctas. Y React podría darte una advertencia, o tu IDE podría darte una advertencia de que, ya sabes, te faltan algunas dependencias. Pero lo que terminamos haciendo, usamos ESLint, deshabilitamos, ya sabes, faltan dependencias, básicamente. Y eso está mal, porque la única tarea de los arrays de dependencias es decirle a React que sí, estos son los valores que estoy usando en la función. Cada vez que un valor cambia, la función debería recrearse, no volver a ejecutarse, ¿verdad? Y nos confundimos, y pensamos que, no, simplemente omitiremos las dependencias. Eso está mal, porque estás yendo en contra de la forma en que React fue diseñado para ser usado, ¿verdad?

Y eso causa muchos problemas. Si tu código no funciona sin que tengas que omitir o perder algunas dependencias, realmente deberías replantearte tu código. Hay algunos casos excepcionales donde podría ser necesario, pero en el 99% de los casos, si tienes dependencias faltantes en useCallbacks, memos, useEffects, en cualquier lugar, tu código tiene errores, y es un error silencioso. Así que, revisa de nuevo. Así que, veamos. Te mostraré esta versión. Entonces, digamos que llamo a fetchData, así que obtiene con alfa, ¿verdad? Lo cambio a beta, y ahora llamo. Entonces, ves, todavía está obteniendo con el filtro alfa, ¿verdad? Aunque he seleccionado beta, puedo seleccionar coma aquí, y puedo obtenerlo. Pero lo mismo, ¿verdad? Porque el callback nunca sabe que necesita recrear la función si el filtro cambia. Veamos la versión corregida. Todos vimos la corrección, ¿verdad? Todo lo que tienes que hacer es simplemente agregar el filtro a las dependencias. Es una corrección muy simple. Pero ahora si llamas a los datos, obtiene con alfa. Lo cambio a beta y lo llamo.

Y en segundo lugar, nunca mientas a React. No omitas dependencias. Ahora, lleguemos a mi favorita, la condición de carrera. Así que, muchos de ustedes podrían haber enfrentado esto, ¿verdad? A menudo tenemos un montón de APIs ejecutándose, ya sabes, un montón de llamadas API sucediendo desde el front end. Y cada vez que un usuario cambia a alguna otra ventana o alguna otra pestaña o hace clic en un botón, se podrían llamar más llamadas API. Y las antiguas deben ser detenidas. Sin embargo, he notado que al escribir muchas APIs, olvidamos cancelarlas. Así que, les mostraré un ejemplo.

Por ejemplo, aquí, simplemente abrimos aquí. Y si ves, está escrito fetch A. Estas son tres solicitudes, A, B y C. Puedes asumir que, digamos, si estás en un CRM, ¿verdad? Y has aplicado un filtro. Así que, el primer filtro podría ser, digamos, para un canal de WhatsApp en particular. El segundo filtro podría ser para un canal de correo en particular. El tercero podría ser, digamos, para algún otro canal en particular, digamos, Instagram, ¿verdad? Ahora, no podemos determinar el tiempo que la respuesta de la API tardaría en responder, ¿verdad?

Tal vez tome un minuto, tal vez tome un segundo, tal vez tome cinco segundos, ¿verdad? Pero no podemos garantizar que si llamo A, luego B, luego C, la respuesta será en ese orden. Si ves que he consultado A, y he obtenido la respuesta A. Si consulto B, he obtenido la respuesta B. Consulto C, obtengo la respuesta de C, ¿verdad? Toma un segundo. Pero ahora, ¿qué pasa, digamos, si el usuario hace clic en B, y luego A, o A, luego B, digamos.

Entonces, el usuario llamó a A antes de llamar, fui a B. ¿Ves lo que pasó aquí? Lo que terminó sucediendo, déjame mostrarlo de nuevo. Entonces, digamos que voy a A, y luego vuelvo a B. Ves, disparé la solicitud para A, luego disparé la solicitud para B. Ahora, la solicitud para B, la respuesta para B, llegó más rápido. Así que, ese valor fue enviado. Y luego llegó la respuesta de A, que sobrecargó el valor de B. Entonces, según el usuario, lo que sucede es que han seleccionado un filtro B, pero los datos que han obtenido son para el filtro A, lo cual es incorrecto.

¿Por qué sucede esto? Simplemente porque no podemos garantizar el tiempo que tomaría responder. Te mostraré el código, ¿verdad? Es un user effect muy simple simplemente no tenemos una cancelación. Aquí, también tenemos las dependencias correctas, pero ¿cómo lo solucionamos? Bueno, cada vez que tu dependencia cambia, básicamente, el filtro, y sabes que el valor tiene que ser llamado de nuevo. En ese caso, deberías cancelar la solicitud existente. ¿Cómo lo haces? Hay dos opciones. Prefiero la segunda. También mostraré la primera. Simplemente puedes tener un flag de cancelación.

Entonces, cancelado es falso. Y cada vez que tu user effect se está limpiando, puedes simplemente establecer cancelado a verdadero. Y aquí hemos añadido un chequeo que si no está cancelado, entonces llamas a la API. Básicamente, lo que hace es que cada vez que haces clic en un filtro diferente, el antiguo será cancelado. Entonces, cuando obtienes una respuesta para el antiguo, está cancelado, por lo que no enviará los datos. Básicamente, estamos ignorando los datos. Pero hay una mejor manera, que es usar abort controllers. Si no estás bien informado sobre ello, puedes leer al respecto. Te tomará cinco minutos de tu tiempo, pero mejorará mucho la calidad de tu código.

¿Cómo funciona eso? Simplemente configuras un nuevo abort controller y lo pasas en cualquier framework que estés usando. Prácticamente todos lo soportan, ¿verdad? Pasas la señal. Entonces, cada vez que quieras abortar, o básicamente, tu user effect se está limpiando, simplemente pasas controller.abort, y se encargará de ello.

Así que, te mostraré el actualizado. Nuevamente, lo mismo. Obtuve B, luego obtuve A. Funciona perfectamente. ¿Ves? Hice clic en B, hice clic en A, pero hay, en la parte del medio donde mostró incorrecto, eso es porque estamos esperando. No puse un estado de carga. Así que, solución simple, ¿verdad?

Llegando al pensamiento final, dependencias circulares. Ahora, esto es algo que te diré que he tenido mi buena cuota de limpiar dependencias circulares en un momento. Nota que había cientos, ¿verdad?, que terminaron sucediendo. Estos no causan problemas que sean muy fácilmente notables, pero sí ralentizan tu aplicación. Podrían causar comportamientos no previstos.