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.
This talk has been presented at React Advanced Conference 2023, check out the latest edition of this React Conference.
FAQ
Rack Native es una tecnología utilizada en Microsoft para desarrollar aplicaciones móviles y de escritorio. Se emplea tanto en aplicaciones Brownfield, que combinan componentes nativos con otros en Rack Native, como en otras plataformas como macOS y Windows.
La Galaxia de Microsoft es una metáfora utilizada para describir la vasta y compleja infraestructura de Monorepos dentro de la empresa. Estos Monorepos permiten que diferentes equipos y aplicaciones compartan y reutilicen código de manera eficiente.
Los mantenedores invisibles en Microsoft trabajan para asegurar que el código pueda fluir sin problemas entre los diferentes 'planetas' de la Galaxia de Microsoft, es decir, entre los diferentes Monorepos, facilitando así el desarrollo y la implementación de aplicaciones.
El banco de pruebas en React Native es una aplicación sandbox que facilita la prueba de diferentes versiones de React Native, ayudando a verificar la compatibilidad y funcionamiento del código en las aplicaciones anfitrionas.
El RNX Kit es un monorepositorio que contiene un conjunto de herramientas y plugins desarrollados por Microsoft para mejorar la experiencia de desarrollo en React Native. Incluye utilidades como un tree shaker para Metro, perfiles personalizados para Babel y ESLint, entre otros.
Microsoft está trabajando en mejorar la experiencia de desarrollo de React Native para hacerlo más universal, permitiendo que el código no solo funcione en iOS y Android, sino también en macOS, Windows y web, a través de la implementación de APIs web estandarizadas.
Microsoft enfrenta desafíos como la gestión de diferentes versiones de React Native y sus bibliotecas en múltiples proyectos, el tamaño del paquete de las aplicaciones, y la complejidad del proceso de actualización en grandes bases de código.
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.
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
Short description:
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
Short description:
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
Short description:
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
Short description:
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
Short description:
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
Short description:
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
Short description:
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
Short description:
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
Short description:
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
Short description:
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
Short description:
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
Short description:
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.
The Talk discusses React Forget, a compiler built at Meta that aims to optimize client-side React development. It explores the use of memoization to improve performance and the vision of Forget to automatically determine dependencies at build time. Forget is named with an F-word pun and has the potential to optimize server builds and enable dead code elimination. The team plans to make Forget open-source and is focused on ensuring its quality before release.
Mishko, the creator of Angular and AngularJS, discusses the challenges of website performance and JavaScript hydration. He explains the differences between client-side and server-side rendering and introduces Quik as a solution for efficient component hydration. Mishko demonstrates examples of state management and intercommunication using Quik. He highlights the performance benefits of using Quik with React and emphasizes the importance of reducing JavaScript size for better performance. Finally, he mentions the use of QUIC in both MPA and SPA applications for improved startup performance.
Suspense is a mechanism for orchestrating asynchronous state changes in JavaScript frameworks. It ensures async consistency in UIs and helps avoid trust erosion and inconsistencies. Suspense boundaries are used to hoist data fetching and create consistency zones based on the user interface. They can handle loading states of multiple resources and control state loading in applications. Suspense can be used for transitions, providing a smoother user experience and allowing prioritization of important content.
Tom Pressenwurter introduces Redwood.js, a full stack app framework for building GraphQL APIs easily and maintainably. He demonstrates a Redwood.js application with a React-based front end and a Node.js API. Redwood.js offers a simplified folder structure and schema for organizing the application. It provides easy data manipulation and CRUD operations through GraphQL functions. Redwood.js allows for easy implementation of new queries and directives, including authentication and limiting access to data. It is a stable and production-ready framework that integrates well with other front-end technologies.
State management in React is a highly discussed topic with many libraries and solutions. Jotai is a new library based on atoms, which represent pieces of state. Atoms in Jotai are used to define state without holding values and can be used for global, semi-global, or local states. Jotai atoms are reusable definitions that are independent from React and can be used without React in an experimental library called Jotajsx.
Today's Talk discusses the importance of managing technical debt through refactoring practices, prioritization, and planning. Successful refactoring requires establishing guidelines, maintaining an inventory, and implementing a process. Celebrating success and ensuring resilience are key to building a strong refactoring culture. Visibility, support, and transparent communication are crucial for addressing technical debt effectively. The team's responsibilities, operating style, and availability should be transparent to product managers.
Construye Aplicaciones Modernas Utilizando GraphQL y Javascript
Featured Workshop
2 authors
Ven y aprende cómo puedes potenciar tus aplicaciones modernas y seguras utilizando GraphQL y Javascript. En este masterclass construiremos una API de GraphQL y demostraremos los beneficios del lenguaje de consulta para APIs y los casos de uso para los que es adecuado. Se requiere conocimiento básico de Javascript.
Presentando FlashList: Construyamos juntos una lista performante en React Native
Top Content
WorkshopFree
3 authors
En esta masterclass aprenderás por qué creamos FlashList en Shopify y cómo puedes usarlo en tu código hoy. Te mostraremos cómo tomar una lista que no es performante en FlatList y hacerla performante usando FlashList con mínimo esfuerzo. Usaremos herramientas como Flipper, nuestro propio código de benchmarking, y te enseñaremos cómo la API de FlashList puede cubrir casos de uso más complejos y aún así mantener un rendimiento de primera categoría.Sabrás:- Breve presentación sobre qué es FlashList, por qué lo construimos, etc.- Migrando de FlatList a FlashList- Enseñando cómo escribir una lista performante- Utilizando las herramientas proporcionadas por la biblioteca FlashList (principalmente el hook useBenchmark)- Usando los plugins de Flipper (gráfico de llamas, nuestro perfilador de listas, perfilador de UI & JS FPS, etc.)- Optimizando el rendimiento de FlashList utilizando props más avanzados como `getType`- 5-6 tareas de muestra donde descubriremos y solucionaremos problemas juntos- Preguntas y respuestas con el equipo de Shopify
A diferencia de las pruebas unitarias, las pruebas de extremo a extremo buscan interactuar con su aplicación tal como lo haría un usuario real. Y como todos sabemos, puede ser bastante desafiante. Especialmente cuando hablamos de aplicaciones móviles. Las pruebas dependen de muchas condiciones y se consideran lentas e inestables. Por otro lado, las pruebas de extremo a extremo pueden dar la mayor confianza de que su aplicación está funcionando. Y si se hace correctamente, puede convertirse en una herramienta increíble para aumentar la velocidad del desarrollador. Detox es un marco de pruebas de extremo a extremo en caja gris para aplicaciones móviles. Desarrollado por Wix para resolver el problema de la lentitud e inestabilidad y utilizado por React Native en sí como su herramienta de pruebas E2E. Únete a mí en esta masterclass para aprender cómo hacer que tus pruebas de extremo a extremo móviles con Detox sean excelentes. Prerrequisitos- iOS/Android: MacOS Catalina o más reciente- Solo Android: Linux- Instalar antes de la masterclass
- Introducción - Cleo & nuestra misión- Lo que queremos construir, cómo encaja en nuestro producto & propósito, revisar los diseños- Comenzando con la configuración del entorno & “hola mundo”- Introducción a la animación de React Native- Paso 1: Hacer girar la rueda al presionar un botón- Paso 2: Arrastrar la rueda para darle velocidad- Paso 3: Agregar fricción a la rueda para frenarla- Paso 4 (extra): Agregar hápticos para una sensación inmersiva
Construyendo una Aplicación de Shopify con React & Node
Top Content
WorkshopFree
2 authors
Los comerciantes de Shopify tienen un conjunto diverso de necesidades, y los desarrolladores tienen una oportunidad única para satisfacer esas necesidades construyendo aplicaciones. Construir una aplicación puede ser un trabajo duro, pero Shopify ha creado un conjunto de herramientas y recursos para ayudarte a construir una experiencia de aplicación sin problemas lo más rápido posible. Obtén experiencia práctica construyendo una aplicación integrada de Shopify utilizando el CLI de la aplicación Shopify, Polaris y Shopify App Bridge.Te mostraremos cómo crear una aplicación que acceda a la información de una tienda de desarrollo y pueda ejecutarse en tu entorno local.
Desplegar aplicaciones React Native manualmente en una máquina local puede ser complejo. Las diferencias entre Android e iOS requieren que los desarrolladores utilicen herramientas y procesos específicos para cada plataforma, incluidos los requisitos de hardware para iOS. Los despliegues manuales también dificultan la gestión de las credenciales de firma, las configuraciones de entorno, el seguimiento de las versiones y la colaboración en equipo. Appflow es la plataforma de DevOps móvil en la nube creada por Ionic. Utilizar un servicio como Appflow para construir aplicaciones React Native no solo proporciona acceso a potentes recursos informáticos, sino que también simplifica el proceso de despliegue al proporcionar un entorno centralizado para gestionar y distribuir tu aplicación en múltiples plataformas. Esto puede ahorrar tiempo y recursos, permitir la colaboración, así como mejorar la confiabilidad y escalabilidad general de una aplicación. En este masterclass, desplegarás una aplicación React Native para su entrega en dispositivos de prueba Android e iOS utilizando Appflow. También aprenderás los pasos para publicar en Google Play y Apple App Stores. No se requiere experiencia previa en el despliegue de aplicaciones nativas, y obtendrás una comprensión más profunda del proceso de despliegue móvil y las mejores prácticas para utilizar una plataforma de DevOps móvil en la nube para enviar rápidamente a gran escala.
Comments