Descifrando el Modo Concurrente

This ad is not shown to multipass and full ticket holders
React Summit US
React Summit US 2025
November 18 - 21, 2025
New York, US & Online
The biggest React conference in the US
Learn More
In partnership with Focus Reactive
Upcoming event
React Summit US 2025
React Summit US 2025
November 18 - 21, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

Con la llegada del modo concurrente en React 18, hablemos de las complejidades detrás de proporcionar APIs declarativas para el renderizado concurrente. Mientras implementaba las APIs del modo concurrente desde cero para Brahmos.js, me encontré con muchos casos de uso y variabilidad que lo convirtieron en uno de los problemas más interesantes de resolver, y aprecio aún más los esfuerzos de React en promover la UI Concurrente. En esta charla veremos qué significa el modo concurrente para una aplicación web, cuáles son las complejidades internas y cómo lo resolví para Brahmos.js.

This talk has been presented at React Advanced 2021, check out the latest edition of this React Conference.

FAQ

El modo concurrente en React 18 no es una función específica que se implemente, sino una serie de características incrementales que permiten utilizar los recursos de manera más eficiente, manteniendo la aplicación receptiva y permitiendo el renderizado en segundo plano.

Sudhanshu Yadav es un arquitecto de front-end que trabaja en Proficy, autor de Brahmos, una biblioteca React, y ha desarrollado varias otras herramientas de código abierto.

Las características concurrentes en React permiten una mejor utilización de los recursos, manteniendo la aplicación receptiva y permitiendo operaciones como suspender, pausar, reanudar o agrupar renderizados, mejorando así la experiencia del usuario.

El time slicing es un patrón en React que divide un trabajo grande en unidades más pequeñas (tasks). Después de procesar cada unidad, se verifica si el navegador necesita realizar alguna tarea, permitiendo así que ambas operaciones se intercalen eficientemente.

En el modo concurrente, se puede priorizar las actualizaciones según su importancia, diferir actualizaciones de menor prioridad e interrumpirlas si es necesario, lo que ayuda a mantener la consistencia y la capacidad de respuesta de la aplicación.

El renderizado en segundo plano permite a React crear un árbol de trabajo en progreso paralelo al árbol actual, procesando actualizaciones sin afectar la representación visible del DOM, lo que ayuda a evitar inconsistencias en la interfaz de usuario.

Las transiciones en React son una forma declarativa de definir actualizaciones diferidas que no deben bloquear el navegador. Permiten agrupar actualizaciones durante una transición sin afectar la capacidad de respuesta, ejecutándose como actualizaciones diferidas hasta que se cumple un tiempo de espera.

Sudhanshu Yadav
Sudhanshu Yadav
30 min
25 Oct, 2021

Comments

Sign in or register to post your comment.
Video Summary and Transcription
Sudhanshu Yadav discute la característica incremental concurrente en React 18 y la necesidad del modo concurrente para proporcionar una mejor experiencia de usuario. El time slicing es el patrón clave que permite las características concurrentes. El renderizado en segundo plano y la unidad de trabajo se utilizan para lograr un renderizado asíncrono y una consistencia eventual. El modo concurrente introduce un nuevo patrón llamado differing para el renderizado inmediato y el ajuste basado en los recursos disponibles. React proporciona APIs para actualizaciones y transiciones diferidas. La implementación de las APIs del modo concurrente puede ser compleja, pero ofrece beneficios como evitar la inanición de actualizaciones y reutilizar el trabajo. La programación y los slots se utilizan para controlar la ejecución y el control dinámico de FPS. El manejo de múltiples transiciones puede ser desafiante, pero las discusiones del grupo de trabajo de React 18 brindan información sobre los esfuerzos del equipo para mejorar la experiencia de usuario.
Available in English: Cracking the Concurrent Mode

1. Introducción a Concurrent Mode

Short description:

En esta charla, Sudhanshu Yadav discute la característica incremental concurrente en React 18 y la necesidad del modo concurrente para proporcionar una mejor experiencia de usuario. Las características concurrentes permiten una utilización efectiva de los recursos, el renderizado en segundo plano y las API declarativas para controlar la secuencia de renderizado. El patrón clave que permite las características concurrentes es el time slicing, que divide un trabajo grande en unidades y proporciona espacio para que el navegador maneje otras tareas.

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 llegue en el React 18, es más como una característica concurrente incremental.

