React Concurrente Hecho Fácil

Hola a todos. Mi nombre es Henrique Núñez. Soy desarrollador de software en Codeminer 42, y hoy hablaré sobre React concurrente. Así que ven conmigo.

Así que comenzaremos dirigiendo nuestra atención a las interfaces de usuario y las interacciones con ellas. Siempre que los usuarios interactúan con la UI, esta se actualiza en respuesta a estas interacciones, y estas actualizaciones se pueden dividir en dos categorías, actualizaciones rápidas y actualizaciones lentas, en términos de cuánto tiempo lleva procesarlas. Por ejemplo, actualizar campos de entrada, botones, interruptores y deslizadores. Cuando consideramos estas actualizaciones de forma aislada, son muy rápidas. Por otro lado, filtrar una lista enorme, actualizar un panel de control, recalcular celdas en una hoja de cálculo o realizar navegaciones generalmente lleva un tiempo razonable para completarse y, por lo tanto, se pueden considerar lentas, especialmente en comparación con las actualizaciones rápidas.

Ahora, veamos esto en la práctica. Primero, tenemos una demostración donde mostramos algunos ejemplos de actualizaciones rápidas. Observa que hacemos clic en el fondo, escribimos en la entrada de texto, arrastramos el deslizador y las actualizaciones en respuesta a nuestras interacciones se procesan al instante. No hay retraso. Además, también tenemos dos tipos diferentes de animaciones en esta demostración. Una animación JS y una animación CSS que aunque no son una respuesta directa a ninguna interacción nuestra, también se están actualizando.

Ahora, esta es una parte de un perfil que se tomó de esta demostración. Observa que en la sección de interacción podemos ver nuestro clic y debajo de eso en la sección principal del hilo podemos verificar que procesar la actualización correspondiente fue de hecho muy rápido, menos de 2 milisegundos. En la segunda demostración, tenemos un botón que desencadena un cálculo pesado, es decir, es una actualización que lleva mucho tiempo procesarse. En este caso, es un ejemplo artificial que servirá para explicar algunas cosas que vendrán a continuación, pero podría ser cualquier otro ejemplo del que hablamos anteriormente como filtrar una lista enorme, así que ten paciencia conmigo por ahora. Este es el perfil correspondiente de la segunda demostración. Observa que esta actualización tarda 2 segundos, que es mucho tiempo para una actualización de UI, especialmente considerando que bloquea el hilo principal. Esta tercera demostración es prácticamente la anterior, pero no. Observa que tenemos control programático sobre cuánto tiempo lleva este cálculo pesado, ya que el primer botón inicia el cálculo y el segundo botón lo finaliza. Es importante dejar claro que aunque en este caso podemos controlar cuánto tiempo llevará el cálculo, funciona prácticamente como la demostración anterior. Y como podemos ver en este perfil, este cálculo todavía bloquea el hilo principal. Ahora, quiero mostrarte qué sucede cuando tenemos una situación en la que coexisten actualizaciones rápidas y lentas. Esta demostración es una combinación de las anteriores, donde tenemos tanto actualizaciones rápidas como lentas como ejemplos. En esta demostración, cuando comenzamos a procesar esta actualización lenta, toda la UI se congela, y todas las actualizaciones rápidas solo pueden procesarse después de que la actualización lenta haya terminado. Los clics en el fondo, el texto que se escribió en la entrada de texto, las interacciones con el deslizador, solo se procesan después de que se haya realizado el cálculo pesado. Lo único que sigue actualizándose a pesar de bloquear el hilo principal es la animación CSS, y solo porque se realiza en la GPU.

