Llevando la Nueva Arquitectura de React Native a la Comunidad de OSS - Edición de Otoño

Genial. Hola a todos. Muchas gracias por unirse a mí hoy. Vamos a hablar sobre la nueva arquitectura de React Native y cómo la llevamos a la comunidad de código abierto. Como creo que muchos de ustedes aquí pueden ser desarrolladores de React y no de React Native, espero que hayan oído hablar de React 18. Para simplificarlo, la nueva arquitectura es cómo vamos a llevar React 18 a dispositivos móviles y a nativo. Una pequeña historia sobre mí. En realidad, soy un ingeniero de Android que trabaja en el equipo de React Native. Pueden encontrarme en línea como Kurtinico en Twitter y en GitHub. Y la nueva arquitectura de React Native ha estado en los medios durante bastante tiempo. Si realmente buscan en línea y buscan la nueva arquitectura de React Native, pueden encontrar bastante contenido, diría yo. Y veamos algunos de los videos que verán. El primero es de ReactConf 2018.

Entonces, hemos estado hablando mucho al respecto. Como el año pasado, mi colega Joshua dio una charla al respecto en React Native EU y se trataba de la nueva arquitectura dentro de Meta. Pero ahora el punto es, ¿cómo lo sacamos? ¿Cómo permitimos que la comunidad de código abierto también lo use? Si observamos una línea de tiempo de la nueva arquitectura, nuevamente, comenzó como un proyecto de seis meses en 2018. Pero resulta que el producto más grande que tenemos en Meta que utiliza React Native, que es la aplicación de Facebook, es bastante complicado. Y créanme, los ingenieros lograron utilizar todos los casos límite posibles y todas las API posibles de React Native para exprimir todo el rendimiento de este framework. Así que nos llevó, al final del día, casi tres años completar la implementación completa de la nueva arquitectura en la aplicación de Facebook. Pero luego, a partir de ahí, como dije, nos miramos a nosotros mismos y nos preguntamos, ¿cómo lo implementamos en código abierto? Y esta charla tratará sobre esto, exactamente. Cómo permitimos que las personas fuera de Meta se beneficien de React 18 y la nueva arquitectura en Nativo. Entonces, para dar un paso atrás y realmente entender por qué estamos trayendo la nueva arquitectura. Como dije antes, queremos llevar todos los beneficios de React 18 a Nativo. Pero no es solo eso. Si han estado trabajando con React Native, probablemente sepan que hay un componente que es crucial en la arquitectura de React Native, que se llama el Bridge. Esencialmente, es un componente que permite que la capa de JavaScript se comunique con la capa nativa y todo se pasa a través de este puente como JSON. Y como pueden imaginar, es un gran

Aquí defines una interfaz y dices que tienes una función que responde a la pregunta definitiva y registras este módulo. Y nuevamente, el punto es esta función y esta firma. Cogen es capaz de entender que estás declarando una API pública que utilizarás en tu código JavaScript. Y la información importante aquí es que hay una entrada que es una cadena y una salida que es un número. A partir de esta información, podemos generar gran parte del código de plantilla que no tienes que escribir. La cuestión es que a los desarrolladores web que trabajan con React Native no les gusta realmente escribir código de Android e iOS, por lo que estamos tratando de hacer esto lo más simple posible. Entonces, ¿cómo se verá esto en Android? Generaremos algunas clases Java. Así que tendremos una clase abstracta con el constructor y un método que cumpla con la firma. Entonces, en este caso, este será un método abstracto que acepta un JavaString como entrada y devuelve un double. Así que hacemos todo el tipo, resolvemos los tipos a los tipos específicos de la plataforma que cada plataforma acepta. Entonces, en iOS, por ejemplo, tendrás un protocolo Objective-C que acepta NSString y devuelve un NSNumber. Obviamente, en algún momento necesitarás escribir la lógica del negocio, como alguien debería responder a la pregunta definitiva, no podemos responder eso por ti, pero sí, estamos tratando de simplificar una gran cantidad de código de plantilla que ya no es necesario escribir.

