Understanding the New Event Loop in React Native

Así que estoy bastante emocionado de repasar el nuevo bucle de eventos en React Native. Creo que es una parte de la nueva arquitectura de la que no se habla tanto, y es en realidad una de las partes más interesantes de la nueva arquitectura que está un poco escondida en las notas al pie, generalmente. Así que vamos a adentrarnos en ello, y con suerte tendrá un poco de sentido. Y estoy tratando de construir diferentes conceptos para que, si no estás familiarizado íntimamente con la nueva arquitectura, aún puedas llevarte algo de esto.

Como mencionó Jani, mi nombre es Mo. Dirijo el equipo móvil en Theodo, que es una consultoría global con alrededor de 700 personas y 200 ingenieros móviles. También soy organizador en la comunidad de React Native London. Así que hemos estado haciendo meetups, el meetup de React Native London desde 2016. He sido organizador allí desde 2019, creo. 2020. Así que ha sido un viaje realmente genial, y este año estamos organizando nuestra primera conferencia de React Native London, lo cual es muy emocionante para nosotros.

El año pasado, en algún momento, fui a Twitter y estaba aburrido, así que decidí hacer algunas pruebas de rendimiento, comparando diferentes frameworks móviles para construir aplicaciones. Así que comencé con Swift UI, también miré React Native, y también miré Flutter, y traté de decir, ¿cuáles son las diferencias? , ver cómo se desempeñan en términos de renderizado.

Así que hice una prueba con como 1,000, 2,000, 3,000 vistas, tanto con como sin texto, para entender cómo se desempeñarían en comparación entre sí. Y obtuvo bastante exposición y bastantes me gusta. Y se podía ver que Swift UI supera significativamente a todo lo demás en iOS, luego React Native, y luego Flutter. Y estaba montando el caballo alto aquí, siendo como, mira esto, acabo de ser un experto en rendimiento mirando a través de todos los diferentes frameworks, solo para ser rápidamente reprendido por personas en el equipo central de React Native y React, lo cual fue toda una experiencia. Así que Svetlan Mikhov, quien trabaja en el motor Hermes, tuiteó de vuelta diciendo, sabes, no soy un experto aquí, pero no creo que tu código funcione. Y luego llegó hasta Eli White, quien dirige React y React Native en Meta, quien dijo, sí, estás usando UseLayoutEffect, realmente no va a funcionar correctamente. Y ahí fue cuando me cayó la bomba, que UseLayoutEffect no realmente funciona correctamente dentro de React Native. Y esto fue bastante impactante, porque es solo una parte central de React, y si construyes en la web, estás usando UseLayoutEffect para un montón de cosas diferentes, pero simplemente no funciona en React Native. Y esto fue cierto prácticamente hasta la nueva arquitectura. Y aquí es donde entra la nueva arquitectura, y según el equipo central de React y React Native, UseLayoutEffect finalmente funciona correctamente dentro de la nueva arquitectura. Y coincidentemente, la nueva arquitectura se lanzó hace dos días, y ahora es oficialmente la predeterminada dentro de React Native.

Así que llega en un muy buen momento. Así que un poco de contexto para las personas que no están familiarizadas con la antigua y nueva arquitectura. No voy a quedarme en esto por mucho tiempo. Lo juro, probablemente todos han oído hablar de ello, y están cansados de escuchar charlas sobre la nueva arquitectura. Pero esta es la antigua arquitectura. Y es una versión muy simplificada de la antigua arquitectura, solo para tratar de hacerla un poco más digerible, pero realmente tienes una separación entre una capa JS y una capa Native. Y tienes un puente en el medio que se comunica a través de JSON, por lo que estás serializando y deserializando JSON, y se están comunicando entre ellos. Así que tu código JS y el código que se ejecuta dentro de tu motor JS va a comunicarse por el puente y hablar con la capa Native para diseñar cosas o para llamar al código Native, y eso se comunica con Yogo, que es tu motor de diseño.