Sobre mí, soy Sudhanshu Yadav, trabajo en Proficy como arquitecto de front-end, soy el autor de Brahmos, la biblioteca React, y también he compartido muchas otras herramientas de código abierto. Soy un fanático de los internos y me encanta discutir los detalles internos de las bibliotecas 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 React o cualquier aplicación en general. La razón más importante por la que existe la característica concurrente es proporcionar una mejor experiencia personal. Muchas bibliotecas se centran en mejorar el rendimiento de la biblioteca en sí, lo cual debería ser una prioridad, pero a veces esas mejoras no son perceptibles para el usuario, y si un usuario no siente que su aplicación es fluida, entonces su aplicación no es fluida. Deberían perseguir que su aplicación sea fluida.

Hay un problema con los patrones actuales que se centran en mejorar la experiencia personal. Tienen un buen contexto en la aplicación, pero no tienen control sobre la fase de renderizado. Debido a esto, esos patrones no pueden utilizar eficazmente los recursos. Con las características concurrentes, se permite utilizar eficazmente todos los recursos disponibles mientras se mantiene la aplicación receptiva. Las características concurrentes también permiten el renderizado en segundo plano y eso habilita muchas cosas como suspender un renderizado, pausarlo, reanudarlo o agrupar renderizados juntos. Muchas cosas más. También elimina una parte difícil de la longitud del usuario, que es orquestar todo el proceso de renderizado. Proporciona API declarativas que pueden ayudarte a construir, definir más el orden, 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 si quiero que las mejores cosas obtengan una pre-renderización o cargar algo de forma perezosa. Todas esas cosas se pueden hacer de una manera más declarativa.

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 el time slicing. Para entender el time slicing, veamos un árbol de React aquí, todos los nodos, puedes pensar en un componente que tarda un poco en procesar y cómo se produciría una actualización, como cambiar un estado en cualquier componente y luego desencadenará un nuevo renderizado en ese componente que internamente desencadenará un nuevo renderizado de sus hijos y todas estas cosas sucederán de forma asíncrona de una vez. Y una vez que encuentres qué cambios son necesarios para el DOM real, después de conocer esos cambios, se aplican 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 dura 16 milisegundos y tienes 16 milisegundos para ejecutar, incluso menos que eso, para hacer todas las cosas de JavaScript. Entonces, 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 respuesta de la entrada del usuario, animaciones o cualquier cosa. Ahora, si tu JavaScript es grande y se extiende a través de varios fotogramas, ¿qué sucederá si hay una tarea del navegador en el medio? Tendrá que esperar hasta que se termine la tarea de JavaScript. Básicamente, tu aplicación se entrecortará un poco porque habrá caídas de fotogramas. Entonces, con el time slicing, la idea es que tienes un trabajo grande, así que divide ese trabajo grande en unidades de trabajo. Y después, procesa unidad por unidad y después de cada unidad, verifica si el navegador tiene algo que hacer y básicamente da un espacio de respiración para el navegador. Con eso, digamos que si una tarea del navegador llega en el medio, puede encajar fácilmente en tu lado de renderizado, puede encajar fácilmente entre tus tareas de JavaScript.

2. Unit of Work and Background Rendering

Short description:

Entonces intentemos visualizarlo en nuestra aplicación. Procesas una unidad de trabajo, llamada Fiverr en React, y verificas si debe incluirse en el navegador. Si no es así, procesas la siguiente unidad hasta que debas incluir el navegador. Una vez que el navegador ha terminado, continúas procesando unidades hasta que todos los cambios se rendericen y se confirmen. Esto convierte el renderizado sincrónico en renderizado asíncrono. Para mantener la consistencia, se utiliza el renderizado en segundo plano. En lugar de actualizar el árbol actual, se crea un árbol en progreso. El árbol actual se mantiene consistente con el DOM real mientras se procesa en el árbol en progreso. Las actualizaciones se priorizan según su tipo, con las tareas del navegador y las actualizaciones de entrada teniendo la mayor prioridad. React proporciona API para marcar manualmente las actualizaciones como diferidas o sincrónicas. Se logra la consistencia eventual al final.

