Cracking the Concurrent Mode

En esta charla, hablaré sobre el modo concurrente, más sobre mi modelo mental hacia las características concurrentes. Así que, no hay un modo concurrente como tal que venga en React 18, es más como una característica concurrente incremental.

Sobre mí, soy Sudhanshu Yadav, trabajo en Proficy como arquitecto de front end, he sido autor de Brahmos, la biblioteca de React, y también he liberado muchos otros herramientas. Soy un fanático interno, y me encanta discutir los internos de la biblioteca que uso, me gusta hacer teorías al respecto, puedes encontrarme en Twitter o puedes revisar mi proyecto en GitHub.

Antes de comenzar, entendamos por qué necesitamos el modo concurrente, qué significa para una aplicación de React o cualquier aplicación en general. La razón más importante por la que existe la característica concurrente es para proporcionar una mejor experiencia personal. Ahora, muchas bibliotecas se centran en mejorar el rendimiento de la biblioteca en sí, lo cual debería ser la prioridad, pero a veces esas mejoras no son notables por el usuario, y si un usuario no siente que tu aplicación es fluida, entonces tu aplicación no es fluida. Deberían percibir tu aplicación como fluida.

Hay un problema con los patrones actuales, que se trata de mejorar la experiencia personal. Tienen un buen contexto en la aplicación, pero no tienen control sobre tu fase de renderizado. Debido a lo cual esos patrones no pueden usar efectivamente los recursos. Con las características concurrentes, se permite usar efectivamente todos los recursos disponibles mientras se mantiene la aplicación receptiva. Las características concurrentes también habilitan el renderizado en segundo plano y eso permite muchas cosas como suspender un renderizado, pausarlo, reanudarlo, o como agrupar renderizados juntos. Muchas cosas. Y también elimina una parte difícil de la longitud del usuario, que es orquestar todo el proceso de renderizado. Proporciona APIs declarativas que pueden ayudarte a construir, definir más los órdenes, dar una pista a React o a la aplicación como una biblioteca de que esta es la forma en que quiero que sea mi secuencia de renderizado, o como si quiero que las mejores cosas obtengan un pre-renderizado de algo o cargar algo de manera diferida. Todas esas cosas se pueden hacer de una manera más declarativa.

Ahora definitivamente la característica concurrente tiene mucho alcance, pero ¿qué habilita las características concurrentes? Y el primer y más importante patrón, diría yo, es la división de tiempo. Para entender la división de tiempo, veamos un árbol de React aquí todos los nodos, puedes pensar en un componente que toma un poco de tiempo para procesar y cómo sucedería la actualización como cambias un estado en cualquier componente y luego desencadenará un re-renderizado en ese componente que internamente desencadenaría el re-renderizado de sus hijos y todas estas cosas sucederán de manera asincrónica de una sola vez. Y una vez que encuentras qué cambios son necesarios para el DOM real, después de conocer esos cambios, comprometes esos cambios al DOM real.

Ahora, veamos cómo se juega en una línea de tiempo de fotogramas. La mayoría de las bibliotecas intentan lograr 60 FPS y eso generalmente significa que tienes un fotograma que es de 16 milisegundos y tienes 16 milisegundos para ejecutar, ni siquiera realmente 16 milisegundos, menos que eso, para ejecutar, para hacer todas las cosas de JavaScript. Así que, si tienes, hay dos tipos de tareas, tarea de JavaScript y tarea del navegador. La tarea de JavaScript sería como el procesamiento del componente, y la tarea del navegador sería como pintar en el navegador o dar una retroalimentación de la entrada del usuario, animaciones o cualquier cosa. Ahora, si tu JavaScript es grande y se extiende a través de múltiples fotogramas, entonces ¿qué pasará si hay una tarea del navegador en el medio? Tiene que esperar hasta que todas las tareas de JavaScript hayan terminado. Así que básicamente, tu aplicación se entrecortará un poco porque habrá caídas de fotogramas. Así que con la división de tiempo, la idea es que tienes un gran trabajo, así que divide ese gran trabajo en unidades de trabajo. Y después, como procesar unidad por unidad y después de cada unidad, verificar si el navegador tiene algo que hacer y básicamente dar un espacio de respiración para el navegador. Con eso digamos que si una tarea del navegador viene en el medio, puede encajar fácilmente en tu lado de renderizado como puede encajar fácilmente entre tu tarea de Javascript.

