Llevando la Nueva Arquitectura de React Native a la comunidad de código abierto

Hola a todos, y muchas gracias por unirse a esta sesión. Hoy vamos a hablar de cómo llevar la nueva arquitectura de React Native a la comunidad de código abierto.

Diapositiva obligatoria sobre mí mismo. Mi nombre es Nicola Corti y trabajo como ingeniero de Android en el equipo de React Native en Meta. Puedes encontrarme en línea como cortinico tanto en Twitter como en GitHub.

Como tenemos mucho que cubrir, vamos directamente al contenido. Así que si buscaras hoy la nueva arquitectura de React Native en Google o en YouTube, encontrarás bastante contenido. Quiero centrarme un poco en YouTube porque hay varios videos que son realmente valiosos. Y como puedes ver, por las fechas, en realidad comenzamos a hablar de la nueva arquitectura de React Native en 2018 en React Conf. Ha pasado mucho tiempo. La última charla es de React Native EU 2021 por mi colega Joshua Gross. De hecho, quiero invitarte a ver la charla si aún no lo has hecho.

Joshua en su charla habló sobre la línea de tiempo de la nueva arquitectura y cuánto tiempo nos llevó implementar esta tecnología, que básicamente es una reescritura importante de los componentes internos de React Native dentro de la aplicación de Facebook. Nos llevó aproximadamente tres años. Así que quiero comenzar desde esta línea de tiempo, desde lo que Joshua dijo en esa charla. Y ¿a dónde vamos desde allí? Mencionó que, nuevamente, comenzamos en 2018 en el segundo trimestre. Inicialmente, este proyecto debía durar aproximadamente seis meses. Pero la realidad es que React Native se utiliza de manera tan extensa dentro de la aplicación de Facebook, y muchos equipos intentan exprimir cada milisegundo de rendimiento de cada pantalla, por lo que implementar un cambio tan grande fue todo un desafío. Por eso nos llevó tanto tiempo.

En 2021, finalizamos la implementación completa de la nueva arquitectura, específicamente el nuevo renderizador fabric en todas las áreas de la aplicación de Facebook. Y luego, bueno, ¿qué sigue? Lo siguiente es que nos enfocamos en la comunidad de código abierto y realmente queríamos permitir que todos se beneficiaran de esta importante reescritura de los componentes internos de React Native. Por lo tanto, lo que sigue es implementar la nueva arquitectura fuera de Meta y capacitar a todos para que utilicen lo que hemos desarrollado hasta ahora. Y ahí es donde estamos ahora. A finales de 2021 y principios de 2022, comenzamos a crear contenido y material para capacitar a las personas fuera de Meta para que utilicen la nueva arquitectura. Así que hoy voy a presentar mucho material y contenido que hemos desarrollado hasta ahora y que te ayudará a adoptar la nueva arquitectura de React Native.

Pero primero, quiero reiterar un poco el por qué, porque me preguntan una y otra vez, ¿por qué debería migrar a la nueva arquitectura? Y si aún no lo has entendido, el por qué tiene que ver con el puente. La nueva arquitectura es básicamente una reescritura importante de muchos componentes de los componentes internos de React Native que nos permite deshacernos del puente. El puente era un componente que permitía la comunicación entre la capa de JavaScript y las capas nativas subyacentes. Con la nueva arquitectura, este componente prácticamente ha desaparecido. Y con eso vienen muchas mejoras en términos de rendimiento y en general, es una reestructuración de los componentes internos del marco. Como reescribimos muchos de los componentes internos, decidimos implementar nuevamente muchos de los pipelines de renderizado y componentes internos de React Native utilizando un lenguaje compartido. Por lo tanto, decidimos utilizar C++ para tener una única implementación del renderizador que nos permite reducir las discrepancias entre las diferentes plataformas. Históricamente, solía haber diferentes renderizadores para Android y iOS, por lo que las cosas se comportaban de manera un poco diferente en las dos plataformas. Gracias a la nueva arquitectura, básicamente tenemos una única implementación de nuestros componentes internos y podemos asegurarnos de que todo lo que desarrollemos sea consistente en las dos plataformas. Del mismo modo, también podemos compartir muchas de las optimizaciones que desarrollamos para una única plataforma en todas ellas. Esto es posible gracias a tener una única implementación del renderizador y los componentes internos. También tomamos una postura en cuanto a la experiencia del desarrollador e intentamos implementar muchas mejores prácticas y combinarlas dentro del componente principal de la nueva arquitectura de React Native. Específicamente, desarrollamos un componente llamado Cogent que nos permite tener seguridad de tipos en nuestra base de código. Y finalmente, la nueva arquitectura es, como dije, sobre el rendimiento, pero también sobre muchas nuevas capacidades que estamos construyendo sobre estas nuevas bases. Es como si hubiéramos tomado una postura, escribimos muchos componentes internos pensando en qué nuevas capacidades nos permite desarrollar en los próximos años. Por lo tanto, cuando nos referimos a la nueva arquitectura, nos referimos a muchos componentes que a menudo llamamos pilares. La nueva arquitectura de React Native está compuesta por varios pilares.