Entonces intentemos visualizarlo en nuestra aplicación. Así que realizas 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. Procesas una unidad de Fiverr y luego verificas si debes incluirla en el navegador, y si no, procesas la siguiente unidad y sigues haciéndolo hasta que no debas incluir el navegador. Tan pronto como debas incluir el navegador, detienes tu procesamiento en ese momento y programar tu próxima unidad de tarea, después de que el navegador haya terminado de hacer sus cosas. Básicamente, te detienes y permites que el navegador haga sus cosas y una vez que el navegador haya terminado, vuelves a procesar las unidades y continuarás hasta que todas las unidades se procesen y una vez que se rendericen todas las cosas, sabrás qué cambios se requieren y confirmas todos esos cambios.

Esto básicamente convierte tu renderizado sincrónico en renderizado asíncrono y es interoperable, como la tarea del navegador puede interoperar o puede haber más variedad de cosas que pueden interoperar. Pero debido a que ahora se ha vuelto asíncrono, hereda el problema de la naturaleza asíncrona, que básicamente significa que pueden ocurrir múltiples cosas al mismo tiempo y si muchas cosas están sucediendo y están sucediendo en tu árbol principal, tu aplicación puede volverse inconsistente. 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, lo marcamos como el árbol actual, que es una representación de tu DOM real. En lugar de actualizarlo directamente, creamos un nuevo árbol en progreso y realizamos todas esas operaciones, todo ese procesamiento en el árbol en progreso. Así es como sucede: copias tu fibra del árbol actual en progreso, verificas si hay actualizaciones pendientes, si las hay, procesas la fibra, básicamente la renderizas, y cualesquiera que sean los hijos renderizados, los comparas con los hijos existentes en el árbol actual. Si son iguales, los clonas del árbol actual. Si son diferentes, entonces creas una nueva fibra. Y luego procesas tu siguiente fibra y continúas haciendo eso, repitiendo hasta que todo esté terminado. Con esto, obtienes el beneficio de que no estás mutando, no estás afectando el árbol actual. Entonces, tu árbol actual se mantiene consistente con tu DOM real mientras estás haciendo algún trabajo en el árbol en progreso. Solo cuando hayas terminado con todas las cosas, una vez que hayas renderizado, conozcas todos los cambios y confirmes los cambios en el DOM. Ahora tu árbol en progreso es una representación real de tu DOM. Intercambiamos el árbol actual y el árbol en progreso porque el árbol en progreso es una versión más precisa de lo que es el DOM. Y al ser asíncrono por naturaleza, puede haber N número de actualizaciones que ocurran al mismo tiempo. Y cuando hay muchas actualizaciones en una cola, necesitas priorizarlas. Y diferentes tipos de actualizaciones tienen diferentes prioridades. Por ejemplo, las tareas del navegador tienen la mayor prioridad, como una pintura que debe ocurrir primero. Y también dentro del contexto de la aplicación, las actualizaciones en la entrada, que deben 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 respuesta. Todos estos tipos de actualizaciones tienen una prioridad más alta. Y deben actualizarse de forma síncrona porque necesitas dar una respuesta rápida al usuario. Pero las actualizaciones como los tiempos de espera, las llamadas a la API, las cargas perezosas, todas esas tienen una prioridad más baja y está bien si se retrasan un poco. Podemos diferir ese tipo de actualizaciones y ese tipo de actualizaciones también se pueden interrumpir. Y React proporciona una API diferente para marcar manualmente las actualizaciones como diferidas o sincrónicas, como se usa para transiciones, flushing, etc.

Ahora, hay otro patrón que es muy importante para el renderizado de contenido, que es que al final quieres tener una consistencia eventual.

3. Concurrent Mode and Differing in React

Short description:

Para entender esto, tomemos el ejemplo de una interfaz de usuario con una tabla y una barra de entrada para filtrar. Cuando un usuario escribe, la actualización de la entrada debe ser sincrónica, mientras que la actualización de la tabla puede retrasarse. El debouncing es un patrón común, pero con el modo concurrente se introduce un nuevo patrón llamado differing. Esto permite el renderizado inmediato de la tabla mientras se interrumpe para una nueva entrada del usuario. Se ajusta automáticamente según los recursos disponibles. Las transiciones en React proporcionan una forma declarativa de definir actualizaciones diferidas.

Entonces, para entender esto, veamos un ejemplo. Digamos que tenemos una interfaz de usuario 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. Entonces, cada vez que escribes en la entrada, filtras la tabla.

