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

Rate this content
Bookmark

Al final de 2021, implementamos con éxito la Nueva Arquitectura de React Native en la aplicación de Facebook. Ahora es el momento de capacitar a todos los desarrolladores de React Native en el mundo para que utilicen la Nueva Arquitectura de React Native, tanto el nuevo renderizador Fabric como el nuevo sistema TurboModule. Pero migrar todo un ecosistema a una Nueva Arquitectura no es una tarea fácil. Para apoyar a toda la comunidad en este esfuerzo, hemos preparado un conjunto de herramientas y materiales que ayudarán tanto a los desarrolladores de aplicaciones como a los de bibliotecas a unirse a nosotros en este viaje. En la charla, presentaremos cómo se ve la Nueva Arquitectura de React Native en el espacio de OSS. Discutiremos el impacto que esto tendrá en el desarrollo de proyectos de React Native. Por último, cubriremos lo que aprendimos de la migración de la Nueva Arquitectura de React Native en Meta, y cómo pueden abordar su migración en su organización.

29 min
02 Dec, 2022

Video Summary and Transcription

La charla trata sobre la nueva arquitectura de React Native y su introducción a la comunidad de código abierto. La nueva arquitectura tiene como objetivo llevar React 18 a plataformas móviles y nativas, al tiempo que elimina el cuello de botella del componente Bridge. Incluye conceptos fundamentales como el nuevo renderizador (Fabric), el sistema de módulos nativos (TurboModule), la generación de código para la seguridad de tipos y el modo sin puente. La arquitectura simplifica el proceso de desarrollo para los desarrolladores web, requiere cambios en las herramientas de compilación y recomienda el uso del motor de JavaScript Hermes. También enfatiza la importancia de explorar nuevas API, migrar bibliotecas y proporcionar comentarios para mejorar el ecosistema.

Available in English

1. Introducción a la Arquitectura de React Native

Short description:

Vamos a hablar sobre la nueva arquitectura de React Native y cómo la llevamos a la comunidad de código abierto. La nueva arquitectura es cómo vamos a llevar React 18 a dispositivos móviles y a nativo. La nueva arquitectura de React Native ha estado en los medios durante bastante tiempo. Hicimos nuestra implementación internamente. ¿Cómo lo sacamos? ¿Cómo permitimos que la comunidad de código abierto también lo use? 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. Queremos llevar todos los beneficios de React 18 a Nativo. Pero no es solo eso. Queríamos deshacernos del componente Bridge, que es un gran cuello de botella en la arquitectura de React Native.

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

2. Conceptos fundamentales de la nueva arquitectura

Short description:

Escribimos una vez las partes internas de nuestra arquitectura, lo que nos permite compartir optimizaciones entre Android e iOS. La nueva arquitectura introduce el componente codegen para la seguridad de tipos y sirve como base para futuras características. Los conceptos fundamentales, o pilares, incluyen el nuevo renderizador (fabric), el sistema de módulos nativos (turbo modules), el codegen para la seguridad de tipos y el modo sin puente. En Android, se generarán clases Java.

cuello de botella. Así que, primero, queríamos deshacernos de él. Como escribimos muchas de las partes internas de nuestra arquitectura, en realidad tomamos una postura y las escribimos una vez. Solíamos tener un renderizador de Android y un renderizador de iOS, que no estaban exactamente alineados. Así que escribimos muchas partes internas en C++ y esto nos permitió compartir algunas optimizaciones específicas de la plataforma entre las dos plataformas. Además, el uso del puente significaba que no podíamos realmente beneficiarnos de la seguridad de tipos. Por eso, la nueva arquitectura tiene un nuevo componente llamado codegen, que proporciona seguridad de tipos dentro de nuestra API. Y finalmente, debes pensar en la nueva arquitectura como la piedra fundamental para muchas características que se construirán sobre React 18 en estas nuevas APIs y también se entregarán a nativo. Entonces, necesitamos asegurarnos de que las personas estén utilizando esas APIs. Entonces, ¿cuáles son los conceptos fundamentales de la nueva arquitectura? Los llamamos pilares. Y tenemos varios de ellos. Primero, tenemos el nuevo renderizador. Y esto es lo que realmente utiliza React 18. Y a menudo se hace referencia a este nuevo renderizador como fabric. Luego tenemos el nuevo sistema de módulos nativos, que te permite interactuar con la plataforma nativa y llamar a las APIs de Android e iOS. Y a este mecanismo lo llamamos turbo modules. Luego, como dije antes, queríamos agregar seguridad de tipos a nuestra fórmula. Por eso introdujimos un nuevo componente llamado Cogen. Y el último pilar es el modo sin puente. Entonces, una vez que todo esté en su lugar, todos tus componentes sean compatibles con fabric y todo sea compatible con turbo modules y así sucesivamente, puedes desactivar completamente el puente. Lamentablemente, no tengo tiempo para profundizar en estos temas, y también son muy técnicos. Pero quiero darte una idea de cómo se verá el código cuando comiences a escribir módulos y componentes nativos y uses Cogen. Lo que imaginamos es que queremos que los desarrolladores definan una especificación, por lo que tendrás un archivo TypeScript, que se verá más o menos como este.