Pero todo lo demás que depende del hilo principal para ser procesado se congela completamente. Y el punto clave aquí es el siguiente. Solo se necesita una única actualización lenta para ralentizar toda tu interfaz de usuario. No importa cuán bien diseñada esté tu interfaz de usuario, cuán optimizados estén todos tus componentes, porque tu interfaz de usuario siempre está a una sola actualización lenta de una mala user experience. Y este es el principal desafío al que nos enfrentamos aquí. Este es el problema que estamos dispuestos a resolver. Como puedes ver, en nuestra configuración actual, tanto las actualizaciones rápidas como las lentas están acopladas entre sí en el sentido de que las actualizaciones lentas terminan bloqueando las rápidas. Ahora, la razón por la que esto sucede es porque el enfoque predeterminado que React utiliza para la representación en la mayoría de las situaciones, que también, para muchos marcos de interfaz de usuario frameworks, es el único enfoque disponible, es representar las cosas de manera sincrónica. Con la representación sincrónica, una vez que React comienza a representar una actualización, se ejecutará hasta su finalización, bloqueando completamente el hilo principal hasta que se termine la representación. Entonces, en la práctica, esto significa que no importa cuánto tiempo tome completar la representación, cualquier interacción del usuario que ocurra durante la representación tendrá que esperarla, independientemente de cuán rápida o urgente sea la respuesta a ellas. Volviendo a las actualizaciones rápidas y lentas, ahora, ¿qué pasaría si pudiéramos desacoplarlas? ¿Qué pasaría si hubiera una forma de permitir que cada actualización se procese a su propio ritmo? Ingrese a react concurrente. Ahora, quiero que presten mucha atención a esta próxima demostración aquí porque esta es la misma demostración que vimos antes, pero ahora hay un giro. En lugar de usar la representación sincrónica, estamos usando concurrent rendering. Observa que ahora, aunque estás procesando la misma actualización lenta que antes, ya no bloquea las actualizaciones rápidas. Mientras la computación pesada aún se está ejecutando, ahora podemos interactuar con otras partes de la interfaz de usuario y siguen siendo responsivas. Echemos un vistazo al perfil de esta demostración. Lo que vemos aquí es la tarea pesada siendo procesada. Pero ahora, en lugar de bloquear el hilo principal, se divide en fragmentos más pequeños y esta división en fragmentos más pequeños nos permite ajustar otro trabajo entre estos fragmentos. Ahora, en adelante, les mostraré dos demostraciones más ejecutándose con representación sincrónica y concurrente para que podamos hacer algunas comparaciones más. En esta primera demostración, tenemos un ejemplo de una navegación donde navegar a diferentes páginas haciendo clic en la barra lateral lleva mucho tiempo. Cuando se utiliza la representación sincrónica, la navegación bloquea otras interacciones de ser procesadas. Entonces, no solo tenemos que esperar antes de navegar a una página diferente, sino que también la barra lateral el efecto de desplazamiento de la barra lateral no funciona. Cuando se utiliza concurrent rendering ahora, que es lo que estamos haciendo en el mismo ejemplo, pero ahora con concurrent rendering, aunque la navegación todavía tarda un poco en procesarse, la barra lateral se mantiene completamente funcional. E incluso si cambiamos de opinión a mitad de una navegación, que es algo bastante común para los usuarios hacer, ¿verdad?, y queremos navegar a una página diferente en su lugar, podemos hacerlo fácilmente sin tener que esperar a que se completen las navegaciones anteriores, porque concurrente React abortará las representaciones en uso anteriores. En la segunda demostración tenemos el clásico ejemplo de filtrado de una lista enorme. Y, por supuesto, como la lista tiene varios elementos, volver a representarla es lento. Entonces, cuando escribimos, obtenemos este jank, ya sabes, donde la barra de búsqueda se congela brevemente. Ahora, en la segunda versión con concurrent rendering, la barra de búsqueda se mantiene completamente responsiva mientras se está representando la lista. Lo cual, creo que todos van a estar de acuerdo, se traduce en una mucho mejor user experience. Ahora, podrías estar preguntándote, como, ¿cómo funciona todo esto, verdad? Y llegaremos a eso ahora mismo.

Concurrent React mejora la representación con dos nuevas características, a saber, la interrupción y la priorización. La interrupción se trata de poder detener una representación a mitad de camino para hacer otras cosas y luego reanudarla más tarde. La priorización se trata de representar las cosas más urgentes primero. Ahora, al combinar ambos, somos capaces de comenzar a representar una actualización, digamos, la computación de la demostración. Y luego, si otra actualización más urgente está sesgada, no sé, como, interactuando con el fondo con una entrada de texto, podemos interrumpir lo que estamos haciendo, atender estas representaciones más urgentes y, una vez que hemos terminado, volvemos a lo que estábamos haciendo antes. Y esto es esencialmente lo que mantiene la interfaz de usuario receptiva.

