El arma secreta de React: Aprovechando las características concurrentes para un rendimiento de primera categoría

Estoy feliz de estar aquí. Gracias por estar aquí. Gracias Natalia por la introducción. Voy a hablar sobre la concurrencia en React y cómo puedes usarla para mejorar el rendimiento de tus aplicaciones. Y sí, soy ingeniero de software y actualmente trabajo en Spotify.

Antes de entrar en la charla en sí, solo un poco de trasfondo sobre mi trayectoria y cómo me adentré en el frontend. Así que comenzó alrededor de 2017. Estudié un curso de ciencias de la computación o un curso muy relacionado con la tecnología, pero construí un sitio web como parte de mi carrera y lo odié absolutamente. Pero me encontré aprendiendo HTML y CSS después de graduarme. Y luego hice eso por un tiempo y finalmente conseguí mi primer puesto en tecnología en 2018. Y básicamente esta fue mi introducción a los frameworks de frontend y más específicamente React. Y luego trabajé allí por un tiempo y me mudé a una startup de comercio de criptomonedas donde trabajaba más intensamente solo con React. Y luego en 2022 comencé un rol de full stack, que es mi primer rol de full stack en Spotify. Así que en realidad trabajo más con el backend estos días, pero trabajo con Java en el backend y React en el frontend.

Bien, suficiente sobre mí. Así que hoy, aquí hay una agenda rápida de lo que voy a hablar. Comenzando con un poco de trasfondo sobre el problema de rendimiento. Entonces, ¿por qué estamos hablando de concurrencia en primer lugar? Y luego hablaremos un poco sobre la concurrencia bajo el capó. Así que cómo React realmente es, cómo React logró la concurrencia. Veremos las principales API concurrentes que se introdujeron en React 18. Hablaré brevemente sobre algunos casos de uso y luego algunas desventajas porque todo viene con una desventaja. Muy bien. Así que si piensas en las aplicaciones que usas en tu día a día hoy, Instagram, Twitter, esas aplicaciones dependen de dar retroalimentación inmediata al usuario, ¿verdad? Cuando desplazo mi feed de Instagram, recibo retroalimentación inmediatamente. Y las aplicaciones que construimos hoy se han vuelto cada vez más complejas, ¿verdad? Comparado con hace muchos años. Así que hay más datos que estas aplicaciones tienen que manejar, lo que significa más renders, más computación. Y todo esto esencialmente significa que hay una mayor probabilidad de una carga aumentada en el rendimiento de estas aplicaciones. Así que esencialmente, aquí es donde entra la concurrencia. Es crucial optimizar para la capacidad de respuesta para asegurar que la experiencia del usuario en estas aplicaciones sea lo mejor posible.

Así que aquí. Y sobre el tema principal.

El qué y el cómo de la concurrencia. En pocas palabras, la concurrencia es la capacidad de gestionar múltiples tareas simultáneamente, como renderizar la interfaz de usuario, responder a la entrada del usuario, procesar solicitudes de red, y hacer todo esto sin bloquear o ralentizar el hilo principal. Así que echemos un vistazo al trasfondo de esto y cómo React realmente logra esto.

Imagen superior, sincrónica, imagen inferior, concurrente. Y el proceso de renderizado en React se divide en dos fases. Así que está la fase de renderizado, y está la fase de commit. Así que si miras la primera imagen, notarás que la fase de renderizado, que es donde React comparará el DOM existente con el DOM virtual, calculará la diferencia, y básicamente hará esta computación y determinará qué cambios necesitan hacerse. Y luego la fase de commit es donde React realmente aplicará estos cambios al DOM.