3. Arquitectura, Herramientas de compilación y Hermes

Short description:

La nueva arquitectura simplifica el proceso de escribir código para Android e iOS para los desarrolladores web. Genera el código de plantilla necesario basado en la API pública declarada, reduciendo la necesidad de codificación manual. La arquitectura requiere cambios en las herramientas de compilación, utilizando Gradle para Android y CocoaPods para iOS. El código C++ está encapsulado y oculto para los desarrolladores web, pero puede ser utilizado para aplicaciones específicas de rendimiento. La infraestructura de compilación se ha mejorado, eliminando el código heredado y solucionando los fallos de compilación. Además, se recomienda el motor de JavaScript Hermes para un mejor soporte y seguimiento de problemas.

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.

4. Bundled Hermes y Motor Predeterminado

Short description:

A partir de React Native 69, React Native ahora viene con Hermes, un motor de JavaScript que es totalmente compatible con cada versión de React Native. En el pasado, surgieron problemas de compatibilidad cuando el motor y React Native se construían en momentos diferentes. Sin embargo, con Hermes incluido, puedes usar un motor que sea totalmente compatible con tu versión de React Native. A partir de React Native 70, Hermes es el motor predeterminado para nuevos proyectos, aunque se puede desactivar si es necesario.

Podrías haber tenido problemas de compatibilidad en el pasado. A partir de React Native 69, hicimos un cambio llamado Hermes incluido. Ahora, cada versión de React Native viene con una versión específica de este motor de JavaScript que sabemos que es totalmente compatible con la versión de React Native. En el pasado, había escenarios en los que el motor se construía en un momento dado y React Native se construía en otro momento, y no eran realmente compatibles entre sí. Ahora tienes un motor que es totalmente compatible con tu versión de React Native en todo momento y simplemente puedes usarlo. A partir de React Native 70, que lanzamos hace un par de meses, Hermes es el motor predeterminado. Por lo tanto, todos los nuevos proyectos tendrán Hermes habilitado de forma predeterminada y si no lo deseas, porque podrías tener una razón válida, deberás desactivarlo.

5. Actualizaciones sobre Lenguajes Modernos y Cronograma

Short description:

Un par de actualizaciones en el lado de los lenguajes modernos. TypeScript ahora es totalmente compatible con Cogent y será el lenguaje predeterminado en React Native 71. Kotlin es totalmente compatible en Android. El sitio web de React Native .DEV está completamente migrado y es bilingüe, compatible con Java y Kotlin. Se está explorando el uso de Zwift y la interoperabilidad de C++.

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

6. Versiones de React Native y Nueva Arquitectura

Short description:

La primera versión de React Native que admite la versión 18 es la 69. Enviamos paquetes armados, con muchas mejoras en la experiencia relacionada con la nueva arquitectura. Lanzamos la nueva arquitectura en la versión 68, con muchas mejoras en el tiempo de compilación y la experiencia del desarrollador. En React Native 71, simplificamos la plantilla y eliminamos todo el código C++. Queremos escuchar a la comunidad y recopilar comentarios sobre las nuevas API. Para utilizar completamente React 18 y las API concurrentes, debes estar en React Native 69 y habilitar la nueva arquitectura.