Ahora, mientras un usuario está escribiendo, esa actualización debe ocurrir más rápido porque debes darle retroalimentación al usuario de que se está ingresando algo. Por lo tanto, debe hacerse de forma sincrónica. Pero la actualización de la tabla puede retrasarse. Está bien si el renderizado de la tabla ocurre en unos pocos milisegundos. Es posible que el usuario ni siquiera lo note o que esté bien con eso.

Entonces, existen patrones existentes para resolver esto. Uno de los patrones comunes es el debouncing. Con el debouncing, haces algo después de unos milisegundos y no lo haces hasta ese segundo. Y si haces algo en el medio, simplemente desplazas ese límite. Pero, con el modo concurrente, se introduce un nuevo patrón llamado differing en lugar del debouncing. Entonces, el debouncing no es muy bueno porque solo retrasa el problema. En realidad, no resuelve el problema. Sería como si renderizaras hasta 200 milisegundos. Pero, ¿qué sucederá si un usuario está tratando de escribir en ese momento? Con el differing, no tienes que esperar 200 milisegundos. Puedes comenzar a renderizar tu tabla lo antes posible. Y sigues intentando renderizarla y la interrumpes cada vez que haya una nueva entrada de usuario. Eventualmente, la tabla se vuelve consistente con lo que el usuario ha escrito. Está bien que se retrase un poco allí. Esto permite que las máquinas con más recursos lo hagan rápido. Para las máquinas que no tienen muchos recursos, se retrasará más. Por lo tanto, se ajustará automáticamente según los recursos disponibles.

Ahora, otro patrón si estás siguiendo React, es posible que hayas pasado por transiciones. Y las transiciones, es posible que hayas visto este fragmento de código. Como en los Componentes Funcionales, puedes usar transiciones y obtener el método de inicio de transición. Y las transiciones son principalmente una forma declarativa de definir una actualización diferida.

4. Actualizaciones y Transiciones

Short description:

Es como decir que tu aplicación está en el estado A y quieres moverla al estado B. Y cualquier actualización entre el estado A y B debe agruparse como una transición. Todas las actualizaciones que ocurren en esa transición se agrupan y se ejecutan juntas. Las transiciones pueden interrumpirse por eventos síncronos, por lo que se utilizan tiempos de espera para asegurar que las actualizaciones se ejecuten. Múltiples transiciones dentro de una acción pueden ejecutarse de forma independiente y fusionar elementos en el árbol actual.

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

Pero, además, todas las actualizaciones que ocurren en esa transición, como aquí SETI state que está en el mismo componente, onClick podría llamar a SETI state en su componente padre, todas las actualizaciones se agrupan en una transición y se ejecutan juntas. Debido a que las transiciones pueden interrumpirse por eventos síncronos, podría haber una posibilidad de que la transición no ocurra en absoluto.

Por lo tanto, para esa transición también hay tiempos de espera. Puedes proporcionar un tiempo de espera y decir, al menos en estos milisegundos, quieres que tu actualización esté disponible en el DOM. Y cuando llegue a ese tiempo de espera, intenta ejecutarlas de forma síncrona. 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... comenzar la transición A, comenzar la transición B. Y ambas transiciones pueden ejecutarse de forma independiente. Es como si se ejecutaran en su propio universo. Y una vez que se ejecutan, pueden fusionar elementos en el árbol actual. Además, cuando llamas al inicio de la transición dos veces, estás llamando a las mismas transiciones de inicio. Por lo tanto, todas estas múltiples transiciones, que son iniciadas por el mismo método de inicio de transición, se agrupan juntas. Por lo tanto, no se observa un comportamiento inconsistente. Estado de comportamiento inconsistente.

5. Complejidades en la Implementación de APIs de Contenido

Short description:

Ahora, si bien el modo de contenido es excelente y ofrece muchas posibilidades, implementar esas APIs no es muy sencillo. La primera complejidad es que tus actualizaciones pueden volverse obsoletas. Para solucionar esto, estoy utilizando un ritmo de lapso de tiempo en esas actualizaciones. Para la parte de mutación, creamos una cola de actualizaciones donde se almacenan todas las actualizaciones. Estas actualizaciones se aplican de forma perezosa durante la fase de renderizado, por lo que solo pueden ocurrir en tu árbol de trabajo en progreso. No tiene que afectar tus referencias de árbol actuales.