Así que intentemos visualizarlo en nuestra aplicación. Así que estás haciendo un cambio de estado y con el cambio de estado llamamos, no lo llamemos un componente, llamémoslo una unidad de trabajo, Fiverr en términos de React. Así que procesas una unidad de Fiverr y luego verificas si deberías incluirla en el navegador, y si no, entonces procesas la siguiente unidad, y sigues haciendo hasta que no tengas que incluir el navegador. Tan pronto como tengas que incluir el navegador, detienes tu procesamiento en ese momento y programas tu siguiente unidad de tarea, después de que el navegador haya terminado de hacer sus cosas. Básicamente te detienes y dejas que el navegador haga sus cosas y una vez que el navegador ha terminado, vuelves a procesar unidades y continuarás hasta que todas las unidades estén procesadas y una vez que todas las cosas estén renderizadas, sabes qué cambios son necesarios, comprometes todos esos cambios.

Así que esto básicamente convierte tu renderizado sincrónico en renderizado asincrónico y es interoperable como la tarea del navegador puede interoperar o podría haber más variedad de cosas que pueden interoperar. Pero porque ahora se ha convertido en asincrónico, hereda el problema de la naturaleza asincrónica que es básicamente como múltiples cosas pueden suceder al mismo tiempo y si muchas cosas están sucediendo y están sucediendo en tu árbol principal, tu aplicación puede volverse inconsistente. Así que para resolver eso, tenemos un patrón llamado renderizado en segundo plano. Con el renderizado en segundo plano, digamos que tenemos la misma aplicación y si hay un cambio de estado, en lugar de actualizar el mismo árbol, marquémoslo como el árbol actual, que es una representación de tu DOM real. En lugar de actualizar directamente eso, creas un nuevo árbol de trabajo en progreso, y realizas todas esas operaciones, todo ese procesamiento en el árbol de trabajo en progreso. Así que cómo sucede, copias tu fibra del árbol de trabajo en progreso actual, verificas si hay actualizaciones pendientes, si las hay, procesas la fibra, básicamente la renderizas, y cualquiera que sean los hijos renderizados, los comparas con los hijos existentes en el árbol actual. Si son iguales, clónalos del árbol actual. Si son diferentes, entonces crea una nueva fibra. Y luego procesas tu siguiente fibra, y continúas haciendo eso, repites hasta que todas las cosas estén terminadas. Con esto, un beneficio que obtienes es que no estás mutando, no estás impactando el árbol actual. Así que, tu árbol actual permanece consistente con tu DOM real mientras estás haciendo algún trabajo en el árbol de trabajo en progreso. Solo cuando hayas terminado con todas las cosas como una vez que hayas renderizado, sabes todos los cambios y comprometes los cambios al DOM. Ahora tu árbol de trabajo en progreso es una representación real de tu DOM. Así que intercambiamos el árbol actual y el árbol de trabajo en progreso porque como el árbol de trabajo en progreso es una versión más precisa de lo que es el DOM. Y siendo de naturaleza asincrónica, puede haber N número de actualizaciones sucediendo al mismo tiempo. Y cuando hay muchas actualizaciones en una cola, necesitas priorizarlas. Y diferentes tipos de actualizaciones tienen una prioridad diferente. Por ejemplo, la tarea del navegador tiene la mayor prioridad que sería como un pintado debería suceder primero. Y también dentro del contexto de la aplicación, las actualizaciones en la entrada, que necesitan actualizar tu estado, o si estás haciendo alguna animación a través de JavaScript, o si estás interactuando en un botón, necesitas dar una retroalimentación. Todos estos tipos de actualizaciones tienen una mayor prioridad. Y necesitan ser actualizadas sincrónicamente porque necesitas dar retroalimentación rápida al usuario. Pero actualizaciones como timeouts, llamadas a API, cargas diferidas, todas esas son de menor prioridad y está bien si se retrasan un poco. Así que podemos diferir esos tipos de actualizaciones y esos tipos de actualizaciones también pueden ser interrumpidas. Y React proporciona una API diferente para marcar manualmente las actualizaciones como diferidas o una actualización sincrónica como se usa para transiciones, vaciado, etc.