Para lograr eso, React nos permite marcar las representaciones como de Alta Prioridad o Baja Prioridad. Sin embargo, una rápida pero importante aclaración. En realidad, en la realidad, tenemos más de dos niveles de prioridad. Pero para la mayoría de los propósitos en la interfaz de usuario, colapsarlos en dos niveles es suficiente. Que es exactamente lo que vamos a hacer. Sólo vamos a hablar de dos niveles de prioridad en esta masterclass.

Continuando, las representaciones de Alta Prioridad son solo las representaciones normales a las que estamos acostumbrados antes de React18. Por lo tanto, son sincrónicas, bloquean el hilo principal, lo que significa que no pueden ser interrumpidas. Y también interrumpen las representaciones de Baja Prioridad, que es lo que vamos a ver a continuación.

Las representaciones de Baja Prioridad, por otro lado, son interrumpibles, lo que significa que ya no bloquean el hilo principal. Y esto también es importante. Sólo comienzan a ejecutarse después de que todas las representaciones de Alta Prioridad han sido atendidas, ¿sabes? Así que, esto es lo que las hace funcionar con esa idea de representación en segundo plano, por así decirlo.

Creo que una forma interesante de entender esto es usando la siguiente analogía. Digamos que estamos desarrollando una aplicación y estamos usando Git para rastrear su base de código. Creo que todo el mundo está acostumbrado a hacer eso hoy en día, ¿verdad? Así que, hay una rama principal que representa el código que está en producción. Y cuando queremos escribir una nueva característica, creamos una rama de características de la principal, como, no sé, característica / característica impresionante, y cuando terminamos de trabajar en ella, la fusionamos de nuevo a la principal. Bastante sencillo. Ahora, cuando hay algún problema crítico en producción, creamos un hotfix de la principal, como, hotfix / arreglar bug desagradable, y cuando terminamos con él, también lo fusionamos a la principal. Esto también es bastante estándar.

Ahora, ¿qué pasa cuando estamos trabajando en alguna característica y de repente, tenemos que enviar un hotfix? Esta no es una situación poco común, ¿verdad? Creo que todo el mundo ya ha pasado por este tipo de cosas. Así que, enviar el hotfix es definitivamente más urgente que entregar las características. Suponiendo que somos responsables de enviar el hotfix, primero tenemos que interrumpir nuestro trabajo en la característica y empezar a trabajar en el hotfix hasta que lo completamos y lo fusionamos. Sólo después de hacer eso, es sólo después de enviar el hotfix, es que podemos volver a trabajar en la característica.

Ahora, si has estado prestando atención, probablemente te habrás dado cuenta de que las características son similares a las actualizaciones de baja prioridad, ya que trabajar en la rama de características, que es análogo a la representación de baja prioridad, puede ser interrumpido en cualquier momento por la necesidad de enviar un hotfix, que a su vez se equipara a las actualizaciones de alta prioridad. Con todo eso en mente, el truco para desacoplar las actualizaciones rápidas de las lentas es básicamente asignar una alta prioridad a las actualizaciones rápidas y una baja prioridad a las lentas actualizaciones, porque de esta manera podemos mantener la aplicación receptiva evitando que las actualizaciones lentas bloqueen las rápidas. A las actualizaciones lentas, al ser asignadas una baja prioridad, se ocuparán en el fondo y pueden ser interrumpidas cuando necesitemos atender las actualizaciones rápidas.

Ahora que entendemos el problema que estamos resolviendo, la solución en sí y cómo funciona, creo que es hora de echar un vistazo a cómo podemos realmente hacer uso de concurrent rendering en la práctica. En React Concurrente, para asignar prioridades a las actualizaciones, utilizamos características concurrentes. Así que volvamos a algunos de los ejemplos anteriores que vimos antes y veamos cómo están realmente implementados usando características concurrentes.