Tenemos Fabric, el nuevo renderizador. Tenemos un nuevo sistema de módulos nativos, al que llamamos Turbo Module. Tenemos un componente que permite generar código, que es el Cogent, y también tenemos el Modo Sin Puente.

Entonces, una vez que todas las piezas están juntas, tenemos la capacidad de eliminar esencialmente el componente de puente, como mencioné antes, esto se llama Modo Sin Puente. Quiero enfocarme un poco en el Cogent y darte una idea de lo que imaginamos como la experiencia del desarrollador en la nueva arquitectura.

Como mencioné antes, la seguridad de tipos, y la idea principal detrás de Cogent es, digamos que el desarrollador está escribiendo un archivo TypeScript que define la API de un módulo nativo. En este caso, definirán una especificación como una interfaz con una declaración de todas las capacidades de este módulo. Por ejemplo, este módulo puede responder a la pregunta definitiva y toma como entrada una cadena y devuelve un número, y el usuario simplemente registrará esto en un módulo.

Cogent trabaja en este nivel. Se enfoca en esta función y en el tipo de entrada y de retorno. Y a partir de eso, genera mucho código base que en el pasado, los desarrolladores tendrían que escribir manualmente tanto para Android como para iOS. Así que echemos un vistazo a eso. En Android, vamos a generar una clase abstracta con un constructor y un método abstracto específico que se adhiere a la firma de la especificación que vimos antes. Así que vamos a tener una función que toma una entrada, una cadena, y devuelve un número decimal. Es una función abstracta, así que depende de ti implementarla y proporcionar la lógica de negocio correcta. De manera similar, en iOS, vamos a tener un protocolo Objective-C que toma como entrada un NSString y devuelve un NSNumber. Así que hacemos todo el trabajo pesado de la escritura de tipos desde la capa de JavaScript hacia la capa subyacente, y generamos código por ti. Así que solo tienes que implementar la lógica de negocio.

También quiero hablar un poco sobre las herramientas de compilación, porque mientras trabajábamos en la experiencia del desarrollador e introducíamos CodeGen, tuvimos que hacer muchos cambios en cómo se construyen las cosas. Específicamente, también hay mucho código C++ que ahora necesitamos compilar, lo cual antes no era necesario. Por lo tanto, hay algunos cambios que podrías ver, y quiero aclarar algunos temas. Como probablemente sabes, el mundo de la compilación dentro de Meta y fuera de él es un poco diferente, porque internamente usamos Buck para compilar gran parte de nuestro código, mientras que externamente no podemos esperar que los usuarios lo hagan. Instalamos Buck y lo usamos para compilar todo. Así que necesitamos adaptarnos a los estándares de la plataforma. Específicamente en Android, tenemos Gradle. Entonces, hicimos mucho trabajo en torno al código C++. Los usuarios encontrarán referencias a archivos CMake o Android.mk, que les permitirán compilar su código nativo. Así que ya no solo tenemos código Java y Kotlin, sino que también tenemos algo de código C++ para compilar. Para Java y Kotlin, pasamos mucho tiempo construyendo el complemento Gradle de React Native. Este es un conjunto de lógica de compilación y herramientas que permite compilar aplicaciones React Native de manera efectiva.

Y esto va a reemplazar a largo plazo, el buen y viejo archivo React.Gradle que todos incluíamos. En iOS, seguimos el enfoque similar. Así que tenemos CocoaPods, y desarrollamos una lógica personalizada en Ruby que nos permite llamar al código gen y integrarlo en tu lógica de construcción.