La clave que quieres saber sobre todo esto es que toda esta comunicación está sucediendo de manera asíncrona, lo que significa que la entrega de esto no se va a hacer de manera síncrona, y por lo tanto realmente no sabes que estas dos capas no saben sobre el estado de cada una en cualquier momento. Así que el lado de React podría haber disparado un evento. No sabrá que se ha completado completamente en el lado Native, y no hay garantías para ello. Necesitaría consultar de manera asíncrona para ver si eso ha sucedido. Y así había un verdadero cuello de botella con este puente. Y podrían estar desincronizados debido a esta comunicación. Y así, cuando se trataba de diseño y uso de efectos de diseño, específicamente, significaba que los datos que el código de React tenía podrían haber sido información obsoleta e incorrecta, por lo que no era realmente la información actualizada que estaba en el terreno con la capa Native. Y así, la nueva arquitectura intentó cambiar esto.

Y ese JSI haría llamadas Native directamente a través de C++ a cualquier plataforma host Native que sea, si es Objective C, si es Java o cualquier otra plataforma que puedas tener, y ahora tenemos más y más plataformas fuera de hoja. La clave aquí es que esta era una comunicación sincrónica bidireccional. Así que ahora podrías emitir comandos sincrónicamente entre las diferentes capas. Y así, este es realmente el núcleo de la nueva arquitectura de React Native, el JSI.

Y esta nueva arquitectura tiene muchos componentes diferentes dentro de ella. Hay nuevos módulos Native, hay nuevos renderizadores, y también está el nuevo bucle de eventos. Así que solo como recordatorio, los nuevos módulos Native básicamente usan ese JSI para comunicarse sincrónicamente entre las diferentes capas. Te da seguridad de tipos entre tu código JavaScript y tu código Native, lo cual es un gran asunto porque muchos bloqueos ocurrirían porque no había esa seguridad de tipos. Gran parte está escrita en C++, lo que significa que maximizas tu intercambio de código a través de todas estas diferentes plataformas, y está cargando estos módulos de manera perezosa.

Y así puedes tener efectivamente un módulo Turbo que tiene algo de C++ con código específico de Native, un poco más de C++, podría ser todo C++ si quieres que sea, pero es una especie de paradigma diferente para escribir módulos Native. Luego tienes el nuevo renderizador, y esto comienza a conectarse con el bucle de eventos. Este nuevo renderizador llamado Fabric fue escrito en C++, y se comparte a través de todas estas plataformas. Y lo clave aquí es que te permite priorizar la renderización en diferentes hilos, y realmente abre la puerta para muchas de las características modernas de React 18 que han estado disponibles en la web durante mucho tiempo para que realmente funcionen dentro de React Native.

Así que abre la puerta al soporte completo de suspense, transiciones, agrupamiento automático, y todo ese buen material. Así que si miras este ejemplo que está en los documentos de la nueva arquitectura, si comienza a reproducirse, veamos. ¡Ahí vamos!

Pero en el lado derecho, debido a que hay algo de batching, puedes ver que renderiza un montón de cosas juntas y las agrupa bajo el capó para que no tengas que tener estos estados intermedios. Porque en el lado izquierdo, ese deslizador se ve un poco lento, y definitivamente hay una especie de desincronización entre la capa Native y la capa de React JavaScript. Así que también puedes usar cosas como transiciones para reducir la prioridad del renderizado que no necesariamente necesitas dar retroalimentación instantáneamente. Y de esa manera no bloqueas el hilo Native.

Así que puedes ver en el lado derecho, lo que está sucediendo es que está esperando que muevas el deslizador completamente y luego renderiza el mayor lote de cosas, mientras que en el lado izquierdo está yendo a medida que desplazas. Y así, estos son los tres tipos de pasos dentro de este nuevo renderizador que necesitas tener en cuenta, y aquí es donde el bucle de eventos se conecta con esto. Hay una etapa de render, luego hay una etapa de commit, y hay una etapa de mount. Ahora, la etapa de render realmente está ocurriendo tanto en la capa de JavaScript, solo está generando ese árbol de React que tienes, que es el objeto JSON que define la estructura de tu aplicación React o tus componentes que tienes. En la capa de commit, estás haciendo cosas como el layout y el tree diffing, y luego en los mounts, estás montando la capa Native en las plataformas host nativas.