Ahora, si bien el modo de contenido es excelente y ofrece muchas posibilidades, implementar esas APIs no es muy sencillo. Hay muchas complejidades y en la próxima parte discutiremos esas complejidades. Aquí, será más sobre mi experiencia en la construcción de 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 forma asíncrona, puede ser interrumpida por una actualización sincrónica y esos cambios de estado de la actualización diferida pueden volverse obsoletos. De manera similar, también puede volverse obsoleto por otra actualización diferida porque todo está sucediendo de forma asíncrona. Y el efecto más grande es que podrían estar mutando la misma referencia y también pueden tener efectos secundarios.

Entonces, para solucionar esto, lo que estoy haciendo es mantener un ritmo de lapso de tiempo en esas actualizaciones. Y cuando estoy en la fase de renderizado, verifico si la actualización es más antigua que la actualización del árbol actual. Si es nueva, sigo el camino más reciente; de lo contrario, descarto las actualizaciones antiguas. Para la parte de mutación, que puede ocurrir principalmente en un componente de clase donde todos los estados de setstate se almacenan en una instancia del componente. En lugar de aplicar el estado en las llamadas de setstate, creamos una cola de actualizaciones donde se almacenan todas las actualizaciones. Estas actualizaciones se aplican de forma perezosa durante la fase de renderizado, por lo que solo pueden ocurrir en tu árbol de trabajo en progreso. No tiene que afectar tus referencias de árbol actuales.

6. Starvación de actualizaciones y reutilización de trabajo

Short description:

Para solucionar la starvación de actualizaciones, se agrega un recuento de reintentos a las actualizaciones de baja prioridad, dándoles más tiempo para las actualizaciones diferidas. Las transiciones se pueden hacer síncronas después de un tiempo de espera. La reutilización del trabajo ya realizado es crucial para evitar desechar el trabajo rehacer. Las actualizaciones en un árbol diferido se pueden reanudar desde donde se quedaron, verificando si están obsoletas y clonando las fibras si es necesario.

El otro problema es la starvación de actualizaciones. Las actualizaciones de baja prioridad pueden ser consumidas por actualizaciones de alta prioridad, por lo que pueden sufrir de starvación, ya que hay muchas actualizaciones de alta prioridad que ocurren con mucha frecuencia, lo que nunca permitirá que la actualización de baja prioridad ocurra. Para solucionar este problema en particular, agregué un recuento 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 trabajo en progreso.

También, para las transiciones, tener un tiempo de espera ayuda, donde puedes decir que 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 síncrona. Y la pieza más importante es reutilizar el trabajo que ya hemos realizado, tanto como sea posible. Debido a que todo está sucediendo de forma asíncrona, existe la posibilidad de que desechemos el trabajo rehacer y para resolver eso, en su mayoría, hago todas las actualizaciones síncronas directamente en un árbol actual porque debe ser vaciado de forma síncrona y resolver el flujo de trabajo en progreso solo para las actualizaciones diferidas. Entonces, con eso, obtenemos la capacidad de, por ejemplo, si hay una actualización en curso en un árbol 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 realizado se han vuelto obsoletas o no, si no están obsoletas, puedes mantener esas fibras. Si están obsoletas, puedes clonar las fibras nuevamente desde el árbol actual.

7. Programación y Ranuras para la Ejecución

Short description:

El problema de programación surge al decidir cuándo ceder al navegador. Para abordar esto, implementé un concepto de ranuras, donde cada ranura tiene una duración de 5 milisegundos. Después de cada ranura, cedemos al navegador y programamos la siguiente ranura utilizando un canal de mensajes. Sin embargo, cuando estamos cerca del fotograma, programamos a través de una llamada de devolución de espera y establecemos un tiempo de espera para garantizar una respuesta más rápida. El tamaño de la ranura puede variar según el número de actualizaciones diferidas y el tiempo disponible en un fotograma, lo que permite un control dinámico de los FPS.