También quiero dedicar un par de segundos a hablar sobre Hermes, nuestro motor de JavaScript interno. Entonces, si lees la documentación de la nueva arquitectura, verás que actualmente se recomienda Hermes. Por lo tanto, te sugerimos encarecidamente que lo uses, porque es la forma en que podemos brindarte un mejor soporte. Nos estamos moviendo hacia tener a Hermes como el motor predeterminado para React Native. Y a partir de React Native 69, cada versión de React Native vendrá con una versión de Hermes incluida. Esto significa que para cada versión de React Native, estamos creando una versión de Hermes que sabemos que es compatible con esa versión específica de React Native. Esto trae muchas mejoras en términos de estabilidad para el motor y básicamente te brinda un motor listo para usar junto con React Native.

También quiero dedicar unos segundos a los lenguajes modernos, porque recibimos muchas preguntas sobre este tema. En el lado de TypeScript, cuando lanzamos la primera iteración de la nueva arquitectura y la documentación, recibimos muchos comentarios de usuarios que no estaban satisfechos porque la herramienta inicial solo admitía flow. Obviamente, queremos asegurarnos de que React Native se use y se admita dentro del amplio ecosistema de desarrolladores web y móviles. Por eso dedicamos tiempo a agregar soporte para TypeScript. Me complace anunciar que el generador de código para la nueva arquitectura ahora admite completamente TypeScript. Por lo tanto, puedes escribir tu especificación en flow o TypeScript y el generador de código generará código para Android e iOS a partir de ellos.

En Android, tenemos Kotlin. Afortunadamente, Kotlin es totalmente compatible en React Native. Puedes escribir tus módulos y componentes en Kotlin. También estamos haciendo muchos esfuerzos para actualizar nuestro sitio web y que sea bilingüe. Si abres este problema en el sitio web de React Native (3018), encontrarás el estado actual de la migración del sitio web para que sea bilingüe. Ya encontrarás documentación en Java y Kotlin en varias páginas. Y puedes esperar que la nueva plantilla de la aplicación se actualice completamente a Kotlin en el futuro. Aún no lo hemos hecho porque queremos centrarnos en la nueva arquitectura por ahora. O puedes esperar que este cambio llegue en un futuro cercano.

En cambio, en iOS tenemos Swift. Muchos usuarios nos preguntan cómo pueden escribir sus componentes y módulos con Swift. Bueno, eso es un poco más complicado. Estamos investigando el tema, pero debido a la interoperabilidad entre Swift y C++, las cosas son un poco complicadas. Espera noticias en el futuro, pero lamentablemente no tengo nada que compartir en este momento. Ahora he hablado mucho sobre la nueva arquitectura. También quiero aclarar un poco cuál es la línea de tiempo y qué versiones hemos lanzado hasta ahora y qué viene a continuación. React Native 68 es la primera versión que admite completamente la nueva arquitectura. Teóricamente, la nueva arquitectura se lanzó hace algunas versiones, pero no hemos proporcionado una forma fácil de usarla. Por lo tanto, la versión 68 es la primera versión que tiene una línea de código que puedes habilitar para probar la nueva arquitectura y comenzar a escribir componentes de Fabric y módulos de Turbo. React Native 69 es la primera versión que agrega soporte para React 18. Si has seguido el desarrollo de React, React 18 es una versión importante que contiene muchas características nuevas, y hablaré sobre las implicaciones en React y React Native en la próxima diapositiva. Como mencioné, la versión 69 también incluye Hermes junto con muchas mejoras en el lado de la nueva arquitectura. Luego tenemos la versión 70, que es la próxima versión que vamos a lanzar.

Contendrá varias otras características que ayudarán a los usuarios en la nueva architecture, específicamente el soporte de autoenlace para Android, que ya estaba presente en la nueva architecture para iOS pero faltaba en Android. Por lo tanto, tuvimos que hacer algunas adaptaciones, y esto se implementará en la versión 70.

También habrá soporte para CMake de extremo a extremo, para que los usuarios puedan escribir su código C++ con CMake. También habrá soporte para la configuración de generación de código unificado. Recibimos muchos comentarios de que la forma en que se configuraba la generación de código era diferente entre Android e iOS, así que tomamos una postura y lo solucionamos.