Así que ese es el nuevo renderizador, lo que nos deja con el nuevo bucle de eventos, que es el tema de esta charla. Y el nuevo bucle de eventos cambia los pasos que React Native en su conjunto toma cuando intenta renderizar cosas en el hilo de JavaScript, y ese trabajo comienza a sincronizarse cuando se renderiza con la plataforma host. Así que lo veremos en un segundo. Ahora, el nuevo bucle de eventos está fuertemente inspirado en las especificaciones de HTML, por lo que básicamente realmente está tomando mucha inspiración del bucle de eventos de JavaScript real.

Así que JavaScript, como sabes, es un lenguaje de un solo hilo, lo que significa que solo puede ejecutar una cosa a la vez, y el código se ejecutará secuencialmente, ¿verdad? Así que cuando miras una pila de llamadas que tienes, las cosas se empujarán a esa pila, y luego tendrán que ir de arriba hacia abajo en lo que es su mecanismo de primero en entrar, primero en salir, ¿verdad? Y así, si miras un ejemplo, si tienes un montón de funciones que se llaman entre sí, la pila de llamadas se ve algo así. Así que tienes la ejecución principal, luego entras en la primera función, luego hay un console.log, así que podemos simplemente ejecutarlo inmediatamente. Lo sacaremos de la pila, luego empujaremos la segunda llamada allí. Luego entraremos en la segunda función, hay otro console.log. Podemos ejecutarlo inmediatamente, porque es como un nivel de hoja, así que nos desharemos de eso. Luego añadimos otra cosa a la pila de llamadas, porque queremos entrar en otra función, así que entraremos en la tercera, console.log eso, y luego podemos comenzar a sacar las cosas de la pila, porque hemos llegado al final de cada una de estas funciones. Así que uno por uno, pasaremos, nos desharemos de eso, y habremos terminado.

Y así, cuando ves que se lanza un error en algún lugar en JavaScript también, ahí es donde ese tipo de seguimiento de pila proviene. Te está diciendo dónde en la pila de llamadas de diferentes funciones que has llamado, de dónde básicamente se origina ese error si bajas por el árbol. Y como podrías haber visto con React Native a veces, si haces esto incorrectamente, puede ser bastante perjudicial. Así que puedes tener algún tipo de código roto aquí, que llama a A primero, luego llama a B, y B parece llamar a A de nuevo recursivamente, así que puedes simplemente seguir con esto, y luego terminarás viendo esto, ¿verdad? Todo es porque JavaScript es de un solo hilo. Es solo porque puede pasar por esta pila de llamadas y solo puede hacer una cosa a la vez, y si sigue pasando por ese proceso en un bucle, a veces puedes simplemente bloquear la pila de llamadas.

Así que entonces surge la pregunta, bueno, es de un solo hilo, ¿cómo hacemos estas tareas de larga duración como hacer llamadas de red o realizar un cálculo realmente pesado? Y ahí es donde entra el segundo componente de JavaScript, que es que es asíncrono, ¿verdad? Así que a pesar de ser de un solo hilo, JavaScript también es asíncrono, lo que significa que si quieres manejar operaciones como hacer llamadas de red o cosas que podrían bloquear una pila de llamadas, en realidad puedes hacerlo de forma asíncrona. Y ahí es donde entra en juego el bucle de eventos. Así que si tienes un setTimeout, que es un ejemplo básico de ejecutar una operación asíncrona con el bucle de eventos en proceso, si pasamos por el mismo proceso, tenemos la ejecución principal de todo el programa, luego haces un console.log para primero, luego llamas a un setTimeout. Ahora el setTimeout no va a hacer nada en la pila de llamadas. En su lugar, lo que hace es que va al tiempo de ejecución del navegador, y dice, básicamente empuja un temporizador allí, y se deshace de ese setTimeout de la pila de llamadas. Así que ahora está ejecutándose en algún lugar dentro del navegador, dentro del motor de JavaScript, y ya no está bloqueando la pila de llamadas.

