Llevando la Nueva Arquitectura de React Native a la Comunidad de OSS

Hola a todos. Muchas gracias por estar aquí. Como escucharon antes, el tema candente en el Ecosistema de React Native es la nueva arquitectura. Así que hoy tengo el placer de hablar sobre cómo llevar la nueva arquitectura a la comunidad de código abierto. Y bueno, es posible que ya hayan visto esta charla antes a principios de año, pero muchas cosas han cambiado y mi equipo, el equipo de React, ha estado desarrollando muchas características nuevas y mejoras para que puedan disfrutar de la nueva arquitectura. Así que hoy nos vamos a centrar en algunas de esas también. Y bueno, un par de palabras sobre mí, como mencioné, soy un ingeniero de Android en el equipo de React Native, pueden encontrarme en línea como Kurtinico en Twitter y en GitHub. Así que empecemos porque tenemos mucho que cubrir. Y si buscaran 'React Native nueva arquitectura' en Google o en YouTube hoy, encontrarán bastante contenido y en realidad quiero centrarme en algunos de ellos. Específicamente en YouTube, encontrarán esos videos. Y si miran las fechas, son bastante indicativas de cuánto tiempo hemos pasado construyendo la nueva arquitectura. Empezamos a hablar de ello en 2018, pero recién en 2021 implementamos completamente la nueva arquitectura internamente. Y bueno, esto es un testimonio de lo complicada que es realmente esta nueva arquitectura. Y sí, quiero enfatizar nuevamente la línea de tiempo aquí. Empezamos en 2018 en el segundo trimestre, y esto comenzó inicialmente como un proyecto de seis meses. Literalmente hacemos planificación cada medio año en Meta y Facebook en ese entonces. Y simplemente pensamos que sí, en seis meses lo lograremos y actualizaremos las partes internas y nos beneficiaremos de ello y todos estarán felices. Eso no resultó ser del todo cierto porque específicamente dentro de la aplicación de Facebook, React Native se utiliza extensivamente en miles de superficies y los ingenieros de producto han estado exprimiendo cualquier posible mejora de rendimiento de React Native, de la antigua arquitectura ya. Así que intentar cambiar el motor mientras el avión volaba bastante rápido resultó ser realmente desafiante.

Así que nos llevó casi tres años y luego dijimos, bueno, ya terminamos. Increíble. ¿Cómo permitimos ahora que la comunidad de código abierto lo use? Y, bueno, aquí es básicamente más o menos donde entré en el equipo y me di cuenta de que esto es realmente un desafío asombroso y bastante intrincado. Así que hoy nos vamos a centrar en cuáles son esos desafíos en detalle, qué hay en tu arquitectura y qué estamos haciendo para permitir que la comunidad de código abierto lo use. Entonces, si Gant aún no te ha convencido de por qué deberías investigar la nueva arquitectura, permíteme reiterarlo. La nueva arquitectura se trata de eliminar el cuello de botella del puente. Además, tomamos una postura y realizamos algunos cambios arquitectónicos bastante importantes, que afectarán a todos los desarrolladores de React Native. Primero, reescribimos nuestras partes internas utilizando un lenguaje de programación multiplataforma, en este caso, C++. Esa también es la razón por la cual muchos desarrolladores vinieron a nosotros y nos dijeron: ¿por qué veo código C++ en mi proyecto? No estoy seguro de querer ver eso. Pero lo bueno de esto es que ahora podemos escribir características y optimizaciones solo una vez en nuestro renderizado compartido, y asegurarnos de que