El otro problema interesante, y fue una especie de pesadilla para mí, fue la programación. El problema con la programación es que, digamos que si cedes al navegador dos veces, 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 fotogramas. Al mismo tiempo, si cedes demasiado al navegador, mantendrá tu navegador receptivo, pero hará que la ejecución tarde 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? El navegador está trabajando en API como isInputPending y la API del programador que pueden resolver este problema, pero hasta que estén disponibles, tuve que encontrar mi propia solución. Lo que se me ocurrió es un concepto de ranuras donde creé ranuras de 5 milisegundos y en esas ranuras, podemos procesar tantas fibras como sea posible. Ahora, después de cada ranura, cedemos al navegador y programamos la siguiente ranura con un canal de mensajes y los canales de mensajes son buenos en términos de que no tienen un tiempo de espera, puedes decir que la mayoría de las técnicas celulares como requestAnimationFrame o no requestAnimationFrame, sino setTimeout y requestIdleCallback, tendrán mayores retrasos entre dos ranuras. Pero el canal de mensajes también puede consumir algunas tareas del navegador, así que lo que hice es que cuando estamos cerca del fotograma y en ese momento, en lugar de programar desde el canal de mensajes, programamos a través de una llamada de devolución de espera y también con un tiempo de espera y el primero que responda, lo tomamos y ignoramos el otro. Y las ranuras no son constantes. El tamaño de la ranura puede aumentar si se vuelve a intentar una actualización diferida varias veces y también el tamaño de la ranura puede reducirse según si tienes suficiente, como si tus ranuras han tomado suficiente tiempo en un fotograma y queda menos tiempo en ese fotograma en particular, por lo que la ranura puede volverse más pequeña para acomodar eso. Y por cierto, una ranura incluso puede volverse más grande que un fotograma, puede abarcar dos fotogramas. La idea detrás de eso es que programáticamente, no programáticamente, dinámicamente podemos controlar, podemos ajustar los FPS en función de la velocidad de ejecución y los recursos disponibles para un usuario.

8. Manejo de Múltiples Transiciones y Complejidades

Short description:

El manejo de múltiples transiciones puede ser una pesadilla, especialmente cuando hay condiciones de riesgo y conflictos entre las actualizaciones. BrahMos adopta un enfoque más simple, ejecutando las transiciones de forma independiente si provienen de diferentes transiciones de inicio, y fusionándolas si comienzan desde el mismo método. Las transiciones anidadas siguen las transiciones hoja, y solo se mantienen las actualizaciones de estado directas del hijo. Hay muchas complejidades, pero explorar las discusiones del grupo de trabajo de React 18 y el documento anterior sobre el modo concurrente proporcionará información valiosa sobre los esfuerzos del equipo para mejorar la experiencia del 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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Una Guía del Comportamiento de Renderizado de React
React Advanced 2022React Advanced 2022
25 min
Una Guía del Comportamiento de Renderizado de React
Top Content
This transcription provides a brief guide to React rendering behavior. It explains the process of rendering, comparing new and old elements, and the importance of pure rendering without side effects. It also covers topics such as batching and double rendering, optimizing rendering and using context and Redux in React. Overall, it offers valuable insights for developers looking to understand and optimize React rendering.
Construyendo Mejores Sitios Web con Remix
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Construyendo Mejores Sitios Web con Remix
Top Content
Remix is a web framework built on React Router that focuses on web fundamentals, accessibility, performance, and flexibility. It delivers real HTML and SEO benefits, and allows for automatic updating of meta tags and styles. It provides features like login functionality, session management, and error handling. Remix is a server-rendered framework that can enhance sites with JavaScript but doesn't require it for basic functionality. It aims to create quality HTML-driven documents and is flexible for use with different web technologies and stacks.
Compilador React Forget - Entendiendo React Idiomático
React Advanced 2023React Advanced 2023
33 min
Compilador React Forget - Entendiendo React Idiomático
Top Content
Joe Savona
Mofei Zhang
2 authors
The Talk discusses React Forget, a compiler built at Meta that aims to optimize client-side React development. It explores the use of memoization to improve performance and the vision of Forget to automatically determine dependencies at build time. Forget is named with an F-word pun and has the potential to optimize server builds and enable dead code elimination. The team plans to make Forget open-source and is focused on ensuring its quality before release.
Uso efectivo de useEffect
React Advanced 2022React Advanced 2022
30 min
Uso efectivo de useEffect
Top Content
Today's Talk explores the use of the useEffect hook in React development, covering topics such as fetching data, handling race conditions and cleanup, and optimizing performance. It also discusses the correct use of useEffect in React 18, the distinction between Activity Effects and Action Effects, and the potential misuse of useEffect. The Talk highlights the benefits of using useQuery or SWR for data fetching, the problems with using useEffect for initializing global singletons, and the use of state machines for handling effects. The speaker also recommends exploring the beta React docs and using tools like the stately.ai editor for visualizing state machines.
Enrutamiento en React 18 y más allá
React Summit 2022React Summit 2022
20 min
Enrutamiento en React 18 y más allá
Top Content
Routing in React 18 brings a native app-like user experience and allows applications to transition between different environments. React Router and Next.js have different approaches to routing, with React Router using component-based routing and Next.js using file system-based routing. React server components provide the primitives to address the disadvantages of multipage applications while maintaining the same user experience. Improving navigation and routing in React involves including loading UI, pre-rendering parts of the screen, and using server components for more performant experiences. Next.js and Remix are moving towards a converging solution by combining component-based routing with file system routing.
Concurrencia en React, Explicada
React Summit 2023React Summit 2023
23 min
Concurrencia en React, Explicada
Top Content
React 18's concurrent rendering, specifically the useTransition hook, optimizes app performance by allowing non-urgent updates to be processed without freezing the UI. However, there are drawbacks such as longer processing time for non-urgent updates and increased CPU usage. The useTransition hook works similarly to throttling or bouncing, making it useful for addressing performance issues caused by multiple small components. Libraries like React Query may require the use of alternative APIs to handle urgent and non-urgent updates effectively.