Así que si miras la primera imagen, es solo un bloque continuo largo de renderizado, ¿verdad? Y luego tenemos el commit, y luego tenemos estas tareas. Y lo que eso significa, típicamente, antes de React 18, es que la fase de renderizado no podía ser interrumpida. Así que cuando cargo un componente o una página, React tiene que completar esa fase de renderizado antes de que el usuario pueda realmente interactuar con la página web. Así que la fase de commit, como puedes ver, básicamente hace que este proceso sea interrumpible. Así que si miras la imagen inferior, notarás que esta fase de renderizado se divide en pequeños fragmentos y esencialmente, React ha creado algo bastante inteligente, donde en lugar de renderizar todo en un solo bloque, realmente puede interrumpir esta fase de renderizado y el usuario puede priorizar las interacciones del usuario entre la fase de renderizado.

Así que nota que tenemos estos pequeños fragmentos de renderizado. Tenemos una tarea, que podría representar un evento de usuario como un clic o escribir. Luego React vuelve al renderizado, maneja la tarea, y es ese ir y venir, lo que significa que nuestras aplicaciones tienen una experiencia de usuario más fluida, y luego son más receptivas.

Así que las posibilidades de tener algún tipo de congelamiento en la UI son menos probables. Así que aquí hay un diagrama muy básico, a un nivel muy alto, algo amateur que creé para representar lo que sucede detrás de escena. Vemos nuestro navegador web, vemos la aplicación React, y luego vemos algo llamado un programador de tareas.

Este programador es como el motor detrás de este modelo de concurrencia. Así que lo que hace es, en primer lugar, he mencionado que el trabajo o el renderizado se divide en pequeñas unidades, ¿verdad? Este concepto se llama time-slicing, por lo que el trabajo de renderizado que se requiere se divide en fragmentos. Y luego lo que hace el programador es, mira todas las tareas que necesitan ser manejadas y las prioriza y luego ejecuta estas tareas.

Así que una tarea de alta prioridad puede considerarse como un usuario haciendo clic en un campo de entrada, o un usuario intentando desplazarse o escribir. Sí, hacer clic en un botón, por ejemplo, eso es de alta prioridad porque, como dije, el usuario espera una respuesta inmediata, ¿verdad? No quiero hacer clic en un botón y que se congele. Y la menor prioridad es obtener datos de un backend o renderizar algún tipo de lista larga.

Así que esta tarea, este programador de tareas incorporado, básicamente asigna esta prioridad a las diferentes tareas, y luego cede el control de nuevo al navegador cada cinco milisegundos. Así que cada vez que nota que hay un clic en la pantalla, básicamente dirá, navegador, esto es importante, maneja esto. Una vez que eso está hecho, React toma el control y continúa renderizando. Si hay otro clic, cede el control de nuevo al navegador y así sucesivamente. Y hace esto por defecto cada cinco milisegundos. Así que básicamente solo verifica continuamente si hay alguna tarea de alta prioridad que necesita ser completada.

Estas son capturas de pantalla que tomé para hacer esto más real del paquete del programador en el repositorio oficial de React. Así que nota a la izquierda, tenemos esta función de bucle de trabajo. Nuevamente, como dije, esto continúa verificando las tareas de alta prioridad. Y luego a la derecha, hay una función llamada should yield to host, y eso es lo que determina si el host significa el navegador. En este caso, eso es lo que determina si React debe ceder el control al navegador o continuar el proceso de renderizado.

Bien, pasemos ahora a las cosas más prácticas. Así que ya sabemos cómo funciona todo esto detrás de escena. Y React ha abstraído toda esta complejidad de los usuarios, que somos tú y yo, a través de estas concurrent APIs. Así que cuando se lanzó la versión 18, que es cuando realmente se introdujo la concurrencia, lanzaron estos dos nuevos hooks, useTransition, useDeferredValue, y luego extendieron suspense para la obtención de datos.