Ahora, hay un patrón más que es muy importante para el renderizado de contenido, es que al final quieres consistencia eventual.

Así que, para entender esto, veamos un ejemplo. Digamos que tenemos una UI donde tenemos una tabla con muchas filas y columnas y esas celdas tardan un tiempo en renderizarse. Y hay una barra de entrada donde puedes escribir y filtrar cosas. Así que, cada vez que escribes en la entrada, filtras la tabla.

Ahora, mientras un usuario está escribiendo, esa actualización tiene que suceder más rápido porque tienes que dar retroalimentación al usuario de que algo se está ingresando. Así que, tiene que hacerse sincrónicamente. Pero la actualización de la tabla puede retrasarse. Está bien si el renderizado de la tabla ocurre en unos pocos milisegundos. El usuario puede no notar eso en absoluto o el usuario podría estar bien con eso.

Así que, hay patrones existentes para resolver esto. Uno de los patrones comunes es el debouncing. Con el debouncing, haces algo después de algunos milisegundos y no lo haces hasta ese segundo. Y si haces algo en el medio, simplemente cambias ese límite. Pero, con el modo concurrente, trae un nuevo patrón de differing en lugar de debouncing. Así que, el debouncing no es muy bueno porque solo retrasa el problema. No resuelve realmente el problema. Será como, renderizarás hasta 200 milisegundos. Pero, ¿qué pasará si un usuario está tratando de escribir en ese momento? Con este differing, no tienes que esperar 200 milisegundos. Puedes comenzar a renderizar tu tabla tan pronto como sea posible. Y sigues intentando renderizarla y la interrumpirás cada vez que haya una nueva entrada del usuario está sucediendo. Y eventualmente la tabla se vuelve consistente con lo que el usuario ha escrito. Así que, está bien retrasarse un poco allí. Esto permite que en máquinas con más recursos, suceda rápido. Para máquinas que no tienen muchos recursos, se retrasará más. Así que, se ajustará automáticamente según los recursos disponibles.

Ahora, otro patrón si estás siguiendo React debes haber pasado por transiciones. Y transiciones, debes haber visto este fragmento. Como, en Componentes Funcionales puedes usar transiciones, obtienes el método start transition. Y las transiciones son principalmente una forma declarativa de definir una actualización diferida.

Es como decir que tu aplicación está en el estado A, quieres moverla al estado B. Y cualquier actualización entre el estado A y B debe agruparse como una transición. Y no debería bloquear tu navegador, no debería hacer que tu navegador no responda, puede ocurrir como una actualización diferida.

Pero, y también, todas las actualizaciones que ocurren en esa transición, como aquí el estado SETI que está en el mismo componente, onClick podría estar llamando al estado SETI en su componente padre, todas esas actualizaciones se conectan en una transición, y todas se vacían juntas. Porque las transiciones pueden ser interrumpidas por eventos sincrónicos, podría haber una posibilidad de que la transición no ocurra en absoluto.

Así que para eso, la transición también tiene tiempos de espera. Puedes proporcionar un tiempo de espera y decir, al menos en este milisegundo, quieres que tu actualización esté disponible en el DOM. Y cada vez que alcanza ese tiempo de espera, intenta vaciarlas sincrónicamente. Y también puede haber múltiples transiciones dentro de una acción. Como aquí en HandleClick, estamos llamando a la transición A y la transición… iniciar transición A, iniciar transición B. Y ambas transiciones pueden ejecutarse independientemente. Es como ejecutar… ejecutando en su propio universo. Y una vez que se ejecutan, pueden fusionar cosas en el árbol actual. También, como un… puedes… cada vez que llamas al inicio de la transición dos veces, estás llamando a las mismas transiciones de inicio. Así que, todas estas múltiples transiciones, que son iniciadas por el mismo método de inicio de transición se agrupan juntas. Así que, no ves un comportamiento inconsistente. Estado de comportamiento inconsistente.

Ahora, aunque el modo de contenido es genial, ofrece muchas posibilidades, implementar esas APIs no es muy sencillo. Hay muchas complejidades, y en la siguiente parte, discutiremos esas complejidades. Aquí, se basará más en mi experiencia construyendo esas APIs de contenido para promise. Pero sí, la mayoría de ellas también se relacionan con React.