Y así, el contenedor V8 o cualquiera que sea tu entorno, está a cargo de esperar a que ese temporizador suceda. Así que ejecuta algún código dentro de ese entorno para decir, espera aquí dos segundos. Mientras tanto, puedo ejecutar console.log segundo aquí. Así que entra en el siguiente, se deshace de eso. Y una vez que ese temporizador ha terminado, puede empujar esa devolución de llamada que le he proporcionado a la cola de devoluciones de llamada. Y ahí es donde entra en juego el bucle de eventos. Así que el bucle de eventos revisa la pila de llamadas y dice, ¿hay algo en la pila de llamadas que se esté ejecutando actualmente? Y si está vacía, lo que hará es mirar a través de la cola de devoluciones de llamada y empujar cosas hacia arriba en la pila de llamadas para ejecutar. Así que he empujado de nuevo mi función allí, la función tiene un console.log, lo ejecuta, y luego puede limpiar la pila de llamadas. Y así es como maneja el comportamiento asíncrono. Así que realmente el bucle de eventos de JS es muy simple. Lo que hace es revisar si hay algo en la cola de devoluciones de llamada. Y si la pila de llamadas está vacía, básicamente empuja todas las devoluciones de llamada en tu pila de llamadas y comienza a ejecutarlas.

Entonces, cuando dices un set timeout de 2000, no está garantizado que se ejecute en dos segundos. Está garantizado que se empujará a la cola de devoluciones de llamada en dos segundos, pero será cualquier cosa mayor a dos segundos. Podría haber otras cosas ejecutándose en la pila de llamadas. Y si la pila de llamadas no está vacía, entonces simplemente espera, ¿verdad? Así que ese es el bucle de eventos de JS muy rápidamente.

Pero, ¿cómo funciona el bucle de eventos de React Native? Ahora, antes teníamos el bucle de eventos, renderizabas en estos tres hilos diferentes y en estos tres órdenes diferentes. Así que renderizabas y hacías el mecanismo de renderizado. Así que hablamos de las tres etapas. Renderizabas en el hilo de JavaScript. Luego, en un hilo de fondo, hacías el commit. Así que eso maneja los árboles de diseño y define y diferencia los árboles de diseño. Y finalmente, montabas dentro del hilo de la interfaz de usuario y hacías eso en la capa nativa. Así que montabas esos componentes nativos anfitriones.

El desafío aquí es, digamos que tu hilo de JavaScript en este punto decide hacer otra representación o hacer algunos cálculos más. Esta pintura que está ocurriendo la segunda vez o esta representación que está ocurriendo la segunda vez no sabe realmente ninguna información sobre la pintura que fue causada por la representación anterior. Así que podría tener datos obsoletos porque el montaje no se ha completado en el hilo de la interfaz de usuario. Así que podría estar accediendo a algunos datos que simplemente no son relevantes y no son información correcta. Y así, la información de diseño no estará disponible en este punto o será de una representación anterior. Y esto podría suceder varias veces y en diferentes puntos de tu aplicación, tendrás la información de diseño incorrecta.

Así que el código como este donde básicamente estás usando un use layout effect para obtener el rectángulo delimitador de los componentes en la pantalla no funcionará correctamente y verás un parpadeo de la interfaz de usuario o simplemente será completamente incorrecto cuando intentes obtener esa información, almacenarla en un estado y luego devolverla a otro componente. Así que este es un ejemplo de un tooltip. Si quisieras posicionar este tooltip correctamente donde está el botón rojo, esto no funcionaría con la arquitectura antigua porque la información de diseño no estará disponible. Lo que hace el nuevo bucle de eventos es muy similar. Lo que hace es básicamente seguir un ciclo. Así que toma la tarea que tienes dentro de una especie de cola de tareas que React quiere que ejecutes y ejecutará esa tarea. Buscará cualquier micro-tarea, y explicaré eso en un segundo, y luego actualizará la representación. Así que esos son los cuatro pasos. Esto es directamente de los documentos allí. Y así, lo que parece es algo como esto. Vamos a empezar con solo tareas y micro-tareas y luego lo cambiaremos a términos más sustanciales y comprensibles. Así que tienes una tarea.