React Native decide qué versión de React utilizar. Y la primera versión de React Native que admite la versión 18 es la 69. Por lo tanto, debes estar en la versión 69 como mínimo, no puedes simplemente cambiarla. Y enviamos paquetes armados, de los que hablé antes en la versión 70, con muchas cosas y muchas mejoras en realidad en la experiencia relacionada con la nueva arquitectura. No tengo tiempo para profundizar en todos ellos, pero algunos de esos puntos han sido muy solicitados por la comunidad. Así que lanzamos la nueva arquitectura en la versión 68, y la gente vino y nos dijo, esto es increíble, pero no funciona para mí porque A, B, C y D. Y escuchamos lo que la gente nos decía, y desarrollamos muchas mejoras en el tiempo de compilación, muchas mejoras en la experiencia del desarrollador, y así sucesivamente. Eso se incluyó en la versión 70. Y en la versión 71, simplificamos mucho la plantilla. Como dije antes, eliminamos todo el código C++. Básicamente, ahora no hay código C++ en absoluto, a menos que realmente quieras verlo porque puedes tener, no sé, tu biblioteca de criptografía, y quieres hacer tus cosas locas con C++, entonces puedes optar por tener código C++ del que eres responsable de mantener. Y luego, ¿qué sigue? Bueno, hoy, el Infinito y más allá porque, como dije, queremos saber qué funciona y qué no funciona para ti. Queremos escuchar a la comunidad, como, sí, esto es valioso para mí o esto no es valioso. Así que por favor prueba esas nuevas API. Todavía se consideran experimentales. No las estamos habilitando de forma predeterminada. Lo haremos en algún momento, pero en esta etapa, todavía estamos recopilando comentarios y escuchando a los autores de bibliotecas, a los autores de aplicaciones, qué es lo que no les funciona. Hablé brevemente sobre React 18 y React Native. Permíteme reiterar. Solo para aclarar las interacciones entre los dos marcos. Si estás en React Native 67 o 68, estás ejecutando efectivamente React 17. Es decir, la versión de React es 17. Y algunas de esas nuevas API como star transition no funcionarán. Para utilizar completamente React 18 y todas esas API concurrentes, debes estar al menos en React Native 69. Y no puedes... No puedes simplemente cambiar la versión de React. React Native decide por ti. Y aquí está el truco: en las versiones 69 y 70, para utilizar esas nuevas API debes estar en la nueva arquitectura. Es decir, debes habilitar la nueva arquitectura para usar React concurrente. Si intentas utilizar esas API pero no estás en la nueva arquitectura, simplemente no funcionarán. Serán vacías.

7. Explorando Nuevas APIs y Documentación

Short description:

Para mantenerse actualizado con el ecosistema y el marco de React Native en constante evolución, es crucial explorar las nuevas APIs y la documentación. La documentación oficial incluye explicaciones de los cambios, pautas para crear bibliotecas y aplicaciones, soporte de migración y documentos detallados de diseño sobre la arquitectura. La nueva arquitectura simplifica el proceso de configuración para iOS y Android, permitiendo a los desarrolladores probar fácilmente las nuevas APIs siguiendo instrucciones específicas. Ejecutar la aplicación con fabric establecido en true confirma el uso de la nueva arquitectura.