Y bueno, en la versión 71, me gusta decir `hasta el infinito y más allá`. React Native se desarrolla en Meta, pero también es un proyecto en el que la comunidad es lo primero. Realmente escuchamos los comentarios de nuestros usuarios e intentamos integrarlos tanto como sea posible. Algunas de las características que se implementarán en la versión 70 están allí porque recibimos comentarios de los usuarios que realmente necesitaban esas características. Así que si sientes que algo no funciona para ti, por favor avísanos, cuéntanos qué no funciona, cuéntanos cómo podemos mejorar la experiencia de la nueva architecture. Estamos ansiosos por eso.

Como dije, quiero dedicar unos segundos a las interacciones entre React Native y React 18. Aquí tengo una tabla para explicarlo. Si estás en React Native 67 o React Native 68, básicamente estás en React 17. Incluso si vas a tu package.json y cambias la versión de React, seguirás consumiendo React 17. La razón es porque la versión de los dos frameworks está estrechamente vinculada. No puedes simplemente actualizar uno u otro, las cosas no funcionarían correctamente. React Native tiene una versión empaquetada de React, el renderizador de React. Por lo tanto, descartaremos la versión que pases en el package.json.

Si quieres usar React 18, entonces debes actualizar a React Native 69, pero aquí hay un detalle. React 18 viene con muchas características concurrentes y nuevas API, como las transiciones estelares. Esas API dependen de la nueva arquitectura de React Native. Así que si estás en la versión 69 y habilitas la nueva arquitectura, puedes usar esas API y beneficiarte de esas características concurrentes. Si estás en la versión 69 pero aún estás usando la antigua arquitectura, sigues utilizando una versión heredada de React. Incluso si es React 18, no te beneficiarás de esas API. Así que espero que entiendas lo crítico que es para los usuarios actualizar también a la nueva arquitectura, porque no se beneficiarán de esas nuevas mejoras y API en las que hemos trabajado en los últimos años.

Ok, he hablado mucho sobre actualizaciones de frameworks y demás. Ahora, también mencioné la nueva documentación y material de la arquitectura, pero aún no lo he presentado. Así que quiero dedicar este último minuto a hablar sobre qué documentación tenemos disponible para ti. Y quiero enfatizar lo importante que es la documentación, porque cuando estaba escuchando este episodio del show de React Native, recuerdo que le preguntaron a la audiencia, ¿qué están esperando en 2022? Y uno de los comentarios fue la nueva arquitectura. Pero muchos otros frameworks han estado utilizando algunas partes de la nueva arquitectura. Pero lo que falta son los documentos. Y eso es realmente cierto. La nueva arquitectura estaba allí y se podría haber utilizado de alguna forma desde versiones anteriores de React Native. Pero sin una documentación adecuada, la comunidad nunca entenderá cómo usarla correctamente. Y les resultará demasiado difícil utilizarla. Así que veamos qué tenemos hasta ahora. Primero, tenemos la documentación oficial. Dentro de la sección de guías de React Native, hay una nueva sección llamada la nueva arquitectura que contiene instrucciones sobre cómo habilitar la nueva arquitectura. Desde la perspectiva de un autor de bibliotecas y desde la perspectiva de un autor de aplicaciones. Vamos a ampliar esta documentación en las próximas semanas y meses.

Así que por favor manténganse atentos, ya que tenemos más cosas para compartir. También quiero mencionar que tenemos una nueva sección en el sitio web llamada arquitectura. Esta sección contiene muchos análisis detallados. Y documentación sobre el software interno de React Native. Nos han pedido mucho este tipo de documentación en el pasado. Hemos dedicado tiempo a pulir nuestra documentación sobre los aspectos internos y compartir diagramas y explicar cómo funcionan las cosas internamente. Pequeña advertencia, estos análisis detallados no son para todos. Si estás usando React Native por primera vez, probablemente no quieras conocer los aspectos internos de los frameworks. Pero si quieres contribuir o si quieres desarrollar un componente más avanzado, es posible que necesites esa información. Espero que te resulte útil.