Lo que hace es básicamente tomar esa tarea de la cola, comenzarla con el bucle de eventos y luego comienza a verificar si hay alguna micro-tarea que corresponda a esa tarea específica. Así que tienes micro-tareas 1.1, 1.2 y 1.3. Entonces, lo que hará es que una por una, las revisará. Aunque hay una tarea en la cola que es una tarea más grande y no es una micro-tarea, aún ejecutará todas las micro-tareas antes de pasar a la tarea dos. Así que eliminará eso, eliminará la siguiente, y luego montará ese componente.

Así que la clave real aquí es el tercer paso, que es ejecutar todas las micro-tareas programadas. Porque si ponemos esto en un ejemplo concreto, digamos que estamos hablando de ese botón y el ejemplo del tooltip, podrías tener una tarea de renderizar el botón con el componente tooltip en algún lugar. Esta es la representación interna de React y la representación de los Reconcilers, pero solo estoy dando un ejemplo aquí para hacerlo más comprensible. Así que digamos que estás tratando de renderizar el botón con el componente tooltip. Ahora, lo que podrían hacer es decir, de acuerdo, tenemos algunas micro-tareas para un use effect y un use layout effect. Entonces, lo que hará es tomar eso primero, procesarlo con el bucle de eventos, procesar el use effect, procesar el use layout effect después, y luego y solo entonces realmente montar el botón con el componente tooltip, en lugar de pasar por estos de manera asincrónica. Y este modelo realmente funciona bien porque ¿qué pasa si un efecto desencadena otro efecto, verdad? Así que tenemos una micro-tarea que puede desencadenar otra micro-tarea.

Bueno, este modelo y este bucle de eventos manejan esa situación. Así que si pasas por los mismos pasos, sacas esa representación de React, la pasas por el bucle de eventos, esa es la tarea principal, luego pasas por el use effect, luego pasas por el use layout effect, pero ese use layout effect realmente desencadena otro use effect. ¿Cómo sucede eso? Tal vez ese use layout effect cambie un estado dentro de tu componente de React que realmente necesita desencadenar otro use effect que tienes allí. Entonces, lo que puede hacer es empujarlo a la cola de micro-tareas, y porque es relevante para esa tarea específica, simplemente superará a cualquiera de las otras tareas que estaban previamente allí y cualquiera de las otras micro-tareas que estaban allí. Y así puedes tomar ese proceso para usar layout effect como estabas, procesar el use effect, y solo entonces manejar la representación real y el montaje allí. Y esto te permite corregir ese comportamiento sincrónico y asincrónico, el comportamiento asincrónico que tenías, y hacer que todo se ejecute de manera asincrónica, hacer que todo se ejecute de manera sincrónica para cada actualización atómica de la interfaz de usuario que tienes.

Y así, una vez que tienes un bucle de eventos bien definido, el equipo de React Native ahora puede programar partes del código JavaScript dentro de los componentes de React para ejecutarse en momentos específicos, y pueden marcar cosas como tareas y marcar cosas como micro-tareas, y realmente pueden obtener control sobre el horario de ejecución para cada una de estas diferentes tareas. Y usando esto, cada iteración del bucle de eventos realmente puede simplemente actualizar una sola actualización atómica de la interfaz de usuario. Así que directamente desde la documentación, lo que esto significa es que refs, efectos de diseño y efectos pasivos ahora tendrán acceso a la información de diseño de los componentes que se renderizan sincrónicamente, y esperarás y bloquearás la pintura hasta que esto se complete. Y así, esto combinado con el nuevo renderizador realmente significa que puedes tener un modelo de subprocesos realmente interesante también. Así que si tienes un JS, digamos que tenemos un hilo JS y un hilo de interfaz de usuario aquí, si tienes un evento que necesita que cambies algunas cosas en la pantalla, lo que puedes hacer es manejar el renderizado en el hilo JS, luego puedes comprometer, y luego montas. Así que este es el predeterminado. Haces algunas cosas en el hilo JS, y luego montas en la capa nativa.