Así que hablaré de cada uno de estos, comenzando con useTransition. Esencialmente, esto nos permite asignar prioridad a una actualización de estado. Así que, tal como mencioné antes, el programador de tareas utiliza una cola de prioridades para determinar qué es importante y qué no lo es. useTransition es lo que nos permite manejar realmente esta prioridad como usuarios, como usuarios finales de React. Así que en el código de la izquierda, es solo un hook normal. Así que devuelve dos valores, una bandera isPending, que es un valor booleano, y luego devuelve un método llamado startTransition. Y si miras dentro de este método handleClick, tenemos este setText, que se considera una tarea de alta prioridad. Tal vez ese no sea el mejor ejemplo, pero solo para compararlo con setTheme, que está envuelto dentro de este método startTransition, y eso se considera de menor prioridad.

Así que cada vez que tienes actualizaciones de estado dentro de startTransition, se considera una actualización de transición que no es tan importante como las otras actualizaciones u otras cosas que necesitan ser renderizadas. También puedes importar directamente este método startTransition. Así que si por alguna razón no quieres usar un hook, o no puedes usar un hook cuando estás en esos componentes específicos, puedes usar el método startTransition, importarlo directamente desde React. Bien, espero que esto funcione.

Oh, okay, I think it's going to keep looping. Pero estas, la siguiente serie de diapositivas son videos de los sitios web del grupo de trabajo de React 18 que extraje. Es básicamente un sitio web que tiene este gráfico, y este, creo que se llama un gráfico de burbujas, y tiene este deslizador en la parte superior, en algún lugar en la parte superior izquierda, donde ves puntuación mínima. No estoy seguro si puedo hacer que esto se reproduzca de nuevo. Tal vez si retrocedo.

Así que si notas, este es un ejemplo de esta transición o esta interacción que ocurre en una computadora rápida que no usa transición o el hook useTransition. Y solo retrocede de nuevo. Así que nota que mientras deslizas, el contenido cambia según el valor en el que está el deslizador. Así que este se ve normal. Pero así es como se ve con un useTransition. Así que de nuevo, nota que las actualizaciones del gráfico de burbujas son mucho, no ocurren tan pronto como deslizas. De nuevo, ayuda al usuario a determinar, bien, ahora estoy en esta puntuación, y esto es como, hay una ligera pausa. Y esto es aún más prominente o más pronunciado en computadoras lentas.

Así que aquí hay otro ejemplo, una computadora lenta que no usa transición. Y nota cuánto retraso hay. Y esto sucede bastante a menudo. Visitas un sitio web que maneja, digamos, muchos datos, y estamos tratando de mover algo o hacer clic en algo, y simplemente se retrasa. Así que voy a retroceder de nuevo. Solo para ver ese retraso. Y sí, incluso hubo, creo, algún fallo allí, pero no es una experiencia de usuario positiva. Creo que todos podemos estar de acuerdo en eso. Y luego aquí está el ejemplo con useTransition en una computadora lenta. Así que para que esto funcione, realmente reducen la velocidad de la CPU, solo para ver la efectividad de esto. Así que lo reproduciré de nuevo. Y ves que el deslizador no está congelado, así que puedo moverme hacia adelante y hacia atrás con bastante facilidad. Y nota esto, como, los gráficos de burbujas se desvanecen ligeramente, lo que indica algún tipo de estado de carga, y están usando la bandera isPending para poder hacer eso. Así que en general, hace que la experiencia del usuario sea más agradable. Reproduce eso una vez más. Mientras deslizamos, podemos deslizar fácilmente, y luego los datos se nos devuelven a demanda. Así que en este caso, las actualizaciones del gráfico se consideran, o han sido envueltas dentro de un método startTransition y se consideran de menor prioridad.

Y el deslizador se considera una actualización de alta prioridad, por lo que React priorizará ese movimiento y luego manejará esta actualización del gráfico de burbujas después. Usa deferred value. Así que esto es bastante similar a useTransition, pero en lugar de asignar prioridad a una actualización de estado lo que podemos hacer con esto es básicamente aplazar las actualizaciones de un valor en la UI. Así que si hay un valor que tengo, y no necesito que se actualice inmediatamente, entonces usaría este hook.