Volviendo al ejemplo de navegación, sin usar ninguna característica concurrente, cada actualización es de alta prioridad. Así que como podemos ver en este primer ejemplo, porque estamos usando un antiguo USETAPE para rastrear la página seleccionada actualmente, las representaciones que se activan al navegar a una página diferente son sincrónicas, y por lo tanto, son bloqueantes. Una vez más, observa que la navegación bloquea las interacciones con la barra lateral.

Ahora, cuando usamos características concurrentes en esta próxima versión, en este caso estamos usando start transition, podemos hacer que las navegaciones sean una actualización de baja prioridad, de modo que ya no bloqueen la actualización de la barra lateral, al mismo tiempo que podemos mostrar un estado de carga con el indicador isPending, por eso ves que la pantalla se oscurece, ya sabes, con este tipo de capa grisácea. Y, en esta versión, hemos añadido un nuevo estado, delayedPage, y vamos a usar ese estado para activar la actualización de baja prioridad, lo que significa que en realidad vamos a usar esta actualización para volver a representar la página en sí. Y luego, al usar el hook useTransition, tenemos acceso primero al indicador isPending, que nos dice cuándo hay una representación de baja prioridad pendiente, y también a la función startTransition que nos permite marcar una actualización de estado como de baja prioridad, de modo que su correspondiente representación, es decir, la representación que se activa con esta actualización, será una representación de baja prioridad, y por lo tanto, no bloqueante.

En este segundo ejemplo, una vez más, estamos filtrando una lista enorme, que, debido al número de componentes que tiene que representar, es bastante lenta, y sin usar ninguna característica concurrente, la representación de la lista filtrada bloquea las actualizaciones de la barra de búsqueda, que es justo lo que vimos antes, ¿verdad? Por eso parece que se congela. Ahora, en la segunda versión, al usar el hook Use Deferred Value, y pasando el filtro diferido que obtenemos del hook a la lista de filtros en su lugar, estamos marcando sus representaciones como de baja prioridad, y ahora ceden a las actualizaciones de alta prioridad en la barra de búsqueda. Observa cómo en estos dos ejemplos, aunque Concurrent Render no hace que la aplicación sea más rápida, ya sabes, no acelera nada, hace que se sienta más rápida, al hacerla más receptiva, y esto es muy importante.

Bueno, a continuación quiero profundizar un poco más en este ejemplo de filtro de lista, para que podamos observar más de cerca cómo funciona este proceso. Vale, esto va a sentar las bases para lo que vamos a ver a continuación. Así que aquí, ahora estoy registrando en la consola cuándo las actualizaciones de alta y baja prioridad empiezan y terminan de representarse. Y también estoy resaltando cuándo se interrumpen las representaciones. Veamos esto paso a paso. Primero, cuando escribimos la primera letra H, como estamos llamando a un set state para establecer el filtro, esto provoca una representación de alta prioridad, que se ejecuta de principio a fin sin parar. Como sin ser interrumpida. Observa que en esta primera representación de alta prioridad, sólo el filtro se ha actualizado. Pero el tercer filtro todavía tiene su antiguo valor, que es simplemente una cadena vacía. Luego, después de que la actualización de alta prioridad termina de representarse, React comienza la representación de baja prioridad, donde tanto el filtro como el tercer filtro están actualizados. Pero una vez más, como escribimos otra letra antes de que la representación de baja prioridad termine, entonces la interrumpimos de nuevo para atender a otra actualización de alta prioridad. Además, en la segunda representación de alta prioridad, como la anterior representación de baja prioridad no pudo terminar, todavía estamos viendo el primer valor de filtro diferido. Esto nos muestra que, en las representaciones de baja prioridad, todos los valores están actualizados, independientemente de su origen. Sin embargo, en las representaciones de alta prioridad, los valores diferidos pueden estar desactualizados. Esta vez, somos capaces de terminar la representación de baja prioridad antes de que escribamos algo más. Así que como puedes ver, en la lista filtrada, la interfaz de usuario se actualiza en consecuencia. De hecho, déjame volver atrás, para que puedas ver esto sucediendo. Como antes, no hay ningún filtrado en absoluto, porque nunca terminamos ninguna representación de baja prioridad que actualice la lista. Y ahora, por primera vez, hemos terminado la representación de baja prioridad. Y porque hicimos eso, puedes ver que la lista se actualizó realmente. Siguiendo adelante, escribimos una tercera letra, que, una vez más, desencadena una representación de alta prioridad.