Ok, sí, esta nueva arquitectura nos obligó a hacer muchos cambios en general, como puedes imaginar, porque ahora hay un generador de código que se ejecuta y hay sí, muchas partes móviles. Entonces, tomamos una postura en nuestras herramientas de compilación, por lo que muchos cambios están ocurriendo en nuestra integración con la plataforma subyacente, y aquí hay un poco de desafío, porque internamente en Meta utilizamos una herramienta de compilación llamada Buck, que también es de código abierto, y la nueva arquitectura para nosotros internamente funciona sobre esto, lo cual es genial, pero no podemos esperar que las personas fuera de Meta utilicen Buck porque es, quiero decir, es de código abierto, pero queremos utilizar las herramientas de compilación específicas de la plataforma en la que se ejecuta. Entonces, en Android se ejecutará en Gradle, y nos tomamos mucho tiempo para asegurarnos de que todo se integre bien. Habrá algo de código C++, por lo que también habrá archivos CMake que son manejados por Gradle. Pequeña advertencia, mucha gente me dijo que no quiere ver código C++, así que encapsulamos todo, los desarrolladores web no tendrán que ver CMake o código C++ en absoluto, pero está bajo el capó y se puede utilizar para aplicaciones específicas de rendimiento. Escribimos nuestro complemento de Gradle y efectivamente en React Native 71, esto elimina gran parte del código heredado y muchos de los fallos de compilación que los usuarios experimentaban al crear su aplicación de Android, esta lógica ha sido completamente reescrita. El resumen aquí es que dentro de tu arquitectura, en realidad estamos limpiando gran parte del código heredado y la infraestructura de compilación heredada que se acumuló en nuestro código de código abierto durante los años. En iOS, de manera similar, tenemos CocoaPods. Y nuevamente, tomamos una postura aquí para limpiar un poco las cosas. Escribimos mucha lógica, ahora tenemos una suite completa de scripts de Ruby que son más fáciles de usar, son más pequeños y están completamente probados. Así que esperamos que veas menos fallos de compilación en el futuro. Ok. Entonces, otro componente que en realidad, no es necesariamente parte de la nueva arquitectura, pero le dedicamos mucho tiempo y visualizamos la nueva arquitectura con estas cosas agrupadas, es nuestro motor de JavaScript llamado Hermes. En la documentación de la nueva arquitectura, en realidad se recomienda. Y podemos brindar un mejor soporte. Si tu aplicación se bloquea y tienes Hermes, podemos saber más qué está sucediendo. Así que invitamos a los usuarios a utilizar este motor y plantear cualquier problema que encuentren.

Un par de actualizaciones también que hicimos en el lado de los lenguajes modernos, ya que mucha gente nos pide que usemos diferentes lenguajes de programación cuando usan React Native. Y aquí tengo muchas actualizaciones en realidad. TypeScript. Cuando lanzamos la primera versión de la documentación de la Nueva Arquitectura, el comentario más votado fue que no querían usar Flow, lo cual puedo entender perfectamente. Nuestra primera versión de la documentación era esencialmente nuestra wiki interna pulida y de código abierto. Y internamente en Meta usamos Flow, pero fuera de eso no es el caso. Así que tuvimos que reconstruir mucho código y dar soporte. Ahora TypeScript es totalmente compatible con Cogent. Y les contaré más, en realidad en la versión 71 de React Native, que se supone que se lanzará en un futuro cercano, en cuestión de semanas en este punto, TypeScript será el lenguaje predeterminado. Por lo tanto, todos los nuevos proyectos se crearán con TypeScript. Estamos enviando tipos junto con React Native. Y hemos analizado más de cerca nuestro ecosistema y pensamos que queremos dar más soporte a TypeScript. El siguiente en Android es Kotlin. Actualmente es totalmente compatible. De hecho, puedes usar Kotlin en todas partes en React Native, creo que la charla anterior te contará mucho más al respecto, así que asegúrate de estar atento. Nuestro sitio web también está completamente migrado y es bilingüe. Todos los ejemplos en React Native .DEV están tanto en Java como en Kotlin. Y puedes usar completamente el que desees y la plantilla que hicimos para TypeScript. También podríamos actualizar la plantilla para usar Kotlin. Aún no lo hemos hecho, pero esto está previsto para el futuro. Y por último, Zwift. Muchos ingenieros de IS nos están pidiendo que usemos Zwift, y sí, esto es un poco más complicado debido a cómo Zwift y C++ interoperan. Espero tener respuestas para esto en el futuro. Estamos observándolo de cerca y esperamos saber más. Así que el cronograma. ¿Qué está sucediendo y cuándo? Mencioné algunas cosas como algunas versiones de React Native, pero permítanme recapitular. Comenzamos a principios de este año, el despliegue de la nueva arquitectura comenzó en realidad este año con React Native 68. Esa es la primera versión de React Native que admite esas nuevas API. Luego, en React Native 69, agregamos el soporte de React 18. Esto puede ser un poco confuso, pero efectivamente la forma en que interactúan React y React Native es que React