Entonces, ahora hablemos de la nueva plantilla de aplicación. La nueva plantilla de aplicación es lo que ves cada vez que ejecutas react native en ella. Mi increíble aplicación. Y queríamos que esto fuera el punto de entrada principal a la nueva arquitectura. Es por eso que trabajamos tanto en esta parte. Para iOS, la extendimos en el momento de la instalación del pod. Normalmente, ejecutarías pod install, pero ahora puedes ejecutarlo con esta variable de entorno, NewArchEnabled establecida en uno, y eso configurará tu proyecto para que realmente utilice la nueva arquitectura. Puedes ejecutarlo con run iOS y estarás ejecutando una aplicación de Android, una aplicación de iOS en la nueva arquitectura. Para Android, de manera similar, tenemos un archivo llamado Gradle properties y una propiedad llamada NewArchEnabled, simplemente cámbiala de false a true, y eso habilitará la nueva arquitectura para ti. Nuevamente, puedes ejecutarlo con run Android y estarás ejecutando una aplicación de Android en la nueva arquitectura. Si quieres estar 100% seguro de que estás en la nueva arquitectura, puedes verificar en Metro que estás ejecutando una aplicación con fabric true y initial props concurrent root establecido en true. Eso significa que estás utilizando Fabric, Turbo modules, la nueva arquitectura y el equipo de react con capacidades concurrentes y todo lo que necesitas. También pasamos mucho tiempo interactuando en la comunidad y produciendo más contenido. Así que quiero presentar un par más. Primero, el nuevo grupo de trabajo de arquitectura. El grupo de trabajo es un repositorio que es solo para discusión donde permitimos a los usuarios colaborar y discutir sobre temas de la nueva arquitectura. Hay varias secciones como anuncios, bibliotecas y documentación y demás. Te invito a echar un vistazo y tal vez pienses si abres el grupo de trabajo que está cerrado por lo que no puedes participar. Pero en realidad hay un enlace en el readme. Entonces, si haces clic allí, puedes unirte al grupo de trabajo. Hay un pequeño formulario para completar y luego serás agregado al grupo de trabajo. Finalmente, también trabajamos en repositorios de ejemplos. Así que hay dos repositorios de ejemplos que quiero compartir contigo. El primero es el repositorio de muestra de la aplicación. Se llama RN New Architecture app y esto contiene varias ramas que te explican cómo migrar tu aplicación de la antigua arquitectura a la nueva. Específicamente aquí es crítico ver que hay varios commits y cada commit está documentado con un mensaje de commit adecuado y puedes seguir paso a paso cómo migramos un proyecto simple de React Native 67 a React Native 68 y activamos la nueva arquitectura allí. De manera similar, también hay un repositorio de ejemplos de bibliotecas llamado New Architecture Libraries y esto contiene ejemplos de cómo crear un componente de fabric y turbo modules que funcionan tanto para la antigua arquitectura como para la nueva arquitectura. Entonces, si eres autor de una biblioteca, esto te resultará realmente útil. También quiero destacar algunas de las bibliotecas que ya han migrado o han comenzado a trabajar en ello. Creemos firmemente que las bibliotecas son fundamentales para la migración de todo el ecosistema así que quiero dar un reconocimiento a esas bibliotecas. Si eres el mantenedor de una biblioteca o autor de una biblioteca y aún no has migrado, considera hacerlo. Ponte en contacto con nosotros si tienes algún problema y aún estamos dispuestos a ayudarte y entender si tienes algún problema y tratar de solucionarlo. Y finalmente, para concluir, realmente espero que en seis meses, un año a partir de ahora, cuando busque React Native en Nueva Arquitectura, buscaré en un motor de búsqueda y encontraré resultados sobre cómo migraste tus aplicaciones a la nueva arquitectura y cómo esto fue exitoso para ti. ¿Qué has aprendido hasta ahora o cómo esto no tuvo éxito? Y, sí, ¿qué no te funcionó? ¿Cuáles son los puntos problemáticos y demás? Estamos aquí para escuchar tus comentarios y realmente queremos escuchar tu historia de migración. Así que por favor cuéntanos. Estamos más que felices de destacar historias de éxito, comentarios que tengas para compartir con nosotros y con el resto de la comunidad. Y con esto, quiero agradecerte mucho por escuchar. También quiero enfatizar que React Native, React, Hermes, Metro, y todos los demás proyectos de la familia React son de código abierto y son más que bienvenidos a recibir tus contribuciones. Así que muchas gracias por escuchar y espero ver tus contribuciones en el repositorio de GitHub de React Native o ponernos al día contigo en el rastreador de problemas de GitHub. 🎵