Pero ahora observa que, como pudimos terminar la representación de baja prioridad anterior en esta alta prioridad de representación ahora, el filtro diferido está actualizado con el filtro. Están sincronizados, lo que nos dice que, mientras las representaciones de baja prioridad sigan siendo interrumpidas, los valores diferidos estarán desactualizados en las representaciones de alta prioridad. Y es solo cuando la representación de baja prioridad puede completarse que los estados estarán en sincronía de nuevo.

Ahora, el proceso se repite una vez más hasta que terminamos de escribir todo. Así que escribimos una letra más, y luego llenamos la lista con la representación de baja prioridad. Tal vez la terminamos, tal vez no, se interrumpe hasta que finalmente terminamos de escribir todo. Entonces las representaciones de baja prioridad pueden terminar, y llegamos al estado final, por así decirlo.

Ahora, antes de avanzar, hay dos observaciones importantes que deben hacerse. Primero, en este ejemplo, estamos usando el hook use deferred value, pero si hubiéramos usado, como, el hook use transition en su lugar, habría funcionado de la misma manera, porque funcionan prácticamente de la misma manera. Segundo, los más atentos podrían haber notado que aunque esto no se mostró explícitamente debido a la falta de estados de pantalla reales, para ser honestos, los componentes cuyas actualizaciones son lentas, a saber, tanto el componente principal en el ejemplo de navegación como la lista futura en el ejemplo de filtrado de lista, están siendo memorizados. Así que hay un React memo envolviendo sus definiciones, que es lo que hace que su re-renderizado sea omitido en las representaciones de alta prioridad. Así que es porque sus representaciones son omitidas, que podemos mantener la interfaz receptiva al no tener que volver a renderizar los componentes costosos, por así decirlo. Y no se vuelven a renderizar como las representaciones son omitidas, precisamente porque reciben un valor desactualizado en las representaciones de alta prioridad.

Ok, con todo eso en mente, ahora podrías estar pensando, entonces la concurrent rendering es tan agradable que esto significa que deberíamos usar transiciones y valores diferidos para todo, ¿verdad? ¿Verdad? Bueno, en realidad no. Definitivamente no queremos hacer eso. Si hacemos eso, estaríamos haciendo el equivalente de asignar una baja prioridad a cada una y a todas las actualizaciones. Y si todo tiene una baja prioridad, entonces no hay prioridades en absoluto, ¿verdad? Verás, esto es lo que teníamos pre-React 18, antes de que la concurrent rendering fuera una cosa. Como, todas las actualizaciones tenían la misma prioridad, que era la causa misma de nuestros problemas en el primer lugar. Era solo que en lugar de que cada actualización tuviera una baja prioridad, tenían una alta prioridad. Pero es lo mismo, ¿sabes? Así que al final, nuestro trabajo como desarrolladores es identificar qué actualizaciones son rápidas, cuáles son lentas, y luego asignar prioridades en consecuencia, para que podamos, en la medida de nuestras posibilidades, mantener la aplicación receptiva y ofrecer una gran user experience. Si quieres saber más sobre Concurrent React, hay esta entrada de blog que escribí que entra en mucho más detalle sobre la concurrent rendering. También habla sobre las características concurrentes, e incluso un poco sobre suspense y cómo interactúa con las características concurrentes. Así que no olvides echarle un vistazo. Además, por último pero no menos importante, hay este pequeño paquete que publiqué que tiene un hook que ayuda a debug las características concurrentes. Es el hook que utilicé para crear esos registros que viste en la diapositiva de la lista futura. Es bastante interesante. Vale la pena echarle un vistazo. Así que con todo eso dicho, muchas gracias y que tengas un maravilloso día. Adiós.