todas las plataformas que utilizan React Native se benefician de ella. Por ejemplo, la optimización de la vista, anteriormente solo disponible en Android, ahora se puede aprovechar en iOS gracias a que la hemos escrito en C++ y se comparte en todas las plataformas. También queríamos introducir la seguridad de tipos en nuestra arquitectura. Queríamos eliminar las referencias de cadena en todos los lugares posibles, y esto es posible gracias a un componente llamado CodeGen, que genera código a partir de una representación de la API que proporcionas a React Native. Por último, debes considerar la nueva arquitectura como la piedra angular para muchas nuevas capacidades que lanzaremos en el futuro. Algunas de ellas aún no se han lanzado, otras están en desarrollo, pero habrá muchas nuevas características basadas en esta nueva arquitectura. Es crucial que todos los usuarios migren a esta nueva arquitectura, ya que no se beneficiarán de las nuevas mejoras a partir de ahora. Entonces, ¿en qué consiste exactamente la nueva arquitectura? La llamamos así porque es un término general que nos ayuda a referirnos a un conjunto de pilares. El primero es nuestro nuevo renderizador, llamado fabric. Lo encontrarás en todas partes, en la web y en nuestra documentación. Luego, reescribimos el sistema de módulos nativos y lo llamamos turbo module. También introdujimos un componente para proporcionar seguridad de tipos en nuestra fórmula, llamado code gen. Y cuando todo esté en su lugar, cuando todos tus componentes sean compatibles con fabric y todos tus módulos sean compatibles con turbo modules, podrás prescindir del puente y eso es lo que llamamos el modo sin puente. Profundizar en cada uno de estos pilares llevaría mucho tiempo, pero quiero darte una idea de la seguridad de tipos a la que me refería antes. Así que me centraré un poco en el code gen. La idea detrás del code gen es que te permite escribir un archivo de especificación, una representación de cómo debería ser tu API. En este caso, proporcionarás un archivo de especificación que responderá a la pregunta definitiva, y lo registrarás. El code gen trabajará específicamente en esta función y entenderá que espera una entrada de cadena y devuelve un número como salida. A partir de esta información, el code gen generará código para Android e iOS. En Android, se verá así. Básicamente, es una clase abstracta en Java donde nos encargamos de todo el código de plantilla, como constructores, y generamos un método abstracto llamado answer the ultimate question. Entendemos los tipos y proporcionamos los tipos específicos de la plataforma, en este caso, cadena y doble. Esto es abstracto porque no podemos escribir mágicamente tu lógica empresarial.

pero podemos ayudarte a escribir todo el esqueleto alrededor. En iOS, la historia es muy similar. Vamos a crear un protocolo Objective-C que, una vez más, comprenda los tipos y proporcione tus tipos específicos de plataforma, como NSString y NSNumber. A medida que implementamos la nueva arquitectura, nos dimos cuenta de que no se trata solo de esos componentes principales. Hay muchos otros aspectos y cosas en las que tenemos que investigar, uno de ellos son las herramientas de compilación. Las cosas meta son un poco diferentes internamente en comparación con cómo son en el espacio de código abierto. Específicamente, dentro de Meta, construimos todo con Buck. Pero no podemos esperar que las personas en el código abierto usen Buck para construir todo. Por eso tuvimos que tomar una postura en nuestro sistema de compilación.

y extenderlos. En Android, trabajamos mucho en Gradle, y sí, verás muchos cambios en nuestro pipeline de Gradle. Específicamente, introdujimos archivos CMake. Estos son necesarios para compilar código C++. También hay mucho código en Java y Kotlin, como siempre. Y esto es construido por el plugin Gradle de React Native, que es nuestro nuevo punto de integración de compilación para Android. Y esto está destinado a reemplazar el archivo Gradle de React, que era obsoleto e histórico. Y este es esencialmente el componente responsable de invocar la generación de código, permitirte optar por la nueva arquitectura, y demás. En iOS, de manera similar, trabajamos mucho en nuestra integración de Cocoapods. Escribimos muchos scripts en Ruby, escribimos mucha infraestructura de compilación heredada aquí. También la razón por la que menciono esto es porque podrías decir, sí, obviamente tienes Cocoapods y cosas de Gradle, pero de lo contrario la gente puede compilar. Este es uno de los primeros puntos de falla de React Native. Como, cuando, una de las mayores preocupaciones que recibimos es, actualizo. Nada se compila más. Bueno, había mucho código heredado que dentro de la arquitectura tomamos una postura, escribimos, escribimos muchas pruebas para ello. Así que con suerte las cosas mejorarán con el tiempo. También revisamos nuestro motor JavaScript. Y sí, hicimos mucho trabajo con el equipo de Hermes. Hermes es nuestro motor JavaScript interno. Actualmente se recomienda para la nueva arquitectura. Entonces, si lees la documentación, se señalará como uno de los componentes que debes usar. A partir de React Native 0.69, hicimos muchos cambios dentro de React Native y desarrollamos lo que se llama Hermes empaquetado. Esto significa que para cada versión de React Native estamos preparando una versión de Hermes que es completamente compatible con ella. A partir de React Native 0.70, también es el motor predeterminado. Si no quieres usarlo, tendrás que desactivarlo. La razón por la que menciono esto es porque, nuevamente, no es necesario para la arquitectura, pero se recomienda encarecidamente porque es donde estamos analizando más de cerca nuestra experiencia de depuración y donde tenemos un equipo dedicado que puede ayudarnos a comprender qué está sucediendo si tienes un fallo con Hermes activado. Si no tienes Hermes, será difícil para nosotros priorizarlo y será más difícil solucionar el error. También algunas actualizaciones en los lenguajes de programación. Porque este es un tema bastante peculiar y, nuevamente, muchos desarrolladores nos están pidiendo que usemos su lenguaje de programación favorito con React Native. Y aquí tenemos actualizaciones en cada capa. En la web, bueno, TypeScript.