Pero con este nuevo modelo, también puedes mover todo al hilo de la interfaz de usuario si hay un evento de alta prioridad que está ocurriendo. Así que si el usuario toca un componente nativo en algún lugar y necesita retroalimentación instantánea, puedes simplemente mover la ejecución al hilo de la interfaz de usuario. Pero al soportar estos múltiples hilos, React puede realmente comenzar a interrumpir y priorizar para renderizar los más urgentes. Así que si estás calculando algo en el hilo JS y hay un evento de alta prioridad en el hilo de la interfaz de usuario, puedes activar ese evento en el hilo de la interfaz de usuario y luego completar tu renderizado JS porque todo esto se hace de manera sincrónica.

Puedes completar el renderizado en el hilo JS y realmente hacer un solo montaje al final. Así que te deshaces de muchos de estos estados intermedios que existían antes que causarían parpadeos y no se verían bien o simplemente estarían completamente incorrectos. Y así, nuevamente, la clave aquí es que los diseños se pueden leer de manera sincrónica, lo cual no era el caso antes. Y simplemente llevó a un montón de comportamientos extraños que no estaban en línea con el modelo de programación de React.

Ahora, podrías preguntarte, ¿por qué en el nombre de Dios esto importa? Hay algunas cosas diferentes. Así que los dos, si miras el RFC directamente, hay dos consecuencias principales importantes. La primera es que React Native ahora comienza a comportarse mucho más como React DOM. Antes de esto, los comportamientos eran muy, muy diferentes. La información de diseño no estaba disponible cuando estabas ejecutando efectos de diseño y la pintura no estaba bloqueada. Todo esto sucedería en React. Y así, estas diferencias están siendo eliminadas y las cosas se están alineando más con React. Así que esta alineación con la especificación web y la alineación con React está realmente muy en línea con hacia dónde se dirige el resto del ecosistema de React Native. Hubo un RFC, creo que fue el año pasado, donde hubo un movimiento para tratar de impulsar las API web en React Native y tratar de estandarizar en torno a las API web, en lugar de tener estas API de capa nativa que no están estandarizadas en torno a ningún tipo de especificación. Y así, eso todavía está en marcha. Todavía hay mucho interés en ese RFC. Y así, hay este impulso general. Si miras al equipo central de React Native, también están trabajando en, como vimos en la última masterclass, React Strict DOM. Así que una forma en la que puedes intentar usar código de interfaz de usuario común en React y React Native, y en lugar de usar React Native web, encontrar una solución mejor y más eficiente para eso. Y esto ya está siendo utilizado por Meta en producción. Así que hay este impulso. Y nuevamente, Meta no vive bajo este mantra de escribir una vez, ejecutar en cualquier lugar. Pero en general, el ecosistema se está moviendo en esa dirección, donde el código de React y React Native puede estar más y más alineado. Y puedes usar... Puedes básicamente... Los desarrolladores que están familiarizados con React pueden cambiar a React Native más fácilmente y viceversa. Porque realmente es solo un paradigma, y es todo React universal.

Así que este es el objetivo final y el sueño que creo que todos están mirando dentro de la comunidad. Pero por qué es más importante, quizás lo más importante, es que finalmente puedo alinear mis tool tips usando el efecto useLayout. Muchas gracias a todos por su tiempo.