La primera complejidad es que tus actualizaciones pueden volverse obsoletas. Debido a que la actualización diferida ocurre de manera asincrónica, puede ser interrumpida por una actualización síncrona, y esos cambios de estado de la actualización diferida pueden volverse obsoletos. De manera similar, puede volverse obsoleta por una actualización síncrona, también puede volverse obsoleta por otra actualización diferida porque todo está sucediendo de manera asincrónica. Y el mayor efecto es que podrían estar mutando la misma referencia, y también pueden tener efectos secundarios.

Así que para resolver esto, para solucionar el problema de obsolescencia, lo que estoy haciendo es mantener un tempo de lapso de tiempo en esas actualizaciones. Y cada vez que estoy en una fase de renderizado, verifico si la actualización es más antigua que la actualización del árbol actual. Si es nueva, entonces ve al camino más reciente, de lo contrario descarta las actualizaciones antiguas. Para la parte de mutación, que puede ocurrir principalmente en un componente de clase donde cada setstate los estados se almacenan en una instancia de componente. En lugar de aplicar el estado en las llamadas de setstate, creamos una cola de actualizaciones donde se almacenan todas las actualizaciones. Esas actualizaciones se aplican de manera perezosa durante la fase de renderizado, por lo que solo puede suceder en tu árbol de progreso de trabajo. No tiene que impactar tus referencias de árbol actuales.

El otro problema es la inanición de actualizaciones. Las actualizaciones de baja prioridad pueden ser consumidas por actualizaciones de alta prioridad, por lo que pueden quedarse sin recursos, porque hay muchas actualizaciones de alta prioridad ocurriendo con mucha frecuencia, lo que nunca permitirá que la actualización de baja prioridad ocurra. Para solucionar este problema en particular, añadí un conteo de reintentos en las actualizaciones de baja prioridad, y con más reintentos, comienzan a dar más tiempo para las actualizaciones diferidas, para que tengan más espacio, básicamente más tiempo para procesar las fibras en un estado diferido, en un estado de trabajo en progreso.

Además, para las transiciones, tener un tiempo de espera ayuda, donde puedes decir, por ejemplo, si una transición es escrita por una actualización de alta prioridad, después de un tiempo de espera, se convertirá en una actualización sincrónica. Y la pieza más importante es reutilizar el trabajo, que ya hemos hecho, tanto como sea posible. Porque todo está sucediendo de manera asincrónica, hay una buena posibilidad de que podamos desechar el trabajo rehecho y para resolver eso, en lo que más hice, es como hacer todas las actualizaciones sincrónicas directamente en un árbol actual porque tiene que ser vaciado sincrónicamente y resolver el flujo de trabajo en progreso solo para las actualizaciones diferidas. Así que, con eso, la capacidad que obtenemos es como, digamos, por ejemplo, hay una actualización ocurriendo en un diferido, como un árbol de trabajo en progreso. En ese momento, si hay una actualización sincrónica que se activa en un árbol actual, terminarás esa actualización y volverás al árbol de trabajo en progreso. En el árbol de trabajo en progreso, puedes reanudar desde donde comenzaste porque no tienes que desechar nada, solo tienes que verificar si las actualizaciones que has hecho, si se han vuelto obsoletas o no, si no están obsoletas, entonces puedes mantener esas fibras. Si están obsoletas, entonces puedes clonar las fibras nuevamente desde el árbol actual.