Cuando lanzamos la primera versión de la nueva documentación de arquitectura, el comentario número uno fue: No quiero escribir mis especificaciones en Flow. Gracias. Y entiendo completamente eso. Es por eso que dedicamos tiempo a escribir una versión del código que entiende archivos de especificación en TypeScript. Así que hoy puedes escribir archivos de especificación en TypeScript y todo funciona. En este punto, también, React Native 0.71 incluirá tipos de TypeScript empaquetados en el paquete NPM, con suerte facilitando la vida de los desarrolladores de React Native.

En la capa de plataforma en Android, tenemos Kotlin. Personalmente, soy un gran fanático de Kotlin. Estoy feliz de hablar más al respecto después si quieres saber más. Pero ya está completamente soportado en React Native, por lo que puedes escribir tu aplicación en Kotlin y ya no necesitas Java. También reescribimos todo el sitio web para que sea bilingüe. Esto fue un esfuerzo impulsado por la comunidad y recibimos muchas solicitudes de extracción para convertir nuestros fragmentos de código de solo Java a Java y Kotlin. Ahora encontrarás ejemplos en ambos lenguajes. Y en el futuro, es posible que esperes que la plantilla se convierta realmente a Kotlin. Hay varios beneficios de tener un único lenguaje de JVM en tu flujo de trabajo, por lo que vamos a investigar eso en el futuro. Mientras tanto, para iOS, la situación es un poco más complicada. A la gente le encantaría usar Swift y estamos investigando eso. El problema aquí es el soporte de interoperabilidad entre Swift y C++. Hay actualizaciones, pero aún no tenemos nada que compartir en esta etapa.

Así que ahora he hablado mucho sobre actualizaciones y cosas que están por venir. En realidad, quiero hacer mi punto un poco más concreto hablando sobre la línea de tiempo, como cuándo sucedieron las cosas. Así que veamos las versiones de React Native que lanzamos y lanzaremos en el futuro. A principios de este año lanzamos React Native 68. Esta es la primera versión de React Native que agrega soporte para la nueva arquitectura. Teóricamente, la nueva arquitectura ya estaba allí desde React Native 64, aunque era muy difícil de usar, por lo que la versión 68 es la primera versión que agrega una línea de código que te permite habilitar o deshabilitar la nueva arquitectura. A partir de ahí, recibimos toneladas de comentarios y la gente nos dijo que esto es genial, pero... y esos `peros` se convirtieron en características que desarrollamos y lanzamos en las versiones siguientes. Así que en React Native 69 lanzamos un par de cosas críticas. La primera es el soporte de React 18. Por lo tanto, la versión 69 es la primera versión

de React Native que admite React 18. Voy a hablar sobre las versiones de React 18 y React Native en la siguiente diapositiva, pero también otra característica es el dermis de paquete. Entonces, mejor soporte para firmas dentro de React Native. Luego, la versión 70. La versión 70 fue un lanzamiento importante para la nueva arquitectura porque nuevamente, toneladas de características que eran realmente críticas. Primero, dermis como predeterminado. Luego, agregamos soporte para autoenlace en Android para bibliotecas nativas. Entonces, antes de la versión 70, tendrías que enlazar manualmente tus bibliotecas de la nueva arquitectura, lo cual era bastante doloroso. Tuvimos soporte completo para CMake y el código y la configuración unificados. Entonces, para hablar brevemente sobre este último punto, antes de la versión 70, tenías que especificar el código y la configuración para Android y para iOS en dos archivos diferentes, lo que hacía que las cosas estuvieran realmente fragmentadas. Así que escuchamos a la comunidad y pensamos, bueno, esto es una mala experiencia para el desarrollador, así que vamos a solucionarlo. Y eso salió en la versión 70.

