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.
Voy a ejecutar básicamente el comando de estilo
YARN para la base de código. Y mientras esto se ejecuta, lo que voy a explicarles es que esto es Restyle. Esta es una biblioteca del sistema de diseño de
Shopify. Así que no es un proyecto POC. Este es uno verdadero que existe. Y ejecutamos el comando de aplicaciones alineadas, que básicamente recorre tu base de código. Le dices, oye, quiero llegar a esta nueva versión 72. Entonces lo que hace es básicamente cambiar tu paquete. Pone la versión correcta de todos los paquetes que conocemos. Y luego hicimos simplemente una instalación de
YARN. Y en este punto, lo que estamos haciendo, ya hemos terminado técnicamente. Ya estamos reejecutando la aplicación. Así que en 30 segundos, básicamente, hicimos aplicaciones alineadas de
YARN que cambian la versión de Rack Native o Rack Native Desktop y las otras bibliotecas involucradas. Hicimos una instalación de
YARN para obtener las nuevas versiones de los paquetes y ahora vamos a reejecutarla. Lo importante que hay que entender aquí es que básicamente cuando usas Rack Native Desktop, sabes todos los cambios, todas las cosas masivas que mostrábamos antes. No necesitas hacer nada de eso. Las únicas cosas que necesitas hacer es cambiar la versión de Rack Native y hacer una instalación de
YARN y una instalación de pod. Para iOS, por supuesto, y Android, simplemente haces una instalación de pod
yarn y luego lo ejecutas. Y como puedes ver aquí, la aplicación ya se está reejecutando. Esto tardó, como puedes ver allí, 33 segundos para reejecutar la aplicación de iOS. Solo para completar, también voy a mostrar que Android también está funcionando. Básicamente, es muy, muy fácil. Estamos eliminando mucha fricción porque si nuestros desarrolladores están trabajando en la experiencia en esta burbuja donde solo tienen su bucle de desarrollo, usan este sandbox, si todo lo que necesitan para ellos cambiar la versión y hacer una instalación de
YARN, estamos eliminando mucha fricción para ellos para poder trabajar, y especialmente en una situación como esta donde puedes cambiar muy rápidamente entre las diferentes versiones de
React Native, y ahí lo tienes. Como puedes ver aquí, está funcionando para iOS y Android bastante sin problemas. Gracias. Lo juro, también puedo hacerlo en vivo. Es la primera charla de la mañana. Hasta ahora, he sido muy positivo, como, oh, mira
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.
esto. Esto es increíble. Esto es genial. Por supuesto que no. También tenemos muchos problemas que estamos resolviendo. Aprecio mucho a todos los que han estado enviando problemas abiertos, diciéndonos hey, he usado esto. Esto no funciona, y también enviando PRs. Sólo quería también agradecer, gracias por sus contribuciones. Nos están ayudando a mejorar para todos. Así que sí. Gracias a todos. Y luego, volviendo a lo invisible, lo que les he mostrado hasta ahora parecía bastante hecho, ¿verdad? Está funcionando. No realmente. Pero estamos llegando allí, ¿verdad? Así que lo que hemos construido hasta ahora, para darles un resumen súper rápido y también mencionar un par de cosas que mencionaste hasta ahora, básicamente, hemos mejorado la facilidad de uso. Hemos creado, como, todos estos presets de burbuja y todo para tener defaults más inteligentes. Estamos tratando de ser transparentes. Estamos poniendo todo lo que podemos en los repositorios de SOAPer en GitHub. Hemos intentado mejorar en la historia de breadability, especialmente para los bucles de desarrollo estándar a través de aplicaciones alineadas y test app. Y luego, por supuesto, tenemos más
advanced escenarios. Todas las cosas que pudimos abrir están en el repositorio RxGit. Así que, por ejemplo, si tienes una aplicación Brownfield, es posible que quieras mirar la biblioteca de Rack Native host que tenemos allí. Callstack también publicó un post en su blog sobre eso. Tenemos tree shaking. Tenemos algunas cosas que funcionan mejor para
monorepos y TyScript. Así que, eso es genial, ¿verdad? Es todo genial. Hemos estado haciendo mucho y todo está funcionando. No es suficiente.
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.
velocidad de desarrollo. Quieren llevar el código lo más rápido posible de las manos del desarrollador a la producción en todas nuestras plataformas. Porque de nuevo, Microsoft no es solo - estamos tratando de entregar a iOS y Android, pero iOS, Android, Windows, macOS, y web. Entonces, es un poco más, y especialmente cuando estas aplicaciones son tan grandes, tan llenas de características, sabes, las cosas pueden tardar meses o años. Entonces, la velocidad de desarrollo es algo en lo que estamos realmente tratando de enfocarnos en este momento. Entonces, de alguna manera, lo que están pidiendo, sabes, velocidad de desarrollo, quieren que esta, como, superposición entre web y
React Native sea mucho más prominente. Entonces, ¿quieren código universal? Esto es un poco difícil, ¿verdad? Entonces, déjame darte un rápido ejemplo de cómo podría verse esto. Entonces, lo que tenemos aquí es básicamente un
Vite en él. Y aquí, lo único que existe, fuera de la plantilla es este use battery status. Es solo un hook. Entra en la API web para el estado de la batería. Y lo muestra. Muy fácil. Muy simple. La batería está al 100%. Entonces, tenemos el 100%. ¿Qué se necesitaría para hacer que funcione en
React Native? Justo fuera de la caja, el mismo código exacto. Bueno, por supuesto, va a haber un truco mágico. Pero lo que voy a mostrarles es que descubrimos una forma en que puedes tomar ese código web, esa carpeta, la aplicación que estaba mostrando antes está dentro de esta aplicación de prueba. Puedo importar el mismo archivo exacto, usar el hook, y luego en el estilo de
React Native, con una vista y una etiqueta, puedo hacer que funcione allí. Es literalmente el mismo código exacto. Y para probar Ahora tenemos 1 mostrando en todas partes, en iOS está mostrando menos 1 porque razones. Si cambio el código a 100, hago una multiplicación aquí, y solo guardo, como pueden ver, está funcionando en todas partes. Entonces, esto es para demostrar que esto se puede lograr de alguna manera. Pero, ¿qué se necesita para llegar allí? Por supuesto, este fue un ejemplo muy... No es como el ejemplo anterior donde todo es como, no, esto no está en producción, estas son cosas que realmente existen. No, esto es muy personalizado, por supuesto. Pero era solo para demostrar el punto. Entonces, lo principal para hacer que algún código funcione dentro de web y nativo es... Si miras este código, este es básicamente el que estaba usando antes, es que tenemos esta API web. Tenemos este 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.
y es algo que no tenemos en
React Native. Entonces, ¿cómo lidiamos con eso? Bueno, en primer lugar, ¿qué son las APIs web? Si no lo sabes, probablemente todos lo sepan, pero básicamente estas son las formas en que los codificadores web pueden interactuar con el navegador para obtener características adicionales. Y lo bueno de ellas es que están bien definidas y estandarizadas. Esto significa que si necesitas interactuar con la batería, está la API de la batería. Y esa es la forma en que se supone que se debe interactuar con ella, como los métodos, lo que se obtiene de ella, todo está definido. No necesitas idear tu propia solución para ello. No necesitas decir, ¿cómo voy a llamar a este método? ¿Cómo voy a recoger el nivel de la batería? Simplemente usas esta API web. Y por supuesto, hay muchas de ellas para toda la web. Son más de 1000. Y porque es estándar, significa que no hay margen para la interpretación, lo cual es algo muy, muy interesante porque de repente, es solo cuestión de implementarlo, ¿verdad? Por supuesto, no lo tenemos para Act Native, pero cuanto más pensábamos en ello, más nos preguntábamos, ¿qué se necesitaría? Así que empezamos a hacer una especie de investigación y básicamente hicimos un script masivo. No necesitas leer nada de esto, no te preocupes. Pensamos, vale, tomemos todas las interfaces. Descartemos las que no queremos. Y veamos cuántas nos quedan. Y básicamente de 1000, bajamos a 200, lo cual es como, vale, esto todavía es mucho. Así que nos dimos cuenta de que si alguna vez intentáramos algo así, para implementar estas web APIs para
React Native es en primer lugar, necesitamos hacerlo intencionalmente. Solo implementamos lo que necesitamos para nuestros productos. La segunda cosa es, por supuesto, es un pagar para jugar. Si fuéramos a implementar una API web, necesitamos implementarla para Android, iOS, macOS y Windows. Si implementamos dos, tenemos como ocho implementaciones diferentes. En tu paquete final, solo necesitas la específica. En el de iOS, necesitas la batería para iOS. Necesitábamos encontrar una forma de hacer que la
tooling, el
bundler sea más inteligente. Por supuesto, intentamos ir por la ruta de código abierto porque queremos que todos se beneficien de ello. Creemos en el código abierto. Soy de Microsoft. Algunas personas todavía están como, ¿huh, Microsoft y código abierto? No, realmente estamos comprometidos con ello. Puedo jurarlo. Lo primero que hicimos fue un RFC. Hicimos este RFC a principios de este año. 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.
con tener conversaciones. Este es como el RFC de gran imagen donde estamos intentando, sabes, recopilar todas las diferentes ideas. Por supuesto, para nosotros, esto significa que estas cosas necesitan funcionar en iOS, en Windows y MacOS. Quería señalar muy rápidamente el hecho de que hemos estado hablando con la gente de Meta, los ingenieros de Meta, sobre este RFC. El objetivo es muy colaborativo. Realmente queremos que esto sea lo más transparente y colaborativo posible. Así que también, realmente, si estás interesado en este problema, como, este RFC es donde estamos intentando resolver las grandes conversaciones de imagen sobre ello, así que por favor lee. Ya conozco a una persona en esta sala que dejó algunos comentarios, así que gracias. Háganos saber sus pensamientos, está allí.
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.
Es para que lo leas y comentes. Por supuesto, el siguiente paso después de eso es lo que te mostraba antes. Hay una solicitud de extracción a la que puedes ir, es un borrador de solicitud de extracción con todas las instrucciones para ejecutarlo localmente. Pero básicamente hicimos una API de batería, perdón, API de estado de batería, que resulta que, no realmente, está obsoleta por razones de
security. Así que estamos como, elegimos una, y elegimos la más cruda posible. Como, eh, lo que sea, es solo un PLC. Así que funciona lo suficientemente bien. Por supuesto, el paso después de eso, porque ahora hemos estado trabajando en esto durante un par de meses, es que todavía estamos mejorando. Todavía estamos aprendiendo mucho. Todavía estamos tratando de hacer las cosas mejor y ajustarnos a los requisitos que surgen en el RFC y esas cosas. Así que por ejemplo, para la API web del estado de la batería, terminamos fusionando el PR. Y tiene las cuatro plataformas funcionando, así que también puedes probarlo en Windows y MacOS. Y todavía está muy en estado de POC. Como, está ahí para demostrar el punto.
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.
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.
Ese soy yo. Gracias. Así que tenemos muchas preguntas entrando. Comenzaremos con la más emocionante. ¿Qué APIs web estás esperando más cuando usas
React Native? Creo que ahora mismo lo que estamos buscando, ya comenzamos a implementar la siguiente. Y queremos implementarlo una vez más correctamente es en almacenamiento. Así que estamos implementando una API de almacenamiento web. Así que probablemente esa sea la primera que vamos a hacer a continuación. Tenemos un problema abierto en el repositorio de OrangeKit donde estamos tratando de hacer una lista corta de los que planeamos trabajar. Y si quieres trabajar tú mismo en uno, puedes dejar un comentario y ellos dirán, hey, quiero trabajar en esto. Tenemos, por ejemplo, a Matt Harget que ya anunció que quiere trabajar en los que están alrededor del multimedia para
VR. Así que sí, es muy emocionante que tan pronto como empezamos a entregar más sobre eso, otras personas empezaron a saltar. Así que podemos dividir el trabajo y todos pueden trabajar en paralelo. Así que ahora estamos enfocados en almacenamiento, a continuación. Perfecto. Gracias. Y otra pregunta, ¿esto significa que tu código web necesita ser escrito usando
React Native web o similar? Bueno, la intención general es literalmente que tomes tu código web y que funcione en
React Native. Así que de alguna manera es como el 180 de
React Native web.
React Native web es como escribes tu código
React Native y lo llevas a la web. Así que escribes tu texto de vista y se porta a
React Native web a web a través de
React Native web. Este enfoque es algo así como el 180 de eso. Como tienes tu código web y así escribes tu div, span, p, y esos funcionan en
React Native. Así que sí, es algo así como lo opuesto pero no en como tirando sombra en
React Native web. Es un proyecto impresionante y si tienes una aplicación
React Native y estás tratando de expandir a la web probablemente esa sea la solución correcta para ti. No es solo lo que necesitamos internamente. Gracias y solo nos quedan cinco minutos. Voy a tener que intentar apresurarme a través de tantos como pueda pero ¿esto significa que los códigos web necesitan... Oh lo siento. Acabo de decir eso. Bueno. ¿Cuáles son las razones para usar algo como las APIs web de RN web versus algo
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.
como... ¿es Lonic? Honestamente, no lo sé. ¿Iconic? Sí. Así que
Ionic, creo que es un gran proyecto. Creo que no exploramos esa opción. Estamos simplemente... nos estamos centrando en lo que tenemos control y lo que sabemos. Así que
React, lo usamos mucho. Así que ni siquiera sé si
Ionic soporta plataformas de escritorio. Tal vez lo hagan, pero para nosotros fue más natural como... está bien, construyamos sobre lo que sabemos, lo que hemos estado haciendo hasta ahora. Mantengamos la dirección. Así que creo que
Ionic es un producto muy válido. No es solo lo que estamos seguros de que podemos trabajar rápidamente. Así que simplemente seguimos quedándonos con
React Native con este enfoque de APIs web. Me encanta y otra que tiene cinco me gusta. Estás compartiendo lógica de negocio. ¿Qué opinas sobre los componentes universales y la representación de la interfaz de usuario? Oh chico, esto me va a hacer cancelar en Twitter, ¿no es así? No no no. Así que voy a decir que, por ejemplo, amo a Tamaguy. Amo a Nate. Ha estado haciendo algunas cosas geniales y muy inteligentes allí. Tenemos nuestras propias bibliotecas de sistemas de
design que estamos apuntando a conseguir al punto universal. Todavía creo que necesitamos separar tener componentes universales de una API universal. La interfaz de usuario debería ser un reflejo del sistema operativo en el que se encuentra. Debería sentirse natural para el cliente. Así que si estás en Android, no quieres una aplicación que parezca iOS. Quieres una aplicación que parezca Android. Así que incluso si estás usando el mismo botón de la misma biblioteca de
design, necesitas tener en cuenta que tu usuario está en su plataforma. Así que quieres adaptar tus interfaces de usuario a la plataforma, incluso si tus componentes son universales. Gracias. Eso
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.
fue un buen esquive, literalmente esquivando. Sí. Me encanta cómo todos también se dieron cuenta de eso. Me encanta la autoconciencia. Sí. Entonces, ¿puedes compartir algún caso reciente en el que hayas utilizado
React Native? Voy a responder, por supuesto, es Microsoft, es grande, no necesariamente sé todo lo que está sucediendo. En
React Native Europe, hablamos del hecho de que para Copilot
AI en las diversas plataformas, utilizamos
React Native de ciertas maneras. Es un caso de uso muy peculiar, pero lo usamos mucho. Recomendaría ver esta charla de mi jefe, Kader Fossani, de
React Native Europe para aprender más sobre todas las diferentes formas en las que lo hemos estado utilizando porque hay muchas. No estamos solo haciendo una charla completa, como, hey, aquí está todo el catálogo. Así que sí, hay muchos de esos. Creo que esta puede ser la última pregunta. Solo tenemos dos minutos más. Sin presión. Sin presión en absoluto. ¿Recomiendas migrar una aplicación existente con
modules nativos personalizados a RnxKit? Las actualizaciones serán más fáciles tal vez. Entonces, si tienes una aplicación
React Native solo para iOS y Android, puedes intentar migrarla a la aplicación de prueba
React Native para usar las APIs web, los
modules, y las otras cosas que tenemos en RnxKit. Eso es más como una tienda de todo en uno. Entonces vas allí, miras la lista, y, como, oh, quiero el tree shaking. Entonces puedes seguir la guía y agregar tree shaking a tu aplicación
React Native. Para las APIs web, una de las cosas que hemos estado tratando de hacer y es una de las cosas que mencionamos en el RC es que queremos tratar de aprovechar tanto como podamos, lo que ya existe en la
community. Entonces, como, por ejemplo, si había un módulo de estado de batería de
React Native ya, nuestro objetivo habría sido simplemente importar eso y simplemente escribir las interfaces para que coincidan uno a uno con la especificación de la API web. Así que esperamos llegar a un punto donde todas estas APIs web estén lo suficientemente completas para que puedas usarlas, nuestra idea es que la migración debería ser bastante rápida porque tratamos de aprovechar tanto como lo que existe en la
community y queremos colaborar con los mantenedores de esos. Así que cosas de
React Native tal vez si la aplicación es lo suficientemente pequeña puedes intentar eso sería interesante. Tenemos el mod de aplicación única pero RxKit es más como ir allí, mirar la lista de herramientas, ver si hay algo que te atraiga y quieras probar. ¡Así que sí, ve si te atrae! Son exactamente las 10.30 ahora. Terminamos justo a tiempo.
Comments