Esta primera pregunta es, ya sabes, como explicaste hacia el final que la nueva especificación del bucle de eventos lo alinea más estrechamente con la web. Pero ¿es el comportamiento desde el punto de vista del desarrollador idéntico ahora? Como si uso QMicroTask o lo que sea, ¿debo esperar los mismos comportamientos exactos en la web? Sí. Así que abre las capacidades de eso. Ahora, no necesariamente... Esto está más orientado hacia, posiblemente, desarrolladores de bibliotecas. Pero sí, podrías... El objetivo completo es que React Native bajo el capó cuando se ejecuta dentro del motor de JavaScript maneja microtareas, y tiene una cola de prioridad para ejecutar cosas. Así que ahora el soporte completo de microtareas va a ser bastante útil, porque es una implementación real de microtarea. Si intentaste encolar microtarea antes, lo que sucedería es que solo usaría algún tipo de polyfill y usaría un temporizador o algo bajo el capó para hacer que pareciera una microtarea, pero no era una microtarea real. Y así que ahora tienes una implementación real, lo cual es bastante bueno.

Bien. Bueno, entonces hay una pregunta para, ya sabes, personas que migran a nuevas arquitecturas. ¿Cuáles son las implicaciones prácticas para los desarrolladores? Recuerdo en los días oscuros de React Native, ya sabes, usaba mucho setTimeout para arreglar muchos errores extraños. Y ahora esos setTimeouts probablemente todavía viven en algún lugar de las bases de código, y luego alguna pobre persona va a... ¿Eran todos setTimeout ceros también? Sí, sí. Y no, a veces pongo un número diferente que solo proporciona... Solo por diversión. Sí, sí, solo para sorprender, ya sabes. Solo para confundir realmente al desarrollador cuando se rompe. Exactamente. Así que ahora digamos que este desarrollador está actualizando la nueva versión. Es como, ¿qué deben esperar? Ya sabes, ¿cuál es el cambio de comportamiento aquí? Así que obviamente la nueva iniciativa de arquitectura ha estado en marcha desde 2018, cuando la anunciaron por primera vez. Y no se ha hecho predeterminada hasta ahora. Así que seis años después. Y creo que la razón de esto fue que realmente estaban tratando de asegurarse de que no hubiera cambios fundamentales para ti si tienes una base de código existente como desarrollador de aplicaciones. Así que trabajaron muy duro con los mantenedores de bibliotecas para asegurarse de que hubiera un soporte adecuado. Que estuviera bien probado, trabajado a fondo. Y que no hubiera sorpresas masivas para los desarrolladores de aplicaciones. Y así creo que muchas iniciativas se han llevado a cabo para tratar de hacerlo lo más fluido posible. Así que si realmente pasas y actualizas, ya sabes, tu aplicación, la afirmación y el objetivo de Meta, al menos, es que esta actualización no debería ser más difícil que cualquier otra actualización de React Native que hayas hecho. En la práctica, podría significar ciertas bibliotecas que no lo han adoptado. Si estás usando una biblioteca de nicho que no está siendo mantenida activamente por el mantenedor de la biblioteca, probablemente tendrás algunos problemas, pero hay capas de interoperabilidad aquí. Creo que desde una perspectiva de código de aplicación, probablemente no estabas usando cosas como use layout effect antes de todos modos, porque no estaría funcionando. Así que lo que esto hará es que hará que el código que tienes sea más eficiente, porque manejará cosas como el batching por ti, y hará suspense mejor, porque tiene mecanismos de suspense completos. Así que creo que generalmente tendrá mejoras positivas, a menos que estés usando algunas bibliotecas que realmente no se están manteniendo activamente más.