Así que es específicamente para valores que podrían potencialmente afectar mi experiencia de usuario que no son críticos para la interacción del usuario, más bien. Así que aquí, simplemente he definido el hook como de costumbre. Toma el valor que deseas aplazar, y luego te devuelve ese valor. Así que aquí, deferred está simplemente en una etiqueta p, y se considera de menor prioridad que el resto de la página.

Así que aquí hay otro video. Básicamente, creé este simple, solo un campo de entrada, y mientras escribo, esencialmente muestra lo que estoy escribiendo en ese campo de entrada. También he añadido ese punto rojo allí, solo para que puedas indicar cuando realmente estoy escribiendo. Así que nota de nuevo, la cantidad de retraso que hay, y también la lista que muestra este campo de entrada ha sido ralentizada artificialmente. De nuevo, para mostrar cómo funciona esto en la práctica, y luego aquí, estoy usando el hook. Y notas el cambio. Así que he definido el hook allí, y el valor que devuelve el hook, luego lo paso a este componente de lista lenta. Así que nota de nuevo, mientras escribo, no hay retraso. El punto rojo está allí más permanentemente, y luego los datos no se actualizan inmediatamente. Así que de nuevo, los nombres no necesariamente necesitan mostrarse inmediatamente, pero mientras escribo, que es una tarea de alta prioridad, quiero que eso suceda, y quiero retroalimentación inmediata.

Bien, y luego la última característica concurrente de la que voy a hablar hoy es Suspense para la obtención de datos. Así que Suspense ha existido desde React 16, pero en React 18, esencialmente han extendido la funcionalidad de Suspense. Así que típicamente, usaríamos Suspense para cargar un componente de manera diferida, así que si no necesariamente queremos que el componente se renderice cuando no es necesario, usaríamos Suspense para eso. Y ahora, lo que podemos usar Suspense es para básicamente pausar el renderizado de un componente hasta que los datos que requiere hayan sido resueltos. Así que aquí tengo un ejemplo. Esta variable de datos tiene que usar datos asincrónicos, y esencialmente, ese Suspense debería tener un componente dentro, pero el componente solo se renderizaría después de que tenga los datos que el componente está usando. Así que aquí tengo dos ejemplos, obtención de datos antes y después. Tengo este componente ArtistList, y así es como típicamente lo haríamos hoy. Así que tendríamos un useEffect donde llamaríamos a esta API, tendríamos un setIsLoading a true, y luego lo estableceríamos a false una vez que el resultado se haya resuelto. Y luego tengo este loadingArtist para verificar cuando loading es true, y luego simplemente renderizo los datos. Así que a la derecha, estoy haciendo prácticamente lo mismo, pero estoy usando Suspense que ahora puede manejar la obtención de datos. Así que aquí tengo mi componente ArtistList envuelto dentro del Suspense.

Tengo mi fallback, y nota que ya no necesito el useEffect. He definido la función ArtistList al final, y luego nuevamente, los datos que ves definidos allí que son iguales a resourced o re-data son los datos que el componente ArtistList necesita. Y esencialmente, hasta que este componente ArtistList tenga, o hasta que estos datos hayan sido resueltos, entonces el componente está básicamente suspendido. Así que React pausa ese renderizado hasta que los datos estén listos. Y solo una advertencia aquí es que esto actualmente solo funciona si estás usando algún tipo de biblioteca de obtención de datos como React Query, por lo que el mecanismo de obtención de datos necesita ser consciente de Suspense. Así que esto típicamente no funcionaría con solo llamadas fetch regulares sin ninguna biblioteca.

