Elevando el Listón: Nuestro Viaje Haciendo de React Native una Opción Preferida

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

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.

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,

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

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.

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.