En Microsoft, estamos comprometidos a proporcionar a nuestros equipos las mejores herramientas y tecnologías para construir aplicaciones móviles de alta calidad. React Native ha sido durante mucho tiempo una opción preferida por su alto rendimiento y gran experiencia de usuario, pero conseguir que los stakeholders se suban al carro puede ser un desafío. En esta charla, compartiremos nuestro viaje de hacer de React Native una opción preferida para los stakeholders que priorizan la facilidad de integración y la experiencia del desarrollador. Discutiremos las estrategias específicas que utilizamos para alcanzar nuestro objetivo y los resultados que logramos.
Elevando el Listón: Nuestro Viaje Haciendo de React Native una Opción Preferida
Video Summary and Transcription
Esta charla discute Rack Native en Microsoft y los esfuerzos para mejorar la integración de código, la experiencia del desarrollador y los objetivos de liderazgo. El objetivo es extender Rack Native a cualquier aplicación, utilizar código web e incrementar la velocidad del desarrollador. Se está explorando la implementación de APIs web para React Native, así como la colaboración con Meta. El objetivo final es convertir el código web en código universal y permitir a los desarrolladores escribir el código una vez y que funcione en todas las plataformas.
1. Introducción a Rack Native en Microsoft
Estoy aquí hoy para hablar sobre elevar el listón. Mi nombre es Calcet, un mantenedor de Rack Native en Microsoft. Usamos Rack Native en nuestras aplicaciones móviles más grandes, así como en otras plataformas como Mac OS y Windows. Tuvimos una charla en Chain React sobre el uso y mantenimiento de Rack Native para escritorio. También introdujimos el concepto de la Galaxia de Microsoft, con múltiples Monorepos.
¿Por qué estás aquí? Esto es Zytrack. Vete, diviértete. No, gracias por estar aquí. Realmente os aprecio a todos. Y bueno, como ya dijo nuestro encantador MC, estoy aquí hoy para hablar sobre elevar el listón. Así que, vamos a entrar en materia. Ella también mencionó que mi nombre es Lorenzo Chandra. Esta es mi cara, pero quizás me reconoces más así. Mi nombre es Calcet. He sido un mantenedor de Rack Native desde 2018. Soy un ingeniero de software senior en Microsoft. Y de lo que quiero hablar hoy es básicamente del viaje que internamente en Microsoft, yo y algunos colegas hemos estado atravesando. Verás, nuestro trabajo, específicamente yo y mis colegas, es ser invisibles. Y puedes decir, bueno, eres malo en eso. Estás en el escenario. Puedo verte. Ya estás fallando. Y como, sí, lo acepto. Pero permíteme darte un poco de explicación. Así que, en primer lugar, cuando piensas en Rack Native, por supuesto, piensas en mobile apps. Y en Microsoft, sí, usamos mucho Rack Native en algunas de nuestras mobile apps más grandes. Por supuesto, estas son principalmente aplicaciones Brownfield. Así que, tenemos algunas partes nativas y algunas partes en Rack Native. Pero no solo eso, en realidad usamos Rack Native en todas las otras plataformas que puedes pensar. Lo usamos para Mac OS y Windows. Y tuvimos una charla en Chain React a principios de este año de dos de mis colegas, Chiara y Shivyan. Y te recomendaría mucho que la veas porque realmente se adentra en el aspecto de escritorio de usar y mantener Rack Native para esas plataformas. Pero no solo eso, hace unos años, introdujimos el concepto de la Galaxia de Microsoft. Verás, Microsoft es una gran empresa. No solo tenemos un Monorepo, tenemos muchos de ellos.
2. Soluciones para una Integración de Código Sin Problemas
Al trabajar en Rack Native, garantizamos una integración de código sin problemas en diferentes aplicaciones y Monorepos. Nuestro objetivo es permitir a los desarrolladores aprovechar las herramientas en lugar de luchar contra ellas. Desafíos como necesidades variadas, diferentes versiones de Rack Native y el tamaño del paquete se abordan a través de nuestras soluciones, incluyendo la aplicación de prueba React Native. Esta aplicación sandbox abstrae los puntos de dolor de usar una aplicación React Native vainilla y soporta múltiples versiones. También soporta la nueva arquitectura y ofrece un modo de aplicación única experimental. Nuestras soluciones cubren las plataformas iOS, Android, MacOS y Windows.
Y cuando trabajamos en Rack Native, por supuesto, quieres tener algo que pueda ser usado en diferentes aplicaciones. Así, por ejemplo, creo que recientemente hemos realizado el despliegue completo de una de las principales experiencias de Rack Native en todas las aplicaciones principales. Y para que eso ocurra, básicamente, tenemos todos estos diferentes Monorepos interactuando entre sí, pero eso aumenta la complejidad de usar Rack Native bastante. Así que, ahí es donde entramos yo y mis colegas. Básicamente nos aseguramos de que todas estas diferentes partes de la galaxia, todos estos diferentes planetas puedan usar el código, puedan tomar el código de un Monorepo, ponerlo en el otro, y todo debería funcionar. Así que, somos invisibles en ese sentido, porque queremos que la gente pueda trabajar sin problemas en su código, y luego ese código vaya a la aplicación final, a lo que llamamos una aplicación anfitriona, normalmente los productos que usas. Para decirlo en un término más apropiado, lo que intentamos hacer es básicamente permitir a los desarrolladores que trabajan en nuestros productos aprovechar las herramientas en lugar de luchar contra ellas. Y todos, bueno, algunos de vosotros sois desarrolladores de Rack Native, así que probablemente sabéis que puede haber puntos de dolor potenciales. Y en Microsoft, tenemos algunos que son muy específicos para este enfoque de Galaxia que tenemos. Así que, cuando tenemos cientos de ingenieros repartidos en muchos proyectos diferentes, si todos tienen necesidades diferentes, si usan diferentes versiones de Rack Native, diferentes versiones de sus bibliotecas, eso crea un problema. Si el tamaño del paquete es demasiado grande, eso es definitivamente un problema, porque nuestras aplicaciones como Office, esa es una aplicación para, ya sabes, Word, Excel, PowerPoint, todo en una aplicación móvil, como sabes, hay algunas políticas en las tiendas. Así que, siempre estamos justo por debajo de eso, y necesitamos mantenerlo allí por supuesto. Y sabes, actualizar, todos conocemos la historia cuando se trata de actualizar, veo que todos están como, oh dios mío. Y lo siento, es en parte mi culpa, estamos intentando hacerlo mejor. Pero sí, y a veces el código no funciona, como funciona en tu sitio, en tu monorepo donde haces desarrollo, y luego, ya sabes, lo envías a Outlook y luego lo meten en su base de código y no funciona. Así que, muchas de estas cosas, por supuesto, no pueden ser necesariamente resueltas a nivel de núcleo. Así que, al enviar PRs contra React Native, a veces necesitamos tomar las cosas en nuestras propias manos. Y para hacer eso, hemos estado trabajando en dos soluciones principales. La primera es lo que llamamos el banco de pruebas. Esto se llama la aplicación de prueba React Native, y es básicamente una aplicación sandbox React Native donde hemos abstraído, el 99.9% de los puntos de dolor de usar una aplicación React Native vainilla. Esta soporta desde la 64 hasta la 72, y estamos trabajando en la 73, y básicamente esto significa que tienes el sandbox y puedes muy rápidamente, y te lo mostraré en un momento, cambiar de una versión de React Native a la otra para que en tu entorno de prueba, puedas verificar que todas las versiones que tus aplicaciones anfitrionas están usando, su código va a funcionar, básicamente. Soporta la nueva arquitectura. Soporta los plugins de configuración de la nube Xfce. Estamos intentando hacerlo lo más utilizable posible para la comunidad, también. Y también tenemos un modo de aplicación única experimental. Así que si tienes un pequeño proyecto paralelo que quieres probar para poner en una diferente aplicación vainilla de React, por favor, habla conmigo, porque estamos buscando sacrificios, personas con las que podamos tener una asociación y probar estas cosas. Y por supuesto, no es sólo para iOS y Android. Nos importa MacOS y Windows, también. Así que, de serie, metes tu código ahí y funciona en todas estas diferentes plataformas. No necesitas ocuparte de eso.
3. Mejorando la Experiencia del Desarrollador y RNX Kit
Hemos creado un monorepositorio llamado RNX Kit, que es un conjunto de herramientas que incluye varios plugins para Metro, perfiles personalizados para Babel y ESLint, y un reemplazo de CLI. Un ejemplo es la función de tree shaking en Metro, que ha mostrado grandes resultados. Actualizar de una versión a otra puede ser un proceso que consume mucho tiempo, pero al usar las herramientas de RxKit, como Reckon Native Desktop, el proceso puede ser significativamente más rápido. Mira el video para ver una demostración del comando de aplicaciones alineadas y el comando de estilo YARN para la base de código.
El otro cubo, la otra solución principal en la que estamos trabajando es básicamente mejorar la experiencia general del developer experience y crear plugins adicionales para nuestras necesidades. Y hemos puesto todas estas cosas diferentes que todos estos, puedes ver allí, es muy largo. Hemos puesto todo eso en este monorepositorio llamado RNX Kit, que es React Native Experiences y Kit es como, porque es un conjunto de herramientas, como estamos poniendo todo allí, y puedes simplemente elegir lo que quieras. Entre las varias cosas, tenemos algunos plugins para Metro. Por ejemplo, lo principal que tenemos es un tree shaker para Metro porque ahora mismo no lo tiene. Tenemos perfiles personalizados para Babel, ESLint, y un reemplazo para un CLI incluso porque básicamente queríamos ajustes adicionales, banderas adicionales que quieres pasar al CLI cuando haces, por ejemplo, el bundling. Y simplemente pensamos, bueno, si solo ponemos un poco más encima, podemos enviarlo a todos nuestros clientes internos. Simplemente ejecutas el bundle y todas las configuraciones adicionales, nos hemos ocupado de eso. Y tenemos una charla especial anunciando el repositorio RNX Kit en 2022 por Dan Foxman. Y sí. Así que como mencionaba, uno de los ejemplos de cosas que tenemos en allí es el tree shaking en Metro. Por supuesto, todo esto es de código abierto. Así que tenemos algunas personas en la community que también pueden usarlo y algunos resultados bastante interesantes. Tree shaking, como mencionaba, el bundling es muy importante para nosotros. Así que hemos estado intentando literalmente afeitar tanto como podamos y el hecho de que también sea utilizable por la community fue una gran señal para nosotros. Por supuesto, cuando se trata de este tipo de cosas, son geniales, pero la mejor parte viene cuando las juntas. Así que como mencionamos, actualizar puede ser mucho, puede llevar meses para algunas de nuestras bases de código más grandes. Así que puedes estar familiarizado con esto. Como cuando intentas actualizar de una versión a la siguiente de Reckon Native, bueno, aquí, esta captura de pantalla es de 68 a 71 creo porque ese fue uno de los principales saltos que hicimos en uno de nuestros monorepos. Esto puede ser bastante largo y bastante grande. Así que lo que hemos estado haciendo es hacerlo sin esfuerzo de alguna manera, al menos para algunas bases de código diría yo. Así que cuando se trata de Reckon Native Desktop, si lo emparejamos con una de las otras herramientas en RxKit, verás que las cosas pueden ser mucho más rápidas que los meses. Así que voy a hacer una demostración. Y voy a prevenir esto con el hecho de que cuando estuve en Reckon Native Europe a principios de este año, mi portátil tenía un 16% de batería. Todo el mundo estaba como, ¿va a llegar al final? No voy a desafiar a los dioses de las demostraciones en vivo de nuevo. Voy a simplemente mostrarles un video, básicamente. Así que lo que tenemos aquí es el primer comando, aplicaciones alineadas. Y como puedes ver, este video no está acelerado. Esto tomó tres segundos. Después de esto,
4. Explicando Restyle y Simplificando la Reejecución
Esto es Restyle, una biblioteca del sistema de diseño de Shopify. Cambiamos la versión de Rack Native e hicimos una instalación de YARN y una instalación de pod. La aplicación ya se está reejecutando, tardando solo 33 segundos para iOS. Android también está funcionando perfectamente. Eliminamos la fricción para los desarrolladores simplificando el proceso de cambio de versiones y realizando una instalación de YARN.
5. Desafíos y Objetivos de Liderazgo
Hemos estado trabajando en una gran cantidad de problemas y agradecemos a todos los que han contribuido abriendo problemas y enviando PRs. Nuestro objetivo es mejorar la facilidad de uso y la transparencia de Rack Native. Hemos realizado mejoras en la historia de breadability, hemos abierto el repositorio RxGit para contribuciones de código abierto e introducido características como el tree shaking. Sin embargo, nuestro liderazgo quiere más. Quieren extender Rack Native a cualquier aplicación, utilizar código web y aumentar la velocidad de los desarrolladores.
Así que, básicamente, lo que ha estado pasando es que nuestro liderazgo es como, sí, sí, todo bien, todo bien, pero quiero más. Quiero llevar tu característica de Rack Native que has construido aquí, y quiero ponerla en cualquier aplicación. No quiero ser forzado a, ya sabes, sólo ponerla en una o dos aplicaciones que ya tienen todas las cosas construidas para el soporte de Brownfield. Y también, ¿por qué no puedo simplemente usar mi código web? Escribí una versión de React de esto. ¿Por qué no puedo simplemente - sólo quiero tomar esta cosa que escribí una vez, y quiero hacerla funcionar en todas estas diferentes plataformas. Y básicamente, lo que estas cosas tienen en común es que nuestro liderazgo quiere velocidad de desarrollo. Como, quieren aumentar la
6. Código Universal y React Native
Quieren llevar el código lo más rápido posible de las manos del desarrollador a la producción en todas nuestras plataformas. La velocidad de desarrollo es algo en lo que realmente estamos tratando de enfocarnos en este momento. Quieren que esta superposición entre web y React Native sea mucho más prominente. Hemos descubierto una forma de tomar el código web y hacerlo funcionar en React Native. Es literalmente el mismo código exacto. Lo principal para hacer que el código funcione dentro de la web y nativo es la API web y el navegador con el getBattery.
7. Implementación de APIs web para React Native
Las APIs web son formas bien definidas y estandarizadas para que los codificadores web interactúen con el navegador y accedan a características adicionales. Implementar APIs web para React Native requeriría una implementación intencional de solo las APIs necesarias para nuestros productos. También implicaría pagar por jugar, implementando APIs para múltiples plataformas. Nuestro objetivo es hacer que el empaquetador sea más inteligente y hemos optado por la ruta de código abierto, ya que estamos comprometidos con el código abierto. Comenzamos con un RFC, que es público en el RnsKit.
8. RFC de Gran Imagen y Colaboración
Este es el RFC de gran imagen donde recopilamos ideas y colaboramos con los ingenieros de Meta. Nuestro objetivo es la transparencia y la colaboración. Si estás interesado, por favor lee y comenta.
9. Próximos Pasos y Colaboración con Meta
El próximo paso es trabajar en la mejora y ajuste a los requisitos que surgen en el RFC. La API web del estado de la batería se ha fusionado y está en estado de POC, funcionando en las cuatro plataformas. También hemos mejorado el script de filtrado inicial creando una mejor herramienta con Rust para tomar decisiones basadas en datos. Este es el plan maestro que aún es experimental y requiere más trabajo. Esperamos colaborar con Meta y compartir soluciones.
Y luego la otra gran cosa en la que hemos mejorado es ese script de filtrado inicial que estamos mostrando, lo hemos descartado, porque estábamos como, bueno, es muy arbitrario. Estábamos como eligiendo algo así como de la nada, como cuáles queríamos y cuáles no. Así que hicimos una mejor herramienta con Rust para ir a través de una base de código y averiguar cuáles APIs web se utilizan en esa base de código. Y eso nos ayuda a tomar decisiones basadas en data, lo cual es muy importante, especialmente para algo de este tamaño. Así que, sí, esto es prácticamente todo. Es como el plan maestro. En lo que yo y mis colegas hemos estado trabajando, en lo que trabajaremos mucho todavía. Por supuesto, es muy experimental. Así que por favor no lo lleves a producción en ningún lugar. No está listo. Probablemente pasará años antes de que esté en buena forma para eso. Y por supuesto, mencionaba antes que la idea es y hemos estado interactuando con Meta. Meta ya ha publicado algunos RFCs propios, algunas publicaciones de blog en esta área. Así que realmente esperamos colaborar más y compartir tanto como podamos a medida que avanzamos y descubrimos juntos las soluciones. Pero sí, cerrando. Estamos un poco pasados de tiempo. Así que voy a ser muy rápido.
10. Elevando el Estándar y Código Universal
Hemos estado integrando la experiencia del desarrollador tanto como podemos, poniendo todo en código abierto. Pero no es suficiente. Estamos tratando de elevar el estándar y convertir este código web en código universal. La colaboración es clave, y esto vale la pena investigar. Una vez que lleguemos allí, si llegamos allí, eso es lo que realmente se verá como Invisible. Solo escribirás tu código una vez, en tu navegador, y funcionará en todas las plataformas.
La Developer experience es parte de Microsoft. Hemos estado haciendo mucho. Hemos estado integrando la developer experience tanto como podemos. Hemos estado poniendo todo en código abierto para que todos puedan aprovecharlo, pero no es suficiente. Así que lo que hemos estado haciendo es tratar de elevar el estándar, hacerlo mucho mejor, y convertir este código web en código universal. Al menos ahora está en esta fase experimental y realmente creemos que la colaboración es clave y esto vale la pena investigar. Así que tal vez el próximo año voy a tener una charla real donde voy a decirles, ja, esto realmente está funcionando. Ja ja, tenía razón. Veremos eso, pero probablemente será así. Pero lo que creo es que una vez que lleguemos allí, si llegamos allí, básicamente eso es lo que realmente se verá como Invisible. Solo escribirás tu código una vez, lo escribirás en tu navegador y luego mágicamente el código funcionará en todas las plataformas. Y sí. Muchas gracias por escucharme. Estas son un montón de cosas.
QnA
Implementando APIs Web y Compatibilidad
Actualmente estamos implementando una API de almacenamiento web y tenemos planes de trabajar en otras APIs web. Nuestra intención es permitir a los desarrolladores tomar su código web y hacer que funcione en React Native. Esto es lo opuesto a React Native web, donde el código de React Native se lleva a la web. React Native web es una gran solución para expandir una aplicación de React Native a la web. En cuanto a las razones para usar las APIs web de RN web frente a algo como Lonic, no estoy seguro.
Explorando Ionic y Componentes Universales
Ionic es un gran proyecto, pero elegimos centrarnos en React Native ya que se alinea con lo que conocemos y hemos estado haciendo. Creemos en el concepto de componentes universales pero enfatizamos la importancia de las interfaces de usuario adaptadas a la plataforma. La interfaz de usuario debe reflejar el sistema operativo en el que se encuentra para proporcionar una experiencia natural al usuario.
Uso de React Native y Casos Peculiares
En React Native Europe, hablamos de cómo usamos React Native para Copilot AI en varias plataformas. Es un caso de uso peculiar, pero lo usamos mucho. Mira la charla de Kader Fossani en React Native Europe para aprender más sobre nuestros diferentes casos de uso.
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
Workshops on related topic
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
Table of contents:
1 - The infamous "N+1" problem: Jonathan Baker - Let's talk about what it is, why it is a problem, and how Shopify handles it at scale across several GraphQL APIs.
2 - Contextualizing GraphQL APIs: Alex Ackerman - How and why we decided to use directives. I’ll share what directives are, which directives are available out of the box, and how to create custom directives.
3 - Faster GraphQL queries for mobile clients: Theo Ben Hassen - As your mobile app grows, so will your GraphQL queries. In this talk, I will go over diverse strategies to make your queries faster and more effective.
4 - Building tomorrow’s product today: Greg MacWilliam - How Shopify adopts future features in today’s code.
5 - Managing large APIs effectively: Rebecca Friedman - We have thousands of developers at Shopify. Let’s take a look at how we’re ensuring the quality and consistency of our GraphQL APIs with so many contributors.
Comments