Pero entonces, ¿qué sigue? Así que tenemos la versión 71. La versión 71 se lanzará muy pronto. No sé cuándo, pero en un futuro cercano. Y, bueno, ya tenemos algunas cosas planeadas. Primero, la nueva plantilla de la aplicación se simplificará enormemente en la versión 71. Uno de los comentarios que recibimos fue que cuando creo un nuevo proyecto, veo siete archivos C++ y no sé qué hacen. ¿Necesito tenerlos aquí? ¿Necesito saber qué hacen? Y así sucesivamente. Y sentimos que probablemente no necesitamos exponer los archivos C++ a nuestros usuarios. Podemos intentar mejorar y encapsularlos. Este es uno de los cambios entre muchos que estamos implementando en la versión 71. Entonces, nuevamente, en la versión 71 nos estamos enfocando en nuestra nueva arquitectura y haciendo las cosas más fáciles para nuestros desarrolladores. Y hay muchos otros cambios que se describen en las notas de la versión 71.

Y luego la versión 72. Bueno, con el infinito y más allá, diría yo, porque muchos de esos cambios se han implementado porque la gente nos detuvo en conferencias y reuniones y nos dijo, oye, probé la nueva arquitectura pero no funciona para mí porque, o no puedo migrar mi biblioteca porque esto y aquello. Entonces, por favor, aprovecha la oportunidad. Hoy somos cinco o seis del equipo de React, del equipo de React Native aquí hoy. Entonces, por favor, detente. Dinos si esto no funciona, es una porquería completa, porque, o esto es increíble porque. Así que, por favor, úsanos tanto como puedas.

Así que, prometo hablar brevemente sobre el soporte de React 18 y React Native. Y aquí está. Esta bonita tabla. Entonces, si estás en React Native 67 o 68, estás efectivamente en React 17. El truco aquí es que no puedes simplemente ir a tu package.JSON y cambiar la versión de React, hacer yarn install y pretender que eso funcionará. Así no es como React y React Native interactúan entre sí. React Native vuelve a empaquetar el renderizador de React a una versión que decidimos cuando cortamos la rama de React Native. Entonces, decidimos qué versión de React vas a usar. Así es como sucede la magia. Entonces, si quieres estar en la versión 18, en realidad necesitas estar en la versión 69 o la siguiente característica. Y aquí está el truco. El equipo de React viene con muchas nuevas características concurrentes como nuevos hooks, como start transition, use transition, y así sucesivamente. Si quieres beneficiarte de esas características concurrentes, necesitas estar en la nueva arquitectura. Si estás en la arquitectura antigua, estás usando efectivamente un renderizador heredado de React. Estamos ofreciendo estos dos modos de renderizado para permitir que las personas hagan una transición gradual a la nueva arquitectura. Pero si me preguntaras cuándo es un buen momento para migrar a la nueva arquitectura, ya sabes la respuesta. Es ahora. Así que comienza a investigar al respecto. Porque estamos poniendo mucho esfuerzo en la historia de migración y escuchando a la comunidad. Ahora es un buen momento para hacer migraciones. Más adelante, será más difícil y doloroso. Ahora, veamos algunos de los materiales que hemos preparado para que puedas comenzar con la nueva arquitectura y entender qué hacer. Y permíteme enfatizar cuán importantes creemos que son los documentos aquí. Realmente se trata de los documentos. Recuerdo haber escuchado este episodio de React Native Show y mencionaban cómo algunas bibliotecas ya estaban aprovechando algunas de las nuevas capacidades de la arquitectura mediante la ingeniería inversa de nuestro código, lo cual no es realmente genial. Así que por eso pensamos, OK. Escribamos algunos documentos oficiales. Y encontrarás en el sitio web reactnative.dev una nueva guía en la parte izquierda llamada la nueva arquitectura, que te brinda una introducción sobre esos pilares, qué hacen, por qué los hicimos, y así sucesivamente. Y también hay otra guía justo debajo llamada migración a la nueva arquitectura, que explica tanto a los desarrolladores de aplicaciones como a los desarrolladores de bibliotecas cómo migrar sus componentes y módulos a la nueva arquitectura.

También dedicamos tiempo a escribir documentos arquitectónicos. Estos son otros documentos muy solicitados que no hemos tenido tiempo de escribir en el pasado. Si vas a la pestaña de arquitectura en la parte superior, encontrarás la descripción general de la arquitectura. Y aquí tenemos análisis detallados y páginas que explican cómo funciona internamente Fabric o cómo se integra Hermes, y así sucesivamente.