Bien, ahora que eso está hecho, con uno de los ejemplos, básicamente hice una grabación rápida del rendimiento. Así que hice un perfilado aquí, y puedes ver que el de arriba es la versión sincrónica, el de abajo es la versión concurrente. Así que creo que esto fue, usé el ejemplo de useDeferredValue con la escritura de los nombres de los artistas. Si te enfocas en la imagen de arriba, puedes ver esta barra roja y en Chrome eso representa lo que se considera una tarea larga. Y he puesto entre paréntesis allí, si pasas el cursor sobre ella, que tomó 403 milisegundos. Así que nuevamente, ves esto, los fragmentos son mucho más largos en comparación con el de abajo cuando añadí este hook useDeferredValue, y ves que las tareas son mucho, mucho más pequeñas. Así es como React maneja estos eventos o estas tareas en pequeños fragmentos. Oh, y sí, 0.1 milisegundos por tarea, mientras que la otra era de 403 milisegundos por tarea. Así que mucho trabajo práctico que acabamos de ver aquí.

¿Cómo usas esto realmente, o cuándo usas esto para otros? Estos son solo algunos ejemplos, hay muchos más de los que podrías imaginar, pero creo que estos son los ejemplos más comunes que quería resaltar. En primer lugar, manejar entradas de búsqueda en tiempo real. Así que si tienes un campo de búsqueda que renderiza algún tipo de datos cada vez que escribes en él, dependiendo de qué entradas hayas escrito, te devuelve datos. La concurrencia es excelente para eso porque nuevamente, previene el congelamiento de la interfaz de usuario. Y luego cambios fluidos de pestañas o componentes. Así que React tiene un buen ejemplo en su documentación, de hecho, de cómo funciona esto. Si tienes algunas pestañas y estás cambiando entre ellas bastante rápido, y digamos que esas pestañas dependen de datos que vienen de un servidor, el botón o la pestaña en sí, el clic podría congelarse. Así que usarías algo como start transition para establecer esta pestaña como una actualización de baja prioridad. Y luego renderizado de listas grandes. Así que nuevamente, esto es intensivo en recursos. Y finalmente, mostrar animaciones y transiciones, así que cualquier cosa que pueda afectar potencialmente la fluidez de las animaciones o transiciones en una página web.

Inconvenientes. Las cosas importantes. Así que sí, hay algunos inconvenientes con la concurrencia, así que definitivamente tiene algún costo. En primer lugar, puede realmente retrasar las actualizaciones no urgentes. Así que lo que estamos haciendo es establecer actualizaciones específicas para que no sean tan importantes. Así que estamos diciendo despriorizar esto y priorizar otra cosa. Y esto podría tener un efecto adverso en la experiencia del usuario, por supuesto, si no lo estás usando de la manera correcta. Así que especialmente si piensas en un dispositivo lento, por ejemplo, las actualizaciones no urgentes podrían ser mucho más lentas de lo que necesitas que sean. Y luego no necesariamente tiene beneficios para componentes costosos. Así que si un componente es bastante grande y tarda 500 milisegundos en renderizarse, independientemente de si estás usando concurrencia o no, esta cantidad de tiempo es lo que te llevaría renderizar ese componente.

En tercer lugar, puede añadir carga al CPU. Así que piensa en todas las cosas que están sucediendo en segundo plano, toda la sobrecarga que React ha incluido. Así que la cesión al navegador, la programación, la priorización, todo eso. Añade algún tipo de sobrecarga, y si estás usando concurrencia en un dispositivo de gama baja, o, digamos, en una tarea que, por otro lado, en un componente que ya está optimizado, o en como un componente intensivo en CPU, podría realmente tener beneficios insignificantes para ti. Así que es importante sopesar los compromisos de rendimiento cuando se trata de concurrencia.

Y finalmente, creo que requiere no es la palabra correcta aquí, pero es más un... Si te gustaría usar concurrencia dentro de tus aplicaciones, ayuda tener algo de conocimiento de lo que está sucediendo detrás de escena para que puedas depurar mejor. Si hay algún comportamiento extraño ocurriendo, entonces sabes, está bien, esto es por lo que entiendo lo que React está haciendo en segundo plano. Así que solo hay esa curva de aprendizaje para los desarrolladores.

