Concurrencia en React, Explicada

¡1,489 días! Este es el tiempo que pasó entre la primera revisión de Dan Mobromov de lo que en aquel entonces se llamaba Time Slicing y el lanzamiento de Direct18 que finalmente hizo estas capacidades disponibles para todos. En estos 1,489 días, Time Slicing pasó por un montón de cambios de marca, varios cambios de API, y hoy se conoce como concurrent rendering.

Ahora, concurrent rendering generalmente incluye dos características. Hooks como useTransition y useDefaultValue y mejoras en suspense e hidratación. También hay una tercera performance característica que Direct18 lanzó, mejor agrupación de actualizaciones, pero no es parte de concurrency.

Así que cuando primero intenté trabajar con estas concurrent características, especialmente con cosas como useTransition, a veces realmente se sentía como magia en términos de cómo optimiza la aplicación. Así que hoy, quiero mostrarles a ustedes lo que realmente sucede en la aplicación cada vez que usas la primera, la característica de rendimiento más fundamental, useTransition, y cómo Rack logra esta magia, que en realidad no es magia en absoluto. Así que vamos a sumergirnos en useTransition, useDefaultValue hooks, y para mostrarlos, déjame mostrarte una aplicación lenta.

Entonces, esta es una aplicación básica de toma de notas. ¡Vaya! ¡Espera! ¡Oh, no! Yo—Yo, espera. Lo siento. Yo— Esto. Sí. ¡Ah! Sí, hemos vuelto. Entonces, esta es una aplicación básica de toma de notas, y tiene una lista de nodos que puedes filtrar. Y si intentas filtrar estos nodos, la aplicación se ralentizará. Puedes notarlo si miras este cubo de hielo que gira. Es un spinner que se congela cuando la aplicación se congela, cuando la página se congela, y, bueno, gira cuando no está congelado, algo así como lo opuesto al hielo.

Si intento escribir, si intento filtrar nodos, si intento escribir la letra F, por ejemplo, puedes notar cómo el spinner se congela durante un segundo o dos. Si intento escribir más, podrías ver cómo la aplicación simplemente se retrasa mientras estoy escribiendo. Entonces realmente no puedes sentirlo, porque estoy escribiendo detrás del teclado. Pero podrías ver cómo estoy escribiendo, y la aplicación se siente realmente, realmente lenta. Las actualizaciones de la UI, ocurren con retraso, y la aplicación simplemente se congela durante un segundo o dos.

Entonces, ahora, cada vez que tengo un problema de performance, lo que me gusta hacer es abrir DevTools Profiler, DevTools Performance, e intentar grabar lo que está sucediendo en la aplicación con el panel de performance. Entonces, en este caso, si hago clic en grabar, e intento escribir, y detengo la grabación, veré que lo que está sucediendo en la aplicación es que tengo este enorme pico de actividad de la CPU de 500ms, y si amplío ese pico de actividad de la CPU, veré que tengo un solo evento keydown que tarda 550ms en procesarse, y debajo de ese evento, hay un montón de llamadas a funciones de React.

Entonces, ahora, si intentara debug esto un poco más a fondo e intentara averiguar qué está pasando, vería esto. Entonces, aquí está lo que sucede en la aplicación. Lo que sucede es que estoy escribiendo en el campo de texto, los inputs de filtro, eso llama a esta función set filter que es solo un hook useState, que, a su vez, cambia el estado en un montón de componentes, y eso hace que React renderice todos estos componentes uno por uno hasta que termine. Y como tenemos muchos componentes, muchos botones de nodos, eso lleva un tiempo. Entonces, este re-renderizado es una operación de detener el mundo. Nada puede suceder hasta que React termine. Si un usuario intenta interactuar con la aplicación de cualquier manera, tendrá que esperar hasta que el re-renderizado termine. Si el re-renderizado de la aplicación tarda dos segundos, el usuario tendrá que esperar dos segundos. Así es como funciona React 17, React 16, incluso React 18 funciona de serie. Un comportamiento de bloqueo de JavaScript bastante estándar.