implementaciones, etc. Por lo tanto, es crucial que si tienes una aplicación de React Native y quieres mantenerte actualizado con la evolución del ecosistema y nuestro marco, eches un vistazo a esas... Sí, a esas nuevas APIs. ¿Y qué significa echar un vistazo a esas APIs? Hemos creado mucha documentación. Y todavía estamos iterando en ella y en realidad se trata de la documentación. Porque esas APIs, que lanzamos en la versión 68, estuvieron disponibles allí durante mucho tiempo. Creo que agregamos fabric en React Native 64 o 65. Pero simplemente no estaban documentadas. Recuerdo escuchar en este podcast, el show de React Native, donde la gente hablaba de que algunas bibliotecas intentaban usarlo, pero no sabían cómo tenían que ingeniar el código del marco, lo cual no es genial. Por eso ahora tenemos una documentación oficial. Encontrarás la nueva sección en el sitio web llamada la nueva arquitectura, donde se explica todo por qué hicimos ciertos cambios, cómo crear una nueva biblioteca, cómo crear una nueva aplicación, etc. Y también, una sección dedicada a la migración. ¿Cómo paso de una biblioteca o una aplicación que no es compatible con la arquitectura a tener el soporte completo para la arquitectura? Además de esto, ahora tenemos una nueva sección llamada arquitectura, que contiene documentos de diseño sobre nuestro trabajo interno y cómo funciona el renderizado, etc. A la gente, especialmente a los que usan bibliotecas populares como reanimated, les gustaría saber cómo trabajamos internamente y cuáles son los principios a seguir, etc. Así que tomamos una postura y también escribimos esos documentos en la nueva plantilla, como lo que sucede cuando eliges React Native en ella. Mi increíble aplicación se ha actualizado para que puedas probarla en tu arquitectura fácilmente. ¿Qué significa esto? Significa que en iOS, en lugar de llamar a pod install después de configurar tu proyecto, llamarás a nuestra ciudad en Newark habilitada para pod install. Y esto reconfigurará tu proyecto para permitirte probar la nueva arquitectura. En Android, en cambio, hay un archivo llamado Gradle dot properties, y cambiarás Newark enabled de false a true. Y simplemente puedes ejecutar react-native run-android, y estarás ejecutando esas nuevas APIs. Efectivamente, verás un mensaje en Metro que te dice: `Hey, estás ejecutando tu aplicación con fabric`.

8. Grupo de Trabajo, Ejemplos y Herramientas de Código Abierto

Short description:

Iniciamos el grupo de trabajo de la nueva arquitectura, que es un espacio de colaboración para hacer preguntas, compartir bibliotecas y discutir la migración de bibliotecas. También proporcionamos ejemplos para la migración de aplicaciones y bibliotecas, así como ejemplos de compatibilidad con versiones anteriores. Valoramos los comentarios y queremos escuchar historias de migración para mejorar las APIs. La antigua arquitectura todavía es experimental y animamos a las personas a probarla y proporcionar comentarios. Nuestras herramientas son de código abierto y nos comprometemos a hacerlas valiosas para todos.

establecido en true, y así sucesivamente. Por lo tanto, estás ejecutando efectivamente la nueva architecture. Muy rápido sobre un par de cosas más que también hicimos, porque veo que se me acaba el tiempo. Pero un par de un par de contenidos más. Primero, iniciamos el grupo de trabajo. Se llama el nuevo grupo de trabajo de la architecture. Y esto es similar al grupo de trabajo de React 18 que comenzamos hace un par de años. Es un espacio de colaboración donde puedes hacer preguntas, compartir tus bibliotecas, dar actualizaciones sobre cómo tu biblioteca se está migrando a la nueva architecture y conectarte con otras personas que también están investigando esas APIs. Si abres el grupo de trabajo, parece que es de solo lectura. Pero en realidad puedes solicitar unirte al grupo de trabajo usando el enlace de abajo. Y revisaré tu solicitud y te enviaré una invitación. También tenemos ejemplos, como cosas que se ejecutan efectivamente. Tenemos un repositorio de ejemplos de aplicaciones que contiene varias ramas. Y cada rama te explica cómo migrar una aplicación desde una versión determinada de React Native, y así sucesivamente. Y cada migración se realiza paso a paso. Por lo tanto, verás todos los commits sobre cómo habilitamos las diversas cosas. También tenemos un ejemplo de biblioteca que contiene ejemplos de cómo crear un módulo turbo o un módulo turbo nativo o un componente de fabric que sea compatible con versiones anteriores. Así que puedes crear algo que funcione tanto en la antigua como en la nueva architecture. Y con esto, realmente espero que en el futuro, cuando busque React Native nueva architecture en algún momento, escucharé tus historias, como escribirás sobre ello y me contarás, como, hey, fue un completo desastre porque tus compañeros se perdieron aquí, aquí, y allá, o las charlas fueron geniales o lo que sea. Realmente queremos escuchar tu historia de migración. Estamos iterando en esto. Sabemos que algunas APIs no son tan geniales y brillantes como te gustaría. Y por eso actualizamos algunas de ellas. Por eso la antigua architecture todavía es experimental. Y ahora es crucial que las personas prueben esto y nos digan qué funciona y qué no funciona. Sí. Y quiero recordarles que todas nuestras herramientas son de código abierto. Nos comprometemos completamente con este ecosistema. Pasamos mucho tiempo hablando con socios, con los mantenedores de bibliotecas. Y solo queremos hacer esas herramientas lo mejor posible y valiosas para todos. Y muchas gracias por escuchar.