Bien, así que para redondear los puntos clave, la concurrencia significa que React ahora puede gestionar y renderizar múltiples versiones de la UI a la vez. Así que está haciendo todo esto simultáneamente. La concurrencia no está habilitada por defecto, así que realmente tienes que optar por la concurrencia a través de estas características concurrentes que destaqué. Y finalmente, en realidad no hace que tu aplicación sea más rápida, pero la hace sentir más rápida mediante la priorización de eventos importantes del usuario.

Así que, y eso es todo. Muchas gracias por escuchar.

Muy bien. Así que tenemos algunas preguntas que llegaron, y las revisaré. Y una de las primeras es sobre suspense y pregunta, ¿deberíamos usar suspense en componentes a nivel de padres o hijos, creo? Bien. Esa es una buena pregunta. Creo que cuando se trata de, si estás, están preguntando específicamente sobre suspense para la obtención de datos, si consideras cualquier aplicación que, así que creo que los beneficios de suspense es que te permite dividir esta lógica de obtención de datos de la aplicación que realmente la utiliza. Así que puedes tener tu lógica en otro componente que está envuelto en suspense y luego tener este componente hijo donde solo estás renderizando la interfaz de usuario o los datos que se reciben. Así que diría que lo uses en los padres y luego en el hijo, solo renderizas los datos que se devuelven.

Genial. Gracias. Y por cierto, solo quiero recordarles a todos también, por favor escaneen el código QR también y den su calificación. Pueden calificar la charla de cinco estrellas. Y tenemos algunas preguntas más llegando. Y esta es sobre cuáles son los beneficios de usar transiciones sobre alguna forma de como un de-balance también? Sí, esa es una buena pregunta. Definitivamente algo que los usuarios consideran. Así que creo que use deferred, use transition o use deferred value. Esos hooks están muy enfocados en la capacidad de respuesta de la interfaz de usuario, ¿verdad? Mientras que algo como de-balance tiene, creo que diría un alcance más amplio donde puedes controlar las llamadas a funciones. Así que si tienes un caso de uso donde la capacidad de respuesta o la interactividad tiene algún tipo de problema de rendimiento, entonces diría que uses deferred value o use transition. Pero si es, supongo, más amplio que eso, y estás tratando de, limitar la cantidad de veces que se llama a una cierta función dentro de tu componente, entonces de-balance funciona mejor para eso. Así que esos hooks están muy enfocados en la capacidad de respuesta de la interfaz de usuario y asegurando que haya una interacción fluida entre el usuario y la aplicación.

Me encanta eso. Y también la especie de distinción entre algo que tal vez está siendo rendimiento en un segundo plano y algo que se siente rendimiento para el usuario y usar la herramienta correcta para obtener uno de esos. La siguiente pregunta, porque siempre pensamos en las pruebas y asegurarnos de que podemos probar nuestro código, ¿cómo afecta esto a la capacidad de prueba? ¿O hay algunas formas en que podemos probar o implementar pruebas en este tipo de cosas? Buena pregunta. Creo que sí. Me centré en este perfilado de rendimiento cuando se trataba de probar la efectividad real de estos hooks. Así que eso es algo que podrías hacer, medir o perfilar lo que estaba sucediendo antes y lo que está sucediendo ahora. Pero creo que no diría que hay diferencias significativas cuando se trata de pruebas. Creo que es más poder identificar si estos antes de sumergirse en el uso de estos hooks, poder identificar si los, supongo, los resultados o lo que te gustaría lograr es lo suficientemente significativo. Porque a veces si hay un uso excesivo de estas características, podría tener un impacto negativo en la aplicación. Genial. Muchas gracias.

Como pueden ver, hay más preguntas, pero no tenemos tiempo para preguntas, desafortunadamente, pero pueden encontrarla en el Q&A de los ponentes. Y también, ¿dónde puede la gente encontrarte en línea? LinkedIn, Dara Olaibi, Twitter, Dara Olaibi, Instagram, Dara Olaibi. Genial. Gracias. ¿Podemos dar un aplauso de cinco sobre cinco para Dara una vez más? Gracias.