Ahora, retrocedamos un paso. Tenemos un problema de performance, ¿verdad? Estoy escribiendo en el campo de texto, y ese campo de texto va a una lista de nodos para re-renderizar, y este re-renderizado es bloqueante y costoso, lo que ralentiza la aplicación y ralentiza todo el proceso de escritura. Entonces, mi pregunta para ustedes, si fueran los desarrolladores de esta aplicación, y esta aplicación estuviera usando React 17, ¿cómo intentarían resolver esto? Hay múltiples soluciones aquí, ¿qué intentarían? ¿Perdón? De-balanceo.

Desbalanceo, throttling, sí. Oh, es realmente difícil escuchar desde aquí. DLS virtualizado, sí, otra gran solución. ¿Alguna otra idea? Bien, entonces sí, hay varias cosas que podríamos intentar aquí. Podríamos intentar usar React Memo si los componentes se renderizan innecesariamente. Podríamos intentar optimizar los componentes en sí, tal vez los componentes son costosos por alguna razón, podríamos intentar virtualizar la lista para renderizar solo los elementos que son visibles en la pantalla, podríamos intentar desbalancear o hacer throttling, y todas estas son excelentes soluciones e incluso puedes combinarlas, pero lo que React 18 hace es que introduce otra solución a la mezcla, haciendo que las actualizaciones no sean urgentes.

¿Qué significa esto? Entonces, con React 17 y versiones anteriores, cada actualización que ocurre en la aplicación se considera urgente. Si haces clic en un botón, React tiene que manejar esa actualización inmediatamente. Si escribes en el input de filtro, React tiene que renderizar la lista de nodos inmediatamente. Con React 18, tu actualización ahora puede tener una prioridad. Cada actualización que haces en la aplicación todavía es por defecto urgente, pero lo que React ahora también soporta son actualizaciones no urgentes, y las actualizaciones no urgentes casi mágicamente no bloquean la aplicación sin importar cuánto tiempo tomen. Veamos cómo funciona esto. Tengan paciencia conmigo. Perdí mi ratón. Aquí está mi ratón. Oh no, sí.

Entonces, volvamos al code. Volvamos al ratón principal. Es un poco confuso, si pongo mi ratón aquí, o como esta demostración, también se duplica allí, así que nunca sé dónde está el ratón. De todos modos, entonces, miremos el code. Este es el code de la aplicación que tenemos aquí. Este es el code de este componente de la lista de nodos que tenemos a la izquierda. En el componente de la lista de nodos, tenemos los inputs de filtro, y tenemos la lista de botones. Así que aquí está el input de filtro que tenemos en la UI de la aplicación, y aquí está la lista de botones. Toda esta UI está controlada por el único campo de estado de filtro. Cada vez que escribo en el campo, este campo de filtro se actualiza, y la UI se vuelve a ingresar. Ahora, esta actualización, por defecto, se considera urgente. Para hacer una actualización no urgente, lo que necesito hacer es usar una de las tres nuevas APIs de rendimiento de React, React start transition, React use transition hook, o React use the first value hook. Todas son bastante similares. Hacen más o menos lo mismo.

Entonces, me voy a centrar solo en el segundo, use transition. Y esto es lo que voy a hacer. Primero, voy a ir a la parte superior e importar el hook use transition de React. Segundo, voy a llamar a este hook use transition en el código, y el hook use transition devuelve dos valores. No, GitHub copilot, estás equivocado. Devuelve el indicador is pending, que indica que la transición está en curso, y devuelve la función, start transition, que te permite marcar algunas actualizaciones como no urgentes. Luego, el tercer cambio que voy a hacer es, y ten paciencia conmigo, voy a tomar este pedazo de estado, y lo voy a dividir en dos partes de estado. Oh, no, botones equivocados. Si miras este filtro, notarás que controla dos partes de la UI, ¿verdad? Controla el filtro que tenemos aquí, y controla la lista de nodos que tenemos aquí. Así que lo que pasa con este pedazo de estado es que ... O lo que pasa con esta UI es que una parte de esta UI es una parte de la UI que queremos actualizar inmediatamente, con urgencia. Es el filtro de entrada. Como cuando el usuario está escribiendo en el filtro, queremos reflejar el cambio inmediatamente, queremos actualizarlo inmediatamente. Pero la lista de nodos puede ser filtrada con un retraso. Puede ser actualizada de forma no urgente. Así que lo que voy a hacer es que voy a tomar este pedazo de estado y lo voy a dividir en dos partes de estado. Una que se va a actualizar con urgencia, y otra que se va a actualizar de forma no urgente. Entonces voy a clonar el use state y llamar al primero ... Llamémoslo setFilter. Lo siento, llamémoslo filterInput y setFilterInput, porque va a controlar el input. Y el segundo va a controlar la lista de nodos, así que tal vez lo llame filterValue y setFilterValue. Ahora voy a tomar este estado de filter input y lo voy a pasar aquí, y voy a tomar este estado de filter value y lo voy a pasar más abajo en el código. Oh no, espera, esto, esto, esto. Oh sí, y el de arriba. Pega aquí, pega aquí. Hecho. Y ahora también necesito actualizar estos estados, ¿verdad? Así que antes tenía, tenía como un hook de set state. Ahora voy a tener dos, así que solo voy a valorar, okay, eso fue, eso fue un spoiler de GitHub quality. SetFilterValue. Valor, sí.

