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

Rate this content
Bookmark

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.

29 min
20 Oct, 2023

Comments

Sign in or register to post your comment.

AI Generated Video Summary

Esta charla discute Rack Native en Microsoft y los esfuerzos para mejorar la integración de código, la experiencia del desarrollador y los objetivos de liderazgo. El objetivo es extender Rack Native a cualquier aplicación, utilizar código web e incrementar la velocidad del desarrollador. Se está explorando la implementación de APIs web para React Native, así como la colaboración con Meta. El objetivo final es convertir el código web en código universal y permitir a los desarrolladores escribir el código una vez y que funcione en todas las plataformas.

1. Introducción a Rack Native en Microsoft

Short description:

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Too much JavaScript is getting you down? New frameworks promising no JavaScript look interesting, but you have an existing React application to maintain. What if Qwik React is your answer for faster applications startup and better user experience? Qwik React allows you to easily turn your React application into a collection of islands, which can be SSRed and delayed hydrated, and in some instances, hydration skipped altogether. And all of this in an incremental way without a rewrite.
GraphQL Galaxy 2021GraphQL Galaxy 2021
32 min
From GraphQL Zero to GraphQL Hero with RedwoodJS
We all love GraphQL, but it can be daunting to get a server up and running and keep your code organized, maintainable, and testable over the long term. No more! Come watch as I go from an empty directory to a fully fledged GraphQL API in minutes flat. Plus, see how easy it is to use and create directives to clean up your code even more. You're gonna love GraphQL even more once you make things Redwood Easy!
JSNation 2023JSNation 2023
28 min
SolidJS: Why All the Suspense?
Solid caught the eye of the frontend community by re-popularizing reactive programming with its compelling use of Signals to render without re-renders. We've seen them adopted in the past year in everything from Preact to Angular. Signals offer a powerful set of primitives that ensure that your UI is in sync with your state independent of components. A universal language for the frontend user interface.
But what about Async? How do we manage to orchestrate data loading and mutation, server rendering, and streaming? Ryan Carniato, creator of SolidJS, takes a look at a different primitive. One that is often misunderstood but is as powerful in its use. Join him as he shows what all the Suspense is about.
TechLead Conference 2023TechLead Conference 2023
35 min
A Framework for Managing Technical Debt
Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt.In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.

React Summit 2023React Summit 2023
24 min
Debugging JS
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.

Workshops on related topic

React Advanced Conference 2022React Advanced Conference 2022
81 min
Introducing FlashList: Let's build a performant React Native list all together
WorkshopFree
In this workshop you’ll learn why we created FlashList at Shopify and how you can use it in your code today. We will show you how to take a list that is not performant in FlatList and make it performant using FlashList with minimum effort. We will use tools like Flipper, our own benchmarking code, and teach you how the FlashList API can cover more complex use cases and still keep a top-notch performance.You will know:- Quick presentation about what FlashList, why we built, etc.- Migrating from FlatList to FlashList- Teaching how to write a performant list- Utilizing the tools provided by FlashList library (mainly the useBenchmark hook)- Using the Flipper plugins (flame graph, our lists profiler, UI & JS FPS profiler, etc.)- Optimizing performance of FlashList by using more advanced props like `getType`- 5-6 sample tasks where we’ll uncover and fix issues together- Q&A with Shopify team
React Summit 2022React Summit 2022
117 min
Detox 101: How to write stable end-to-end tests for your React Native application
WorkshopFree
Compared to unit testing, end-to-end testing aims to interact with your application just like a real user. And as we all know it can be pretty challenging. Especially when we talk about Mobile applications.
Tests rely on many conditions and are considered to be slow and flaky. On the other hand - end-to-end tests can give the greatest confidence that your app is working. And if done right - can become an amazing tool for boosting developer velocity.
Detox is a gray-box end-to-end testing framework for mobile apps. Developed by Wix to solve the problem of slowness and flakiness and used by React Native itself as its E2E testing tool.
Join me on this workshop to learn how to make your mobile end-to-end tests with Detox rock.
Prerequisites- iOS/Android: MacOS Catalina or newer- Android only: Linux- Install before the workshop
React Summit Remote Edition 2021React Summit Remote Edition 2021
87 min
Building a Shopify App with React & Node
WorkshopFree
Shopify merchants have a diverse set of needs, and developers have a unique opportunity to meet those needs building apps. Building an app can be tough work but Shopify has created a set of tools and resources to help you build out a seamless app experience as quickly as possible. Get hands on experience building an embedded Shopify app using the Shopify App CLI, Polaris and Shopify App Bridge.We’ll show you how to create an app that accesses information from a development store and can run in your local environment.
React Summit Remote Edition 2021React Summit Remote Edition 2021
60 min
How to Build an Interactive “Wheel of Fortune” Animation with React Native
Workshop
- Intro - Cleo & our mission- What we want to build, how it fits into our product & purpose, run through designs- Getting started with environment set up & “hello world”- Intro to React Native Animation- Step 1: Spinning the wheel on a button press- Step 2: Dragging the wheel to give it velocity- Step 3: Adding friction to the wheel to slow it down- Step 4 (stretch): Adding haptics for an immersive feel
JSNation 2022JSNation 2022
41 min
Build a chat room with Appwrite and React
WorkshopFree
API's/Backends are difficult and we need websockets. You will be using VS Code as your editor, Parcel.js, Chakra-ui, React, React Icons, and Appwrite. By the end of this workshop, you will have the knowledge to build a real-time app using Appwrite and zero API development. Follow along and you'll have an awesome chat app to show off!
GraphQL Galaxy 2021GraphQL Galaxy 2021
164 min
Hard GraphQL Problems at Shopify
WorkshopFree
At Shopify scale, we solve some pretty hard problems. In this workshop, five different speakers will outline some of the challenges we’ve faced, and how we’ve overcome them.

Table of contents:
1 - The infamous "N+1" problem: Jonathan Baker - Let's talk about what it is, why it is a problem, and how Shopify handles it at scale across several GraphQL APIs.
2 - Contextualizing GraphQL APIs: Alex Ackerman - How and why we decided to use directives. I’ll share what directives are, which directives are available out of the box, and how to create custom directives.
3 - Faster GraphQL queries for mobile clients: Theo Ben Hassen - As your mobile app grows, so will your GraphQL queries. In this talk, I will go over diverse strategies to make your queries faster and more effective.
4 - Building tomorrow’s product today: Greg MacWilliam - How Shopify adopts future features in today’s code.
5 - Managing large APIs effectively: Rebecca Friedman - We have thousands of developers at Shopify. Let’s take a look at how we’re ensuring the quality and consistency of our GraphQL APIs with so many contributors.