El otro problema interesante, y fue una especie de pesadilla para mí, fue la planificación. Así que el problema con la planificación es, digamos que si cedes al navegador para listar, entonces ejecutarás tu código más rápido, pero tu navegador se volverá... Sacrificarás la capacidad de respuesta de un navegador porque consumirás algunos frames. Al mismo tiempo, si cedes demasiado al navegador, mantendrá tu navegador receptivo, pero hará que tu ejecución tome más tiempo. Entonces, ¿cómo sabes cuándo ceder al navegador? Además, una vez que cedes al navegador, ¿cómo sabes que el navegador ha terminado su trabajo para que puedas programar la siguiente unidad de trabajo en consecuencia? Así que el navegador está trabajando en APIs como isInputPending y scheduler API que pueden resolver este problema, pero hasta que estén disponibles, tuve que idear mi propia solución. Así que lo que se me ocurrió es como un concepto de slots donde creé slots de 5 milisegundos y en esos slots, podemos procesar tanto fiber como podamos. Ahora, después de cada slot, cedemos al navegador y programamos el siguiente slot con un canal de mensajes y los canales de mensajes son buenos en términos de que no tienen un tiempo de enfriamiento, se puede decir que la mayoría de las técnicas celulares como request animation frame o no request animation frame sino set timeout y request ridal callback, tendrán mayores retrasos entre dos slots. Pero el canal de mensajes también puede consumir algunas tareas del navegador, así que lo que hice es que siempre que estamos cerca del frame y en ese momento en lugar de programar desde el canal de mensajes, programar a través de request idle callback y también con un set timeout y el que responda primero, tomar eso e ignorar el otro. Y los slots no son constantes. El tamaño del slot puede aumentar si una actualización diferida se reintenta varias veces y también el tamaño del slot puede reducirse basado en si tienes suficiente, como si tus slots han tomado suficiente tiempo en un frame y queda menos tiempo en ese frame en particular, por lo que el slot puede hacerse más pequeño para acomodarlo. Y por cierto, un slot incluso puede hacerse más grande que un frame, como puede abarcar dos frames. Y la idea detrás de eso es programáticamente, no programáticamente, dinámicamente podemos controlar, podemos ajustar los FPS basados en la velocidad de ejecución y los recursos disponibles para un usuario.

El otro problema interesante, y las transiciones son buenas, pero manejar múltiples transiciones es una pesadilla. La cosa es que, debido a que son sincrónicas por naturaleza, puede haber múltiples transiciones en una cola. Y debido a que son sincrónicas, también pueden tener condiciones de riesgo. Y las actualizaciones en una transición pueden ser anuladas por otra transición.

También, una transición puede estar anidada, por lo que puedes escribir una transición de inicio dentro de una transición de inicio y también puedes componer transiciones. Como tener múltiples transiciones de inicio envueltas en otra transición de inicio. Incluso puedes hacer todo tipo de cosas desagradables con las transiciones.

Y otra cosa que puede suceder es que dos transiciones pueden intentar actualizar el mismo estado. Y ahora, ¿qué hacer, cuál tomará precedencia? En BrahMos, adopté un enfoque más simple para resolver eso. React, en este momento, fusiona todas las transiciones juntas, pero su plan a largo plazo es ejecutar las transiciones individualmente en un carril diferente. En BrahMos, lo que estoy haciendo es que si hay dos transiciones de diferentes transiciones de inicio, siempre se ejecutan de forma independiente. Y si la transición comienza, como múltiples transiciones comienzan desde el mismo método de inicio, siempre se fusionan. Ahora bien, esto podría ser que estés llamando al mismo método de inicio varias veces, o podría ser que estés presionando un botón y hubo un botón anterior presionado, ¿aún no se ha procesado completamente? Ahora has vuelto a presionarlo. La transición anterior y la nueva transición, las actualizaciones se fusionarán. Y esto, si tienes diferentes transiciones, esas transiciones se mantienen en una cola de transiciones y se procesan una por una. En lugar de crear múltiples árboles de trabajo en progreso para intentar procesar cada transición en su propio lugar, lo mantenemos simple, procesando una transición a la vez. Y las transiciones de tiempo de espera pueden moverse de la cola de transiciones a la sincronización de datos. Eso lo manejan los tiempos de espera. Y para las transiciones anidadas, simplemente sigo las transiciones hoja que existen, eso se respetará. La transición principal solo mantendrá las actualizaciones de estado que son hijos directos de esa transición.

Ahora hay muchas más complejidades, y supongo que podría haber explicado más de ellas, pero tenemos tiempo limitado. Te recomendaría encarecidamente que revises las discusiones del grupo de trabajo de React 18. Son minas de oro. Y también el documento, el documento anterior sobre el modo concurrente, en realidad obtendrás muchas ideas. Y después de ver esos documentos y discusiones, comenzarás a apreciar el esfuerzo del equipo de React. Están tratando de resolver un problema importante, que es brindar una mejor experiencia de usuario. Y en un esquema más amplio, eso es lo único que importa. Con esa nota, me gustaría agradecerte y verte a todos. Gracias. Gracias.