Entonces, y el corchete de cierre. Así que lo que hicimos aquí hasta ahora es que, hicimos, como, prácticamente nada. Como, el único cambio que hicimos hasta ahora es que tomamos este bit de estado y lo dividimos en dos bits de estado. Y eso es bastante, bueno, no tiene, no tiene sentido todavía.

Entonces, si intento escribir en el filtro, notarás que, como, todavía, todavía es lento. Todavía se está retrasando, ¿verdad? Estoy presionando F y el IceCube se retrasa, como que las cosas giran durante un segundo. Pero eso es porque ambas actualizaciones de estado siguen siendo urgentes.

Así que lo que voy a hacer ahora es que voy a hacer un último cambio. Voy a tomar mi hook setFilterValue y voy a marcarlo, la llamada setFilterValue, y voy a marcarla como no urgente. Y voy a hacer esto envolviéndola con StartTransition. Y entonces, mira, el único cambio que hice, envolví el estado del filtro con StartTransition. Y ahora si intento escribir en el filtro, notarás que la lista de nodos todavía se actualiza, pero la aplicación no se congela en absoluto, los cubitos de hielo siguen girando ininterrumpidamente todo el tiempo. Es batterithmost.

Puedo escribir todo lo que quiera y se actualiza perfectamente. Entonces, es como magia. Es genial. ¿Alguien podría adivinar cómo funciona esto? ¿Cómo hace React esto, sabes o estás adivinando? ¿Promesa? ¿No? Tal vez en esa dirección. Adelante. Diría que simplemente lo encola y cuando está libre hace algo y luego gira de nuevo. ¿Pero notaste que los cubitos de hielo siguieron girando todo el tiempo? Cuando haces algo, cuando haces clic en algo de inmediato, así que cuando React atenúa, es capaz de hacerlo, ejecutará esa fase de code. Más o menos sí, pero... Es solo una suposición. Sí, sí, está bien, sí. ¿Alguna otra idea? Lamento por los oyentes en vivo, esta es probablemente la parte aburrida. Adelante, sí. ¿Está sentado? ¿Sentado? Es una parte, pero no. Entonces, la forma en que esto funciona es... Lo siento, diapositiva equivocada. La forma en que esto funciona es devolviendo el control. Entonces, lo que hace React es comenzar a renderizar la aplicación, y luego devuelve el control al navegador después de cada fotograma. Veamos cómo se ve esto en DevTools. Entonces, en DevTools, este era el comportamiento antiguo, ¿verdad? Presioné el botón del teclado, y el hilo principal estuvo bloqueado durante 500 milisegundos. React comenzó a renderizar y React siguió renderizando durante 500 milisegundos. Entonces, lo que React va a hacer ahora, o lo que React está haciendo ahora es si escribo una sola letra, y luego dejo de grabar, y veo qué pasa, todavía notaría un solo pico de la actividad de la CPU, ¿verdad, en la parte superior? Pero si hago zoom en ese pico, veré que mi tecla percibida cuando eso sucedió cuando escribí la letra F, ahora solo toma 15 milisegundos, y aquí React realiza la actualización Argent de inmediato, sin importar cuándo sucede el clic, porque todas las actualizaciones no Argent normalmente estarán bloqueando el hilo principal solo durante cinco o 10 milisegundos. Así es como funciona el renderizado concurrente de React 18 y así es como funciona bajo el capó. Ahora, hablemos de las desventajas porque, por supuesto, no hay almuerzo gratis. La primera desventaja es que las actualizaciones no Argent tardan más. React tiene que ceder el control al navegador todo el tiempo y eso introduce algunos retrasos. Entonces, si vuelvo al navegador, no voy a reproducir eso ahora, pero simplemente tomé esta aplicación e hice la grabación con start transition y sin start transition. Entonces, en el caso sin start transition, cuando estaba grabándolo hace una hora, este evento de presión de tecla tardó 473 milisegundos en renderizar, y bloqueó el hilo principal todo el tiempo. Cuando agregué start transition, los hilos principales dejaron de estar bloqueados, pero toda la actualización, como renderizar todos los componentes, tardó más. Lo tomó, ¿puedes verlo? 582 milisegundos.