9. Cambio a la Nueva Arquitectura y Dependencias

Short description:

¿Cuándo es un buen momento para cambiar las aplicaciones existentes a la nueva arquitectura? El cronograma para cambiar a la nueva arquitectura y dependencias es una consideración crucial. Si bien los TurboModules son compatibles con versiones anteriores y se pueden habilitar fácilmente, migrar bibliotecas de interfaz de usuario puede ser más desafiante. Se recomienda revisar la lista de dependencias y asegurarse de que la mayoría estén migradas. Las bibliotecas sin mantenimiento representan un riesgo de seguridad y brindan la oportunidad de evaluar y potencialmente actualizar o revivirlas.

Muchas gracias, Nicola. Fue como si nos iluminaras sobre la nueva arquitectura. Y sí, tenemos tiempo para preguntas. Sí. Tenemos algunas preguntas y comenzaré de inmediato. ¿Cuándo es un buen momento para cambiar las aplicaciones existentes a la nueva arquitectura o cuál es, en tu opinión, el cronograma para cambiar a la nueva arquitectura o qué dependencias? Sí. Esta es una pregunta bastante crucial, diría yo. Cuando comenzamos, a principios de este año, teníamos muchas bibliotecas, muchas bibliotecas populares, que no tenían soporte para Fabric o TurboModules, lo que dificultaba mucho la migración, especialmente en Fabric. Los TurboModules son realmente compatibles con versiones anteriores en el sentido de que puedes habilitarlos fácilmente. Y si tienes bibliotecas que están migradas o bibliotecas que no están migradas, funcionarán bien juntas. En cambio, en el lado de la interfaz de usuario, es mucho más difícil. Y estamos haciendo un gran esfuerzo en este sentido para que las bibliotecas migradas y no migradas funcionen bien juntas. Esperamos que haya más sobre este tema en el futuro. Pero por ahora, mi recomendación es revisar tu lista de dependencias y ver que la mayoría de ellas, muchas de ellas, estén realmente migradas. Por ejemplo, Reanimated, React Native screens, todas están migradas y tienen una versión compatible con Fabric. Pero a veces puedes usar una biblioteca que no tiene mantenimiento. Bueno, eso es desafortunado. Diría que también es una oportunidad para tomar una postura sobre qué bibliotecas dependes y, dependiendo de bibliotecas que no están mantenidas, generalmente es un riesgo de seguridad. Entonces, tal vez también sea una oportunidad para que las aplicaciones revisen en qué dependen y limpien algunas de ellas o potencialmente revivan algunas de ellas

10. Migración de Bibliotecas y Compatibilidad hacia Atrás

Short description:

Muchas bibliotecas se han migrado a la nueva arquitectura, lo que indica tracción por parte de la comunidad. Si bien la nueva arquitectura se considera experimental, está lista para producción y se está iterando. La compatibilidad hacia atrás está disponible para los componentes que no son de interfaz de usuario, pero la compatibilidad con fabric requiere consideraciones adicionales. La colaboración con Microsoft en herramientas como AlignDepth y RnXKit tiene como objetivo proporcionar información sobre la compatibilidad de las bibliotecas. El kit RnX está ganando fuerza para admitir la nueva arquitectura.

bibliotecas, bifurcándolas y actualizándolas. Estoy totalmente de acuerdo contigo. He visto muchas bibliotecas excelentes migrando a la nueva arquitectura, como Reanimated, React Native SVG, gesture handlers, y también mencionaste las screens. También hay mucha tracción por parte de la comunidad, pero creo que como desarrollador junior o alguien que no tiene conocimientos de C++ o Kotlin, o de la nueva arquitectura en sí, es realmente difícil ir y actualizar algo, ¿verdad? Sí, lo es, y por eso seguimos considerando la nueva arquitectura como experimental.

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.

11. Rendimiento y Migración a la Nueva Arquitectura

Short description:

Para nosotros, la nueva arquitectura ha valido la pena en términos de rendimiento. Nos permite desarrollar características como el pre-renderizado que antes no eran posibles. Sin embargo, habilitar la nueva arquitectura no garantiza ganancias de rendimiento inmediatas. Depende de tu caso de uso y bibliotecas. Migrar a la nueva arquitectura será necesario para beneficiarse de nuevas bibliotecas y APIs.

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í.

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

React Advanced Conference 2023React Advanced Conference 2023
29 min
Raising the Bar: Our Journey Making React Native a Preferred Choice
At Microsoft, we're committed to providing our teams with the best tools and technologies to build high-quality mobile applications. React Native has long been a preferred choice for its high performance and great user experience, but getting stakeholders on board can be a challenge. In this talk, we will share our journey of making React Native a preferred choice for stakeholders who prioritize ease of integration and developer experience. We'll discuss the specific strategies we used to achieve our goal and the results we achieved.
React Finland 2021React Finland 2021
27 min
Opensource Documentation—Tales from React and React Native
Documentation is often your community's first point of contact with your project and their daily companion at work. So why is documentation the last thing that gets done, and how can we do it better? This talk shares how important documentation is for React and React Native and how you can invest in or contribute to making your favourite project's docs to build a thriving community
Vue.js London 2023Vue.js London 2023
11 min
The Hidden Cost of Open Source
There is a cost that many companies don’t consider when using open source. It can cost a lot of money and time to keep upgrading sunsetted versions.Open source is free for companies to use until the author sunsets a version.These are some best practices that we we recommend when considering open source adoption:        - Who is the author? Do they have a strong reputation that is going to be around for a long time? Do they have the resources to support an enterprise library?        - How much online support is there in the community for this library? How many dependencies are on this library?        - Does it have an end of life policy? What’s going to happen when they rev on a version? Will companies have an option to stay on older versions for a long time?        - What should you consider when migrating to a supported framework after a version has been sunsetted?
React Day Berlin 2023React Day Berlin 2023
29 min
Bringing React Server Components to React Native
React Server Components are new topic in community, bunch of frameworks are implementing them, people are discussing around this topic. But what if we could use React Server Components in React Native? And bring all optimisation features that RSC allows to mobile apps? In this talk I would present what we are able to do with RSC in React Native!
React Advanced Conference 2021React Advanced Conference 2021
21 min
Building Cross-Platform Component Libraries for Web and Native with React
Top Content
Building products for multiple platforms such as web and mobile often requires separate code-based despite most of the components being identical in look and feel. Is there a way where we could use shared React component library on different platforms and save time? In this presentation I'll demonstrate one way to build truly cross-platform component library with a unique approach of using React & React Native in combination.

Workshops on related topic