Yo diría, si me preguntaras, ¿está lista para producción? Te diría, bueno, la aplicación React Native más grande se ejecuta en ella, así que sí, está lista para producción. ¿Es fácil de usar? Estamos iterando en ello. Hay algunos detalles complicados, por ejemplo, en la versión 70, el tiempo de compilación en Android era de aproximadamente media hora. En la versión 71, utilizamos mucho el tiempo de compilación, y ahora es cuestión de segundos. Y esos cambios requieren un ciclo de retroalimentación de tu parte y también tiempo para que los solucionemos. Muy bien. Y creo que tenemos una pregunta que fue respondida durante tu charla. ¿Es necesario migrar todas las bibliotecas a la nueva arquitectura? Es compatible hacia atrás. Y creo que mencionaste la compatibilidad hacia atrás. Pero si puedes agregar más información. Sí, permíteme reiterar. La historia de la compatibilidad hacia atrás es, como dije, un poco más complicada en los dos componentes, en los dos pilares, los módulos nativos. Todo lo que no es de interfaz de usuario es compatible hacia atrás. Puedes usar los turbo módulos o los módulos nativos heredados, como los llamamos, una vez que habilitas la nueva arquitectura, en la interfaz de usuario. Sin embargo, si habilitas fabric, como si habilitaras la nueva arquitectura y tienes un componente que no es compatible con fabric, verás una caja morada que te indica que aquí debería haberse renderizado algo, pero esto no es compatible con fabric. Esto te brinda una retroalimentación inmediata si algo está funcionando o no. Pero también estamos trabajando con Microsoft en una herramienta llamada AlignDepth o Depth Check. Es parte de esta colección de herramientas llamada RnxKit, que es un conjunto de herramientas que Microsoft está desarrollando. Y estamos colaborando e iterando en proporcionar más información sobre qué bibliotecas son efectivamente compatibles con la nueva arquitectura y cuáles no. En el directorio de bibliotecas de React Native, hay una etiqueta que te indica si es compatible o no. Pero sí, una vez que todo esto sea estable, créeme, habrá una forma fácil de saber qué bibliotecas son compatibles y cuáles no.

Sí, fue una excelente respuesta. Y también vi un tuit de Lorenzo, ayer creo, sobre AlignDepth y el kit RnX. Está ganando cada vez más fuerza, diría yo, para respaldar esta nueva arquitectura. Creo que tengo una pregunta más, solo rápidamente.

En términos de rendimiento, ¿valió la pena todo el trabajo que han hecho? Para nosotros, sí. Pudimos desarrollar una característica como el pre-renderizado o hacer cosas que la arquitectura anterior no era posible. Como, no nos permitía hacer.

Ahora la gente viene y nos dice, sí, habilita la nueva arquitectura y espera, como, ya sabes, picos de ganancias aquí y allá. Ese no es el caso. Como, la arquitectura es una, como dije, es una piedra fundamental para las herramientas en las que tienes que construir encima. Como, si estabas haciendo algo con el puente, entonces hacer eso con la nueva arquitectura, hacer eso de forma síncrona pasando de JavaScript directamente a C plus plus, te dará ganancias de rendimiento. Pero eso depende de tu caso de uso. No es que no haya ganancia de rendimiento inmediata. Y sí, realmente depende de tu caso de uso, de tus bibliotecas y de lo que estás haciendo. Y veremos cada vez más bibliotecas que utilizarán esas nuevas APIs, y tendrás que migrar para beneficiarte de esas nuevas bibliotecas. Genial. Sí. Muchas gracias. Muchas gracias a ti, Nicola. Es un placer tenerte aquí.