Entonces, 100 milisegundos más. Así que este sobrecoste, no es constante, depende de cuántos componentes estás renderizando, no lo sé, etc. No es como si fuera 100 milisegundos más largo cada vez, o un 20% más largo, pero lo que ves aquí es porque Rect tiene que devolver el control al navegador cada vez, la totalidad de la actualización termina más tarde. Quizás eso está bien porque se marca como no urgente, pero es una desventaja a tener en cuenta.

La segunda desventaja es que esta complejidad extra no es gratuita. Para hacer posible el concurrent rendering, Rect tuvo que hacer su architecture mucho más compleja. Introdujo RectFiber, que por cierto, la próxima charla en ese escenario va a hablar sobre ello. Ve a verlo. Introdujo las comprobaciones de concurrent rendering. Todo esto tiene un costo en la CPU, y de hecho esta es una de las razones por las que Vue y Preact se niegan rotundamente a implementar algo similar al concurrent rendering. Tanto Vue como Preact creen que es poco probable que las aplicaciones del mundo real se beneficien de las características concurrent. Como Marvin de Preact, por ejemplo, dice, todavía está en el aire si el modo concurrent es algo que beneficiará a las aplicaciones en absoluto, incluso para React. O Evan de Vue dice, la demostración del equipo de Rect, es tan forzada que es muy probable que nunca ocurra en la aplicación real. Y estoy mostrando capturas de pantalla de 2019 y 2020, pero basado en las conversaciones de Twitter, nada ha cambiado desde entonces.

Ahora, el equipo de React, sin embargo, parece jugar a largo plazo y es explícito al respecto. No estoy seguro de si todavía está en Twitter porque ahí es donde vive toda la documentation real hoy en día pero Dan, por ejemplo, en este tweet dice, esto desbloquea muchas habilidades que no eran posibles. El time slicing es solo un bonito bonus. Y una de las cosas que las características concurrent desbloquearán es la próxima API fuera de pantalla que permite renderizar partes invisibles de la UI en segundo plano, y requiere concurrent rendering para funcionar, para no bloquear el renderizado cuando está renderizando, renderizando, renderizando. De todos modos, hay otra desventaja / trampa. La concurrency de React no ayuda a optimizar los componentes costosos. Si miras de nuevo el bucle principal de renderizado de React, notarás que should yield al host es esta función que comprueba si React tiene que devolver el control al navegador, sólo se llama después de cada renderizado, ¿verdad? Así que como la función performing unit of work, toma un componente. Comienza a renderizarlo. Y luego sólo una vez que ese renderizado está completo, should yield to host comprueba si React debería devolver el control al navegador. Así que si cualquier componente individual tarda, por ejemplo, no cinco sino 500 milisegundos en renderizar, el hilo principal seguirá estando bloqueado durante los 500 milisegundos completos, incluso a pesar de que esta actualización esté marcada como no urgente. Y esta es la tercera desventaja de la concurrency de React. Desventaja / trampa. Así que para resumir, la concurrency de React es más lenta para las actualizaciones no urgentes. Es más costosa en términos de CPU para todas las actualizaciones. No ayuda con los componentes costosos, pero si estás dispuesto a lidiar con todas estas desventajas y trampas, obtendrás este comportamiento casi mágico de renderizar algo enorme y no ralentizar la página en absoluto. ¿Es esto un meme? Quizás esto es un meme.