React Advanced Conference 2022React Advanced Conference 2022
81 min
Introducing FlashList: Let's build a performant React Native list all together
Top Content
WorkshopFree
In this workshop you’ll learn why we created FlashList at Shopify and how you can use it in your code today. We will show you how to take a list that is not performant in FlatList and make it performant using FlashList with minimum effort. We will use tools like Flipper, our own benchmarking code, and teach you how the FlashList API can cover more complex use cases and still keep a top-notch performance.You will know:- Quick presentation about what FlashList, why we built, etc.- Migrating from FlatList to FlashList- Teaching how to write a performant list- Utilizing the tools provided by FlashList library (mainly the useBenchmark hook)- Using the Flipper plugins (flame graph, our lists profiler, UI & JS FPS profiler, etc.)- Optimizing performance of FlashList by using more advanced props like `getType`- 5-6 sample tasks where we’ll uncover and fix issues together- Q&A with Shopify team
React Summit 2022React Summit 2022
117 min
Detox 101: How to write stable end-to-end tests for your React Native application
Top Content
WorkshopFree
Compared to unit testing, end-to-end testing aims to interact with your application just like a real user. And as we all know it can be pretty challenging. Especially when we talk about Mobile applications.
Tests rely on many conditions and are considered to be slow and flaky. On the other hand - end-to-end tests can give the greatest confidence that your app is working. And if done right - can become an amazing tool for boosting developer velocity.
Detox is a gray-box end-to-end testing framework for mobile apps. Developed by Wix to solve the problem of slowness and flakiness and used by React Native itself as its E2E testing tool.
Join me on this workshop to learn how to make your mobile end-to-end tests with Detox rock.
Prerequisites- iOS/Android: MacOS Catalina or newer- Android only: Linux- Install before the workshop
React Summit Remote Edition 2021React Summit Remote Edition 2021
60 min
How to Build an Interactive “Wheel of Fortune” Animation with React Native
Top Content
Workshop
- Intro - Cleo & our mission- What we want to build, how it fits into our product & purpose, run through designs- Getting started with environment set up & “hello world”- Intro to React Native Animation- Step 1: Spinning the wheel on a button press- Step 2: Dragging the wheel to give it velocity- Step 3: Adding friction to the wheel to slow it down- Step 4 (stretch): Adding haptics for an immersive feel
React Advanced Conference 2023React Advanced Conference 2023
159 min
Effective Detox Testing
Workshop
So you’ve gotten Detox set up to test your React Native application. Good work! But you aren’t done yet: there are still a lot of questions you need to answer. How many tests do you write? When and where do you run them? How do you ensure there is test data available? What do you do about parts of your app that use mobile APIs that are difficult to automate? You could sink a lot of effort into these things—is the payoff worth it?
In this three-hour workshop we’ll address these questions by discussing how to integrate Detox into your development workflow. You’ll walk away with the skills and information you need to make Detox testing a natural and productive part of day-to-day development.
Table of contents:
- Deciding what to test with Detox vs React Native Testing Library vs manual testing- Setting up a fake API layer for testing- Getting Detox running on CI on GitHub Actions for free- Deciding how much of your app to test with Detox: a sliding scale- Fitting Detox into you local development workflow
Prerequisites
- Familiarity with building applications with React Native- Basic experience with Detox- Machine setup: a working React Native CLI development environment including either Xcode or Android Studio
React Summit 2023React Summit 2023
88 min
Deploying React Native Apps in the Cloud
WorkshopFree
Deploying React Native apps manually on a local machine can be complex. The differences between Android and iOS require developers to use specific tools and processes for each platform, including hardware requirements for iOS. Manual deployments also make it difficult to manage signing credentials, environment configurations, track releases, and to collaborate as a team.
Appflow is the cloud mobile DevOps platform built by Ionic. Using a service like Appflow to build React Native apps not only provides access to powerful computing resources, it can simplify the deployment process by providing a centralized environment for managing and distributing your app to multiple platforms. This can save time and resources, enable collaboration, as well as improve the overall reliability and scalability of an app.
In this workshop, you’ll deploy a React Native application for delivery to Android and iOS test devices using Appflow. You’ll also learn the steps for publishing to Google Play and Apple App Stores. No previous experience with deploying native applications is required, and you’ll come away with a deeper understanding of the mobile deployment process and best practices for how to use a cloud mobile DevOps platform to ship quickly at scale.
React Advanced Conference 2022React Advanced Conference 2022
131 min
Introduction to React Native Testing Library
Workshop
Are you satisfied with your test suites? If you said no, you’re not alone—most developers aren’t. And testing in React Native is harder than on most platforms. How can you write JavaScript tests when the JS and native code are so intertwined? And what in the world are you supposed to do about that persistent act() warning? Faced with these challenges, some teams are never able to make any progress testing their React Native app, and others end up with tests that don’t seem to help and only take extra time to maintain.
But it doesn’t have to be this way. React Native Testing Library (RNTL) is a great library for component testing, and with the right mental model you can use it to implement tests that are low-cost and high-value. In this three-hour workshop you’ll learn the tools, techniques, and principles you need to implement tests that will help you ship your React Native app with confidence. You’ll walk away with a clear vision for the goal of your component tests and with techniques that will help you address any obstacle that gets in the way of that goal.you will know:- The different kinds React Native tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting text, image, and native code elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RNTL tests and how to handle them- Options for handling native functions and components in your JavaScript tests
Prerequisites:- Familiarity with building applications with React Native- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Native Testing Library- Machine setup: Node 16.x or 18.x, Yarn, be able to successfully create and run a new Expo app following the instructions on https://docs.expo.dev/get-started/create-a-new-app/