Genial, fantástico. La pregunta más popular que tenemos aquí es, de hecho, dos personas preguntando más o menos la misma pregunta, que es como, ya sabes, después de este nuevo descubrimiento sobre use layout effect y luego actualizar a la nueva versión, ¿alguna vez volviste a ejecutar tus benchmarks desde el inicio de la charla y descubriste cuál fue el cambio? Lo hice antes de que la nueva arquitectura incluso saliera, pero tenías que hacerlo de una manera diferente. Así que necesitabas ir y crear como un componente nativo que lo midiera en el lado de la pintura nativa, lo cual fue algo de lo que el equipo central de React realmente me dio algunos ejemplos de. Y mejoró marginalmente el rendimiento de React Native, aproximadamente un 15, 20%, si recuerdo correctamente. Espero que probablemente podría intentar ejecutarlo de nuevo con use layout effects. ¿Mejoró el rendimiento, o solo mejoró tus mediciones? Solo soy el mensajero aquí, ¿de acuerdo? Claro, sí. Lo siento por eso.

Bien, aquí está la pregunta. Creo que esto podría estar relacionado con el tipo de gráfico visual que mostraste sobre como el diferente orden de operaciones donde primero ejecutas la tarea, luego la cola de microtareas y luego llegas al renderizado. ¿Es posible que accidentalmente ralentizamos nuestro renderizado usando patrones al esencialmente terminar encolando demasiado trabajo de alguna manera?

Esto fue en realidad, así que si miras como el RFC que hicieron para esto y luego el trabajo que realmente pusieron, había una persona, no sé si era parte del equipo de React o si era solo un miembro de la comunidad que estaba muy como, esto podría ser realmente peligroso porque podrías estar bloqueando como la amenaza de JF por un tiempo realmente largo si hay este tipo de cola de eventos que desencadenan cosas una y otra vez. En general, parecía que realizaron algunas pruebas y no tuvo un efecto masivamente perjudicial.

Hay una advertencia, que es que si creas un componente de React como desarrollador que encola un montón de microtareas y bloquea el hilo, entonces podría retrasar las pinturas bastante significativamente. Pero creo que el equipo de React aquí pensó que era mejor que se alineara con cómo React se comporta porque así es como React se comporta. Si encolas cosas como microtareas una y otra vez, puedes retrasar las pinturas que están sucediendo en el navegador. Así que creo que la prioridad fue intentemos hacerlo consistente con cómo se comporta el navegador. Pero como sabes, no hay un uso legítimo de las características de React que llevaría a eso. No que yo sepa. Sería considerado y clasificado al menos por el equipo central de React como un error o código ineficiente que probablemente deberías corregir, es mi entendimiento de leer las discusiones que tienen allí.

Genial. Increíble. Bien. Así que nos queda una última pregunta. Y antes de hacerla, tengo que dar un poco de advertencia de contenido y tal vez preguntarte, ¿encuentras los juegos de palabras desencadenantes? ¿Cómo te sientes acerca de los juegos de palabras? Soy ambivalente a ellos, pero a veces ellos- Bien. Bueno, si alguien encuentra los juegos de palabras desencadenantes, entonces podría ser un buen momento para irse. Si la pila de llamadas está bloqueada, ¿puedes usar la mención de software en su lugar? Oh, Dios mío. ¿Era el tipo de la pila de llamadas sentado aquí? No, ¿no puedes? Bien. Bien. ¿Necesitamos explicar el chiste primero? Todos conocen la mención de software de la pila de llamadas, levanten la mano. Las dos grandes consultorías polacas de React. Sí, consultorías. Sí. Genial. Eso fue un buen marketing allí. Estoy impresionado con ustedes. Sí. No voy a comentar sobre eso. No voy a comentar sobre la multitud.

No. Trabajo en otra consultoría, así que no voy a comentar sobre eso, desafortunadamente.

Sí. ¿The Odo se llama? The Odo. The Odo, sí. Theodore en realidad. Theodore. Bien.

Bien. Bien. Bueno, creo que se nos está acabando el tiempo y nos hemos quedado sin preguntas. Creo que la última ya fue un paso demasiado lejos. Estoy profundamente decepcionado con el público. Vamos todos ahora a tomar un café. Así que tenemos 20 minutos para una pausa para el café. Tengo un pequeño, bastante pequeño anuncio si se quedan 30 segundos. Pero podemos darle un aplauso a Mo y dejarlo ir. Bien.