Workshops on related topic

Masterclass de Depuración de Rendimiento de React
React Summit 2023React Summit 2023
170 min
Masterclass de Depuración de Rendimiento de React
Top Content
Featured Workshop
Ivan Akulov
Ivan Akulov
Los primeros intentos de Ivan en la depuración de rendimiento fueron caóticos. Vería una interacción lenta, intentaría una optimización aleatoria, vería que no ayudaba, y seguiría intentando otras optimizaciones hasta que encontraba la correcta (o se rendía).
En aquel entonces, Ivan no sabía cómo usar bien las herramientas de rendimiento. Haría una grabación en Chrome DevTools o React Profiler, la examinaría, intentaría hacer clic en cosas aleatorias, y luego la cerraría frustrado unos minutos después. Ahora, Ivan sabe exactamente dónde y qué buscar. Y en esta masterclass, Ivan te enseñará eso también.
Así es como va a funcionar. Tomaremos una aplicación lenta → la depuraremos (usando herramientas como Chrome DevTools, React Profiler, y why-did-you-render) → identificaremos el cuello de botella → y luego repetiremos, varias veces más. No hablaremos de las soluciones (en el 90% de los casos, es simplemente el viejo y regular useMemo() o memo()). Pero hablaremos de todo lo que viene antes - y aprenderemos a analizar cualquier problema de rendimiento de React, paso a paso.
(Nota: Esta masterclass es más adecuada para ingenieros que ya están familiarizados con cómo funcionan useMemo() y memo() - pero quieren mejorar en el uso de las herramientas de rendimiento alrededor de React. Además, estaremos cubriendo el rendimiento de la interacción, no la velocidad de carga, por lo que no escucharás una palabra sobre Lighthouse 🤐)
Next.js para Desarrolladores de React.js
React Day Berlin 2023React Day Berlin 2023
157 min
Next.js para Desarrolladores de React.js
Top Content
Featured WorkshopFree
Adrian Hajdin
Adrian Hajdin
En esta avanzada masterclass de Next.js, profundizaremos en conceptos clave y técnicas que permiten a los desarrolladores de React.js aprovechar al máximo Next.js. Exploraremos temas avanzados y prácticas prácticas, equipándote con las habilidades necesarias para construir aplicaciones web de alto rendimiento y tomar decisiones arquitectónicas informadas.
Al final de esta masterclass, serás capaz de:1. Comprender los beneficios de los Componentes del Servidor React y su papel en la construcción de aplicaciones React interactivas, renderizadas por el servidor.2. Diferenciar entre el tiempo de ejecución de Edge y Node.js en Next.js y saber cuándo usar cada uno en función de los requisitos de tu proyecto.3. Explorar técnicas avanzadas de Renderizado del Lado del Servidor (SSR), incluyendo streaming, fetching paralelo vs. secuencial, y sincronización de datos.4. Implementar estrategias de caché para mejorar el rendimiento y reducir la carga del servidor en las aplicaciones Next.js.5. Utilizar Acciones React para manejar la mutación compleja del servidor.6. Optimizar tus aplicaciones Next.js para SEO, compartir en redes sociales, y rendimiento general para mejorar la descubrabilidad y la participación del usuario.
Aventuras de Renderizado Concurrente en React 18
React Advanced 2021React Advanced 2021
132 min
Aventuras de Renderizado Concurrente en React 18
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
Con el lanzamiento de React 18 finalmente obtenemos el tan esperado renderizado concurrente. Pero, ¿cómo va a afectar eso a tu aplicación? ¿Cuáles son los beneficios del renderizado concurrente en React? ¿Qué necesitas hacer para cambiar al renderizado concurrente cuando actualices a React 18? ¿Y qué pasa si no quieres o no puedes usar el renderizado concurrente todavía?