Actualizamos la nueva plantilla de la aplicación para que puedas comenzar con el nuevo proyecto. Así que creemos que el punto de entrada para la nueva arquitectura debería ser solo una línea cuando creas una nueva aplicación. ¿Cómo se vería? Bueno, vas a crear tu aplicación con React Native en ella, y luego en iOS, el punto de entrada está en el pod install. Entonces, normalmente solo harías pod install en tu proyecto, y estarías bien, mientras que dentro de tu arquitectura, volverás a ejecutar pod install, pero con esta nueva variable arc enabled establecida en true. Luego, una vez que ejecutes iOS, estarás ejecutando efectivamente una aplicación de iOS dentro de tu arquitectura, y podrás comenzar a jugar y así sucesivamente. En Android, una historia similar. Tenemos un archivo llamado Gradle.properties con una línea llamada new arc enabled. Solo cámbialo de false a true, y ejecuta Android, y listo. Y una vez que lo ejecutes, Metro te dirá en la consola que tu aplicación se está ejecutando con Fabric configurado en true y concurrent roots configurado en true. Eso significa que todo está habilitado, experimentarás el nuevo renderizado, todo, magia, cosas increíbles, y así sucesivamente. Y también asegúrate de ver la charla de Lorenzo justo después de la mía, porque ahora te digo, como, sí, esto es increíble. Solo cambia una línea y comienza, todo funciona. Y siempre y cuando no tengas dependencias externas que no se hayan migrado a la nueva arquitectura. Y Lorenzo va a hablar realmente de eso porque es un punto crucial.

Para ayudar a las personas a migrar esas bibliotecas, en realidad, una iniciativa que comenzamos es el grupo de trabajo de la nueva arquitectura. Esto se basa en la experiencia que construimos como parte del grupo de trabajo de React 18 y es esencialmente un repositorio de discusión solo en GitHub al que puedes unirte. Y hay varias secciones. Nuevamente, algunas sobre documentos, algunas sobre bibliotecas. Entonces si eres autor de una biblioteca, puedes unirte, puedes solicitar soporte. Tenemos algunas bibliotecas en el pasado que se quedaron atascadas y así sucesivamente. El grupo de trabajo puede parecer de solo lectura, pero si solicitas unirte usando el enlace en el archivo Léame, revisaremos la solicitud y te dejaremos pasar. Solo estamos haciendo una prevención de spam con este formulario. Y también escribimos algunos ejemplos. Entonces, específicamente, tenemos el repositorio de ejemplos de aplicaciones que es básicamente una aplicación, como una colección de ramas donde en cada rama mostramos cómo migrar una aplicación de una versión de React Native a otra paso a paso. Así que efectivamente verás cada confirmación con un mensaje informativo y instrucciones sobre por qué hicimos ese paso y así sucesivamente. Y estamos haciendo esto para diferentes versiones de React Native para mostrarte cómo estas serie de pasos se reducen a medida que hacemos esta historia de migración más fácil. También tenemos un repositorio de ejemplos de bibliotecas que sigue un enfoque similar pero explica

cómo migrar un componente o un módulo a la nueva arquitectura. Finalmente, nuevamente, en este punto, lo realmente importante de la nueva arquitectura son las bibliotecas. Si dependes de una biblioteca que expone un componente o un módulo que no es compatible con la arquitectura nueva, tendrás problemas. Por eso es crucial que los mantenedores de bibliotecas comiencen a investigar la arquitectura y migrarlas. Ya tenemos un conjunto de bibliotecas que han sido migradas. Estamos recibiendo cada vez más informes de bibliotecas que se están actualizando a la nueva arquitectura. Pero nuevamente, si no has migrado tu aplicación o específicamente tu biblioteca, por favor avísanos qué te está bloqueando y sí, intentemos mejorar esto juntos. Y con esto, realmente espero que en un año a partir de ahora, seis meses a partir de ahora, o cuando busque React Native en tu arquitectura en Google, encuentre tu historia de migración. Nos encantaría escuchar qué funciona para ti y qué no funciona. Estamos haciendo nuestro mejor esfuerzo para escuchar a la comunidad, nuevamente, cuáles son los obstáculos y demás. Pero es crucial que nos cuentes qué funciona y qué realmente no funciona. Específicamente para esto, vamos a tener una sala de discusión hoy con algunas personas de Meta, de Infinite Red, de Microsoft, y demás, para hablar sobre el futuro de React Native en tu arquitectura. Asegúrate de unirte, pasar por allí y vamos a conversar sobre algunas de las cosas que mencioné hoy. Y con esto, quiero recordar que todas nuestras herramientas son de código abierto, y estamos muy emocionados de recibir tantas contribuciones, y quiero agradecerles mucho por escuchar.