Gracias. Bueno, tenemos algunas preguntas. Sí. Primero, ¿cómo puedo saber o juzgar que necesito usar useTransition? ¿Cuáles son algunas señales o signos que debería buscar? Buena pregunta. Aún no tengo una intuición clara al respecto. Pero voy a intentar responder. Si tu aplicación es lenta, y si ves que es como si intentaras ejecutar un rectProfiler y ves que no es porque haya algún componente costoso individual, sino un montón de pequeños, que es básicamente cómo sucede típicamente. Y sabes que puedes retrasar algunas partes de la UI, entonces lo usarías o en realidad una mejor transición. Así que si estás pensando en usar throttling, o bouncing, prueba primero startTransition, porque funciona prácticamente de la misma manera pero es mejor porque no retrasa nada. No retrasa la renderización ni un segundo ni dos segundos. Genial.

Gracias. ¿Por qué las actualizaciones dan resultados incompletos inesperados al escribir pruebas? ¿Existe un escenario aquí cuando estás realizando pruebas automatizadas y esperas que algo suceda en pantalla, tal vez en un tick? No he... Sí, no lo sé. Supongo que las buenas pruebas, normalmente esperan que un elemento aparezca en pantalla. Eso no va a afectar estas pruebas. Sí, si hay pruebas que usan el temporizador, entonces supongo que eso podría afectarlas un poco. Sí, eso es cierto.

Espera. La siguiente. Veamos. Demasiadas preguntas. ¿Cómo se cancelan las actualizaciones obsoletas? Entonces, si tienes múltiples... OK, sí. Esa es una gran pregunta. Entonces React simplemente las cancela. No recuerdo la mecánica exacta. Pero si escribo F y React comienza a renderizar esta enorme lista de notas, y luego 100 milisegundos después escribo otra letra, entonces React simplemente descartará el primer renderizado que ha estado en progreso. Comenzará a renderizar el segundo renderizado. Así que es inteligente, es bueno en eso, simplemente detiene el trabajo tan pronto como puede. Genial.

¿Cómo puedes beneficiarte de estas APIs si tu actualización no urgente ocurre en una biblioteca, como React Query, por ejemplo? ¿Perdón? ¿Cómo puedes usar estas APIs si la... ¿Actualización urgente ocurre? En, como, una biblioteca, en React Query, por ejemplo. Esa es una buena pregunta. Entonces, no lo sé. La próxima API que necesitas envolver como cualquier función que tengas que cambia el estado, necesitas envolverla con startTransition. No tiene que ser exactamente este callback de estado, podría ser 10 capas de funciones intermedias. Pero si React Query... No he usado React Query. Entonces, si React Query te da algún callback que cambia el estado, que podrías envolver con eso, entonces eso es bueno. Si establece el estado internamente, entonces no.

También echa un vistazo al useDeferredWidgetHook, porque es una API diferente, y si no puedes hacer la transición, tal vez useDeferredValue te pueda ayudar. Sí. ¿Conoces alguna biblioteca que esté implementando esto internamente? Por ejemplo, ¿existen banderas para React Query que podrías instruir a React Query para hacer lo correcto automáticamente para ciertos conjuntos de data? Realmente no lo sé, y creo que la razón de esto es buena, la biblioteca no sabe qué partes de la UI son urgentes o no urgentes. Depende de ti, del desarrollador de la aplicación. Cierto.

Vale. Entonces, ¿qué sucede si llega una actualización urgente mientras las actualizaciones no urgentes aún están en la cola? También genial, sí. Entonces se detendrá una actualización urgente. React ejecutará la actualización urgente de inmediato. Y luego, en realidad, no estoy seguro, creo que, así que, no me cites en esto, pero, mi entendimiento es, si la actualización urgente cambia el estado no urgente, entonces React comenzará a renderizar el estado no urgente desde cero. Si afecta a alguna otra parte de la UI, entonces React simplemente continuará donde lo dejó. Creo, no me cites en esto, pero creo que así es como funciona. Genial. Gracias. Voy a ir y twittearlo de inmediato. Tú dijiste esto. OK.

Creo que todas las demás preguntas aquí ya están prácticamente respondidas. Así que creo que eso es todo. Muchas gracias. Gracias por tenerme. Sí, disfruta de tu día y nos vemos más tarde.