¡Hay algunos cambios de comportamiento de los que debes estar al tanto! En esta masterclass cubriremos todos esos temas y más.

Acompáñame con tu portátil en esta masterclass interactiva. Verás lo fácil que es cambiar al renderizado concurrente en tu aplicación React. Aprenderás todo sobre el renderizado concurrente, SuspenseList, la API startTransition y más.
Consejos sobre React Hooks que solo los profesionales conocen
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
Consejos sobre React Hooks que solo los profesionales conocen
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
La adición de la API de hooks a React fue un cambio bastante importante. Antes de los hooks, la mayoría de los componentos tenían que ser basados en clases. Ahora, con los hooks, estos son a menudo componentes funcionales mucho más simples. Los hooks pueden ser realmente simples de usar. Casi engañosamente simples. Porque todavía hay muchas formas en las que puedes equivocarte con los hooks. Y a menudo resulta que hay muchas formas en las que puedes mejorar tus componentes con una mejor comprensión de cómo se puede usar cada hook de React.Aprenderás todo sobre los pros y los contras de los diversos hooks. Aprenderás cuándo usar useState() versus useReducer(). Veremos cómo usar useContext() de manera eficiente. Verás cuándo usar useLayoutEffect() y cuándo useEffect() es mejor.
Presentando FlashList: Construyamos juntos una lista performante en React Native
React Advanced 2022React Advanced 2022
81 min
Presentando FlashList: Construyamos juntos una lista performante en React Native
Top Content
Featured Workshop
David Cortés Fulla
Marek Fořt
Talha Naqvi
3 authors
En esta masterclass aprenderás por qué creamos FlashList en Shopify y cómo puedes usarlo en tu código hoy. Te mostraremos cómo tomar una lista que no es performante en FlatList y hacerla performante usando FlashList con mínimo esfuerzo. Usaremos herramientas como Flipper, nuestro propio código de benchmarking, y te enseñaremos cómo la API de FlashList puede cubrir casos de uso más complejos y aún así mantener un rendimiento de primera categoría.Sabrás:- Breve presentación sobre qué es FlashList, por qué lo construimos, etc.- Migrando de FlatList a FlashList- Enseñando cómo escribir una lista performante- Utilizando las herramientas proporcionadas por la biblioteca FlashList (principalmente el hook useBenchmark)- Usando los plugins de Flipper (gráfico de llamas, nuestro perfilador de listas, perfilador de UI & JS FPS, etc.)- Optimizando el rendimiento de FlashList utilizando props más avanzados como `getType`- 5-6 tareas de muestra donde descubriremos y solucionaremos problemas juntos- Preguntas y respuestas con el equipo de Shopify
React, TypeScript y TDD
React Advanced 2021React Advanced 2021
174 min
React, TypeScript y TDD
Top Content
Featured Workshop
Paul Everitt
Paul Everitt
ReactJS es extremadamente popular y, por lo tanto, ampliamente soportado. TypeScript está ganando popularidad y, por lo tanto, cada vez más soportado.

¿Los dos juntos? No tanto. Dado que ambos cambian rápidamente, es difícil encontrar materiales de aprendizaje precisos.

¿React+TypeScript, con los IDEs de JetBrains? Esa combinación de tres partes es el tema de esta serie. Mostraremos un poco sobre mucho. Es decir, los pasos clave para ser productivo, en el IDE, para proyectos de React utilizando TypeScript. En el camino, mostraremos el desarrollo guiado por pruebas y enfatizaremos consejos y trucos en el IDE.