Construyendo una Aplicación Móvil con Expo, EAS y React Native

Hola a todos. Mi nombre es Brent. Soy un Gerente de Ingeniería en Expo. Esta charla es una visión general de alto nivel sobre la construcción de aplicaciones React Native con Expo y EAS. No vamos a hablar sobre cómo manejar gestos y animaciones, navegación, o incluso hablar sobre una sola línea de código de React Native. Hay excelentes recursos para estos temas que enlazaré al final. Esta charla trata más sobre el proceso.

Si quieres construir una aplicación para Android y iOS y usar React en la web, React Native probablemente sea una buena elección. Gran parte del mismo conocimiento se aplicará a React Native. La API de componentes es la misma, puedes seguir usando tu biblioteca de gestión de estado favorita, las herramientas de desarrollo de React y un montón de otras cosas. Otra cosa que React Native tiene en común con React DOM es que hay un pequeño núcleo no dogmático. Gran parte del trabajo que necesitas hacer para construir una aplicación web existe fuera de React DOM y en mayor medida con React Native. React Native no pretende proporcionar una abstracción sobre todo lo que necesitas hacer para construir una aplicación.

Lo que esto significa es que se necesitará cierta familiaridad con el código nativo y las herramientas. Tendrás que aprender una cosa o dos sobre Xcode y Cocoapods y Android Studio y Gradle. Necesitarás poder distinguir entre un almacén de claves y un certificado de distribución. Dependiendo de lo que estés construyendo, podrías incluso necesitar sentirte cómodo escribiendo código nativo. Puedes manejar esto de varias maneras. Puedes aumentar el conjunto de habilidades nativas en tu equipo de desarrolladores de React. Puedes traer expertos nativos para gestionar el lado nativo, y puedes usar las herramientas de Xcode. Xcode toma el relevo donde React Native lo deja y te ayuda a mantenerte productivo en React. Xcode es un conjunto de proyectos de código abierto y servicios alojados para ayudarte a manejar la complejidad accidental del desarrollo de aplicaciones multiplataforma.

En el resto de esta charla, veremos lo que Xcode puede hacer, cómo funcionan sus abstracciones, cómo estas abstracciones a veces pueden quedarse cortas, y lo que estamos haciendo para resolver estas limitaciones. Así que, he dicho que Xcode toma el relevo donde React Native lo deja. Déjame explicar. Xcode hace posible escribir tu aplicación solo en TypeScript o JavaScript y configurarla en JSON. Observa los directorios de Android y iOS en el terminal a la izquierda. Para ejecutar este proyecto, abriríamos los directorios del proyecto de Android y iOS en Android Studio y Xcode, luego compilaríamos y ejecutaríamos los proyectos. Pero no tenemos ningún proyecto nativo en el terminal a la derecha. Se parece mucho más a un proyecto de React DOM.

por Expo. Lo abres en Android o iOS, descargas una aplicación de la App Store llamada Xcode, y la instalas. Esto es como un navegador web para desarrollar aplicaciones React Native. Incluye el tiempo de ejecución con un conjunto extenso de APIs construidas por el equipo de Expo para añadir capacidades como notificaciones y hápticos. Y el propio React Native.

Pensemos un minuto para aclarar a qué me refiero con un tiempo de ejecución. En un navegador web, el tiempo de ejecución incluye la biblioteca estándar de ECMAScript junto con las APIs web estándar. Como desarrollador ejecutando un sitio web, no puedes cambiarlo sin enviar un pull request al motor del navegador. El tiempo de ejecución está controlado por los proveedores del navegador. Incluye todas las APIs que puedes usar desde JavaScript. Podrías reconocer estas como las funciones que se convierten en código nativo entre corchetes cuando las registras constantemente. Exponen acceso al DOM, la red y otras cosas como la ubicación del dispositivo. En Node.js, tienes la biblioteca estándar de Node en lugar de las APIs web y puedes extender el tiempo de ejecución construyendo extensiones nativas en lenguajes como C++ o RAS.

En un navegador web, el tiempo de ejecución es proporcionado por los proveedores del navegador. En los proyectos gestionados por XO, el tiempo de ejecución es proporcionado por XO. Puedes cambiar enviando un pull request al repositorio de XO en GitHub. En otras aplicaciones de React Native, para cualquier cosa más allá de las APIs principales, necesitas crear o instalar módulos nativos escritos en lenguajes como Swift o Kotlin y recompilar la aplicación para usarlos con JavaScript. Para instalar una biblioteca en un proyecto gestionado por XO, ejecuta XO install. XO install toma una versión de la que coincide con la versión del tiempo de ejecución utilizada por el proyecto. Llamamos a la versión del tiempo de ejecución la versión del SDK de XO. Podemos usar la biblioteca desde JavaScript sin recompilar ningún código nativo. Todo esto puede previsualizar tu trabajo en progreso en XO Go. Para hacer esto, añade a tu colega a tu equipo en el sitio web de XO y publica tu aplicación con XO publish. Luego, comparte la URL. Puedes configurar esto para que se ejecute automáticamente en pull requests para obtener un flujo de trabajo de vista previa similar a lo que puedes hacer en la web con servicios como Netlify y Vercel. También puedes compartir código en Snack. Es un tipo de entorno sandbox que te permite editar y ejecutar código directamente en un navegador web. Cuando estés listo para enviar tu aplicación, ejecuta XpoBuild Android o iOS. Llamamos a esta herramienta de construcción Turtle porque toma tu aplicación y la empaqueta en una aplicación preconstruida. El resultado es una aplicación independiente, un binario que puedes enviar a una tienda.

El resultado es una aplicación independiente, un binario que puedes enviar a una tienda. Se llama una aplicación independiente porque se sostiene por sí misma. Ya no depende de Xpogo para ejecutarse. Así es como funciona Turtle. El comando de construcción sube tu paquete de JavaScript de la aplicación, manifiesto y recursos, como imágenes y fuentes. Luego, Turtle inicia un nuevo trabajador y descarga los archivos que acabas de subir. También descarga nuestra aplicación shell preconstruida. Luego configura la aplicación shell basándose en propiedades del manifiesto como el nombre y el icono. Copia el JavaScript descargado y los recursos en los recursos de la aplicación shell.

Y por último, firma la aplicación con tus credenciales de firma de la aplicación. Cuando todo este proceso está completo, podemos proceder a subir esta aplicación independiente a las tiendas. Para enviar tu aplicación, ejecuta EAS submit PHP, Android o iOS. Bueno, más o menos. En realidad, tendrás que enviar tu aplicación a través de la consola de Google Play la primera vez que lo hagas en Android porque aún no es posible a través de ninguna API pública. Si accidentalmente lanzas tu aplicación con un error, puedes solucionarlo localmente y luego ejecutar Expo publish para actualizar JavaScript por aire. Puedes actualizar de manera segura aplicaciones gestionadas por aire porque el código que posees es solo JavaScript. Así que es similar a actualizar un sitio web. Para actualizar la aplicación, simplemente descargamos el nuevo JavaScript y lo intercambiamos por el paquete de JavaScript que se está utilizando actualmente en el shell.

Usualmente hacemos esto cuando la aplicación se reinicia, pero puedes configurarlo de manera diferente si lo deseas. A grandes rasgos, así es como enviamos una aplicación gestionada con Expo y React Native hoy en día. Cada semana hay millones de personas usando aplicaciones construidas por decenas de miles de desarrolladores de esta manera. Miles de aplicaciones se construyen con Turtle para su despliegue en las tiendas de aplicaciones cada día. Ahora que hemos visto el camino dorado, podemos echar un vistazo a dónde estas abstracciones comienzan a quedarse cortas. Recibimos muchas solicitudes de características de desarrolladores que construyen aplicaciones gestionadas por Expo, pero podemos destilar la mayoría de ellas en una de tres cosas. Primero, quiero usar una biblioteca que no está integrada en el SDK de Expo. Por ejemplo, React Native web RPC. Segundo, quiero eliminar bibliotecas que no estoy usando. Por ejemplo, para reducir el tamaño de la aplicación. Y tercero, quiero incluir código nativo que voy a escribir yo mismo y que no está en ninguna biblioteca existente. Estas tres solicitudes apuntan a un problema.

Las personas necesitan poder personalizar el tiempo de ejecución en las aplicaciones de React Native Android y iOS. Actualmente, si llegas al punto en el que necesitas modificar el tiempo de ejecución, incluso si solo es para eliminar algún código o agregar un solo módulo nativo, necesitas tomar el control de tus proyectos nativos. Puedes hacer esto con expoeject.

Expoeject es un comando que instancia y configura los proyectos nativos de iOS y Android en tu máquina. Ahora tienes un proyecto nativo estándar, y no solo los archivos JavaScript. Así que el nombre suena muy similar, pero es un poco diferente de createReactAppsEject porque después de ejecutarlo, todavía estás usando la mayoría de las herramientas de expo. Dicho esto, no todo está soportado aún.

Tomar el control de tus proyectos nativos es una solución muy razonable para muchos desarrolladores, y algo que cada herramienta de expo debería soportar. Otros desarrolladores prefieren que Expo continúe gestionando sus proyectos nativos. Quieren agregar y eliminar bibliotecas nativas, y dejar que Expo se encargue de cómo funciona realmente. Así que, hay dos partes en nuestra solución a este problema. Pero verás pronto que la primera parte es en realidad un requisito previo para la segunda. Primero, necesitamos hacer que todas las herramientas de Expo funcionen en cualquier proyecto de React Native, y luego podemos hacer que el tiempo de ejecución nativo sea personalizable en proyectos gestionados.

Si podemos hacer que el tiempo de ejecución sea personalizable, entonces los desarrolladores pueden agregar o eliminar cualquier módulo nativo en sus proyectos gestionados. La mayoría de las herramientas de Expo ya funcionan fuera de los proyectos gestionados, por ejemplo, los paquetes del SDK de Expo como Notifications y Haptics. Lo que nos falta es el servicio Turtle Build y Expo Go. Estas herramientas fueron construidas específicamente alrededor de un tiempo de ejecución fijo, por lo que necesitaremos construir nuevas versiones de estas herramientas desde cero que puedan proporcionar una experiencia equivalente.

Turtle no puede soportar cualquier aplicación arbitraria de React Native porque está diseñada específicamente para ensamblar aplicaciones shell. Esto es muy diferente de compilar una aplicación, por lo que construimos un nuevo servicio desde cero llamado EAS Build. EAS significa Expo Application Services. Ejecutar una compilación de Android o iOS en algún servidor en la nube no es exactamente una idea novedosa, pero necesitamos construirlo para proporcionar una experiencia fluida y personalizada, una que esté profundamente integrada con los servicios de Expo y React Native.

Así es como funciona EAS Build. Ejecutas EAS Build-P android o iOS, creas un clon superficial del repositorio Git de tu proyecto, lo comprimes y lo subes. EAS Build configura una nueva VM, luego descarga el archivo de tu proyecto. Instala dependencias de JavaScript y dependencias nativas, luego inicia una compilación nativa. Cuando la compilación se completa, firma el binario resultante con las credenciales de tu propia aplicación. Como la mayoría de las cosas en esta charla, hay un poco más que eso, pero esos son los pasos a alto nivel. Usando EAS Build ahora podemos construir y firmar cualquier proyecto de React Native.

La otra pieza que falta es un equivalente a Expo Go. Así que hemos estado construyendo algo que llamamos Expo Development Client.

Es la biblioteca de React Native que te da la misma experiencia que Expo Go, pero con tu propio runtime personalizado. Es mínimamente opinado para soportar el conjunto más amplio de casos de uso. Cuando creas una compilación de depuración de tu aplicación, obtienes la experiencia del Development Client. Cuando creas una compilación de lanzamiento, todo el código del Development Client se elimina. Puedes construir el Development Client una vez y centrarte en el lado de JavaScript de tu aplicación, y luego volver al Development Client cuando quieras escribir o instalar algún nuevo código nativo.

Así que, con soluciones para Turtle y Expo Go, podemos pasar a la Parte Dos, personalizando el runtime en Proyectos Expo Gestionados. En Proyectos Expo Gestionados, hay dos lugares donde necesitamos poder modificar el runtime. En nuestro entorno de desarrollo local, y en nuestras aplicaciones independientes. Comencemos con las aplicaciones independientes. Necesitamos un servicio de compilación en la nube capaz de construir proyectos con código nativo arbitrario. Esto suena como un trabajo para EAS build. Podemos reutilizar el comando eject para generar y configurar los proyectos nativos de iOS y Android basados en la aplicación JavaScript. Llamaremos a este nuevo comando prebuild. En EAS build, solo necesitamos ejecutar prebuild, y luego construir el proyecto resultante como lo haríamos para cualquier aplicación de React Native. No hay aplicaciones shell aquí. Con esto en su lugar, los desarrolladores pueden eliminar bibliotecas que no están usando, porque el comando prebuild solo enlaza y configura bibliotecas que están instaladas en el proyecto. En casos simples, agregar bibliotecas funcionará bien también, porque React Native las enlaza automáticamente a través de Gradle y Cocoapods. Pero instalar bibliotecas de módulos nativos a menudo implica alguna configuración adicional de proyectos de datos, prebuild solo sabe cómo hacer esto para paquetes XOSDK. Podemos resolver esto dando a los desarrolladores ganchos en el proceso de prebuild, y documentando públicamente las herramientas que usamos para configurar paquetes XOSDK. Llamamos a estas herramientas plugins de configuración. Los plugins de configuración son funciones que se ejecutan durante el proceso de prebuild. Tienen acceso a utilidades que hacen fácil realizar las tareas de configuración más comunes. Y si esas no manejan tu caso de uso, entonces puedes acceder directamente al proyecto en el sistema de archivos como una salida de emergencia. Los desarrolladores pueden pasar opciones a los plugins de configuración como claves API y mensajes de permisos.

Ahora que los desarrolladores pueden personalizar sus runtimes para agregar y eliminar bibliotecas, si los ves cometer algunos errores accidentalmente con las actualizaciones over-the-air, puedes terminar en una situación donde el código JavaScript para una actualización es incompatible con el runtime en el binario. Necesitamos proporcionar herramientas que hagan fácil hacer lo correcto en estos escenarios. No entraremos en eso aquí, pero vale la pena señalar que este es un nuevo problema que surge con runtimes personalizados, y estamos trabajando en soluciones en un nuevo servicio llamado EAS Update. Para personalizar el runtime en nuestro entorno de desarrollo podemos usar el cliente de desarrollo de Expo. Teóricamente y esto no está realmente implementado aún en el momento en que estoy diciendo esto, hay dos pasos para crear una compilación de cliente de desarrollo personalizada para un proyecto gestionado.

Segundo, ejecuta una compilación de depuración de nuestro proyecto en EAS build. Podemos depender de los plugins de configuración incluidos en los paquetes del cliente de desarrollo para configurar el cliente automáticamente durante la fase de pre-construcción.

Así que eso es todo. Ahora, necesita ser súper fácil compartir tus compilaciones del cliente de desarrollo de Expo, así que construimos algo que llamamos distribución interna en EAS build. Puedes usarlo para compartir compilaciones del cliente de desarrollo con tus amigos y colegas. Para hacer esto, primero, si estás distribuyendo a iOS, agrega el dispositivo a una lista de permitidos, para que se incluya en el perfil de aprovisionamiento. Esto no es necesario para Android. Ahora, puedes crear una compilación. Cuando la compilación se complete, envía la URL de la compilación a tu colega. Ellos pueden instalar directamente desde esa página.

En el futuro, una vez que todo esto esté listo, construir aplicaciones gestionadas con Expo y React Native se verá mucho más así. Podrás instalar una biblioteca de módulos nativos, luego ejecutar una nueva compilación del cliente de desarrollo localmente o en EAS build para agregarlo a tu runtime del cliente de desarrollo. Luego puedes continuar construyendo tu aplicación en TypeScript o JavaScript.

EAS build y los plugins de configuración están disponibles ahora. Si expo-sdk41 ha sido lanzado para cuando esta charla se emita, puedes probar EAS build con tu proyecto SDK41 y debería reducir tu tamaño de aplicación significativamente al solo incluir las bibliotecas nativas que estás usando. Si lo haces, ten cuidado cuando estés haciendo actualizaciones over-the-air.

Vale la pena señalar que EAS build es un servicio de pago y planeamos tener un nivel gratuito generoso, suficiente para apoyar a desarrolladores aficionados, estudiantes y pequeñas organizaciones que recién están comenzando. Por ahora, EAS build todavía está en vista previa y está limitado detrás de un plan de pago. Estaremos lanzando la disponibilidad general en el verano. El cliente de desarrollo de Expo y EAS update están ambos en datos cerrados. Si estás interesado en probarlos, sigue el enlace en la pantalla para completar una encuesta. Si estás viendo esto un tiempo después de la fecha de grabación, mantendremos esas páginas actualizadas para que puedas encontrar información relevante allí también.

Entonces, ¿por qué estamos haciendo esto? Bueno, Read Expo cree que un porcentaje significativo de aplicaciones de Android y iOS se pueden construir solo con TypeScript usando un cliente de desarrollo con un runtime personalizado y apoyándose en el SDK de Expo y el ecosistema de código abierto de React Native. Hay muchas bibliotecas geniales por ahí, y los proveedores de servicios están apoyando cada vez más envoltorios de React Native para sus paquetes nativos. A medida que React Native continúa madurando, esto solo mejorará más y más. Incluso si prefieres gestionar tus proyectos nativos, estas herramientas pueden permitir mejores cargas de trabajo para tu equipo. Pueden ayudarte a estructurar tu proceso para que el trabajo en el runtime y el código de la aplicación estén separados, similar a cómo construir componentes con Storybook te permite dividir el desarrollo de tu sistema de componentes de la construcción de características con esos componentes. Con eso, puedes obtener todos los beneficios que vienen con tener un runtime estable y un mecanismo para cargar aplicaciones en ese runtime, como vistas previas fáciles de pull requests en GitHub. Amamos la web, y queremos que React Native sea más como ella, mientras aún retenemos lo que hace a React Native genial. Y creemos que el trabajo que hemos estado haciendo es un gran paso en esa dirección.

Puedes seguirnos en Twitter, en expo y no brent, y frecuentemente publicamos actualizaciones más extensas en nuestro blog. Aprende cómo comenzar a escribir código en React Native, revisa los enlaces de Learn en el lado derecho.

Muchas gracias por escuchar. Adiós.

Muchas gracias por esa maravillosa charla. Espero que la hayas disfrutado tanto como yo. Brent es increíble.

Ahora, antes de continuar, respondamos la pregunta que Brent les hizo a todos ustedes. Espero que la hayan respondido en el Slido. Entonces, Brent preguntó, ¿alguna vez has lanzado una app con React Native? Y podemos ver que un buen 30% de ustedes, amigos, han lanzado una app con React Native. Eso es bastante impresionante. Y con suerte, con algunas de las cosas de las que Brent habló, incluso pueden lanzar mejores apps con React Native próximamente.

Voy a invitar a Brent a unirse a nosotros en el escenario. Brent, ¿cómo estás? Estoy bien. ¿Y tú? Estoy bien. Gracias. Así que, tenemos bastantes preguntas llegando. Aquellos de ustedes, tal vez si todavía tienen una pregunta, asegúrense de dejarla en el chat de Discord.

Así que, la primera pregunta, voy a ir directo a ella. De BKG, ¿hay algún inconveniente en usar Expo, cosas que no puede manejar que te harían necesitar salir de él? Sí, creo que intenté cubrir eso un poco en la charla en términos de, ya sabes, mencionar los compromisos que vienen con tener un runtime fijo. Y así, hay solo tantas cosas que realmente podemos incluir dentro del preset, así que runtime de SDK fijo. Y puedes echar un vistazo a la página de solicitudes de características que Expo tiene para ver algunas de las cosas con las que la gente se encuentra. Y, ya sabes, hay algunas bibliotecas en la comunidad de React Native que no incluimos que a mucha gente le gustaría usar frecuentemente, y así una gran parte de lo que estamos trabajando es abordar esas limitaciones para que puedas modificar el runtime y no tengas que enfrentar esos tipos de compromisos en términos de como usar lo que quieres usar mientras también obtienes la experiencia de tener mucha de la complejidad de gestionar tu app manejada para ti.

Genial. Alguien está haciendo una pregunta de comparación, así que están preguntando cómo se compara Expo con App Center Code Push. ¿Alguien tiene alguna experiencia? ¿Hay alguna diferencia? ¿Algo similar? Sí, así que creo que lo más comparable allí es Expo Updates, que es el servicio de actualización over-the-air que creo que es comparable a Code Push. Son bastante similares. Creo que Code Push tiene algunas características interesantes que Expo aún no tiene, y lo mismo ocurre al revés. Creo que hay un par de cosas que surgen solo por el hecho de que Expo Updates está integrado en proyectos de Expo que lo hacen tal vez un poco más conveniente en algunas circunstancias, pero luego en otras circunstancias, si necesitas configurarlos desde cero, creo que es un poco igual. Pero cuando creas un proyecto con Expo CLI, obtendrás Expo Updates configurado automáticamente para ti, así que no tienes que hacer nada en absoluto. Solo tienes que crear una cuenta con Expo y podrás publicar actualizaciones a tu app con Expo Publish, así que todo está configurado.

Así que esa es una gran ventaja que obtienes desde el principio. Y luego hay otro aspecto en el que si estás usando Expo Updates con este Managed Workflow que mencioné un poco en la charla, donde es como si gestionáramos el runtime por ti, entonces obtienes actualizaciones over-the-air realmente seguras porque no tienes que preocuparte de que el código nativo cambie bajo tus pies en diferentes circunstancias y así, si publicas un proyecto para SDK 40 y luego haces algunos cambios y lo publicas de nuevo, eso funcionará. Mientras que tienes que estar un poco más preocupado cuando el runtime puede cambiar y como tener cuidado para asegurar que el JavaScript que estás publicando sea compatible.

Gracias. Espero que eso responda a tu pregunta, Sarush, ¿eh? Tenemos otra pregunta y ahora no sé, admitiré que no sé qué significan estos acrónimos, así que si tú sabes qué significan estos acrónimos, ¿puedes decirnos? ¿Expo alguna vez soportará BLE directamente o deberíamos confiar solo en EAS? Es difícil de decir, realmente no estamos enfocados en, quiero decir, esta pregunta es específicamente sobre BLE, como así que eso es Bluetooth de baja energía, pero hay muchas otras posibles APIs que la gente diría, oh bueno, ¿alguna vez vas a soportar esto o esto o esto? Y podríamos, como que tuvimos una elección como, está bien, ¿vamos a salir y construir todos estos diferentes envoltorios de API y soportar todos estos y definitivamente en el futuro y ceñirnos a este concepto de como un runtime gestionado que solo entonces crece y crece y crece. Y así que esa fue una ruta posible que podríamos haber tomado y la otra fue permitir a las personas personalizar el runtime. Así que hemos optado hasta ahora por, como en el último año, como centrémonos en hacer el runtime personalizable. Y creo que una vez que logremos eso en un punto realmente bueno donde las personas puedan usar bibliotecas BLE existentes o lo que sea que quieran usar en esas bibliotecas de compras, bibliotecas de mapas, etc. Que como no están incluidas, entonces una vez que eso esté bien, podemos tal vez volver y decir, OK, bueno, ¿en cuáles de estas áreas crees que realmente podemos tener un impacto positivo? No hay necesidad de reimplementar algo que otra biblioteca ya ha hecho un excelente trabajo. Y así que si hay una gran biblioteca BLE por ahí y tiene sentido para nosotros contribuir a eso, entonces lo haríamos. Si es algo donde pensamos, OK, bueno, tal vez necesitamos reescribir esto para hacerlo como creemos que debería ser, entonces lo hacemos. Y así que está un poco sobre la mesa en términos de si integramos eso o no. Pero lo más probable, quiero decir, el futuro de hacia dónde va el desarrollo con proyectos de Expo es definitivamente con con EAS y cosas como el cliente de desarrollo.

Sí, bueno, entonces tenemos otra pregunta justo de Rado. Para agregar una biblioteca, creo que es una pregunta de aclaración. Para agregar una biblioteca de código nativo, necesitas ejectar. Correcto. Sí, así que en este momento, ese es el caso. Y eso fue un poco de lo que discutí en la primera mitad de la charla, fue como, este es el runtime fijo. Y luego, si quieres cambiar esa forma en que lo haces ahora, como ejectarías y eso generaría estos proyectos nativos. Y no es exactamente lo mismo que ejectar en Create React app donde como ejectas y ahora no hace nada por ti y te encargas de todo. Es como a mitad de camino entre eso y como no ejectar. Y así básicamente, genera los proyectos nativos que de otra manera habrías gestionado por ti. Y luego puedes agregar lo que quieras a eso. Y eso es un poco donde está ahora. Y así, hacia donde vamos es la segunda mitad de la charla fue lo que podrías hacer es agregar la biblioteca, y luego podrías obtener, está construido para hacer una nueva construcción del cliente para ti que incluya esa biblioteca. Y luego podrías continuar con el desarrollo como lo estabas haciendo antes. Y eso te permitiría tener esa misma experiencia de flujo de trabajo gestionado, pero aún así personalizar el runtime y eliminar bibliotecas.

Así que otra cosa es justo hacia el final de la charla, él dijo que había algunas cosas que no estaban, que podrían no haber estado disponibles aún que podrían estar disponibles ahora, solo por curiosidad, ¿están disponibles ahora? Así que no hemos lanzado SDK 41 aún, pero lo haré poco después de esto. Las cosas alrededor del cliente de desarrollo y demás, no, eso es más como una línea de tiempo de junio, julio para eso. Y sí, así que eso es un poco más adelante. De la semana pasada a esta semana, no va a cambiar mucho allí. No te preocupes. Tal vez cuando alguien esté viendo la grabación, ya habría sido lanzado por ellos.

Así que una especie de pregunta, has estado en el espacio de React Native por un tiempo. Solo por curiosidad, ¿cuáles son tus aplicaciones favoritas de React Native? O tal vez una que hayas visto que realmente te haya gustado? Bueno, tengo que dar un saludo a Coinbase porque están haciendo su IPO hoy. Coinbase Pro y, um, y algunas otras cosas también en React Native. Y creo que hicieron un buen trabajo con eso. Um, realmente me gustó esta aplicación llamada Readwise. Puedes ir a readwise.io. Es una gran herramienta para, um, tomar todos tus tipos de destacados de un montón de diferentes ubicaciones y, uh, realmente revisarlos, no solo como ponerlos en este archivo de cosas que estás como, Hey, eso es genial. Quiero recordar esto. Así que solo voy a destacarlo y luego nunca pensar en ello de nuevo.

Esta cosa se conectará a los destacados de Kindle y todas tus otras aplicaciones de Twitter, lo que sea, y, y usará algo de repetición espaciada y revisión. Um, también me gusta la aplicación llamada Third Wave. Uh, solo es utilizable en Canadá en este momento, pero es una muy buena aplicación de café. Uh, y al igual que algunas otras grandes como la aplicación de PlayStation la nueva aplicación de PlayStation es realmente genial. Um, y, uh, acabo de descargar eso. No reaccioné a native al otro extremo. Y, y, y de, de esas son algunas de tus aplicaciones favoritas de React Native, ¿qué hay de algunas de tus bibliotecas favoritas?

Um, definitivamente tienes que ir con gesture handler y reanimated como dos de mis favoritas. Um, Expo GL es otra realmente buena. Um, te permite usar WebGL esencialmente, o algo cercano a eso dentro de, um, aplicaciones de React Native. Y así puedes usar three J S y cosas así con él. Y así, uh, oh, en realidad olvidé mencionar otra aplicación que realmente me gusta es shop de Shopify y usan expo GL, um, en, en su aplicación, uh, y, uh, similar. Sí. Usos realmente geniales de eso. Um, y por supuesto, la biblioteca de react navigation en la que estoy muy involucrado, uh, en ese expo, uh, es, uh, supongo que el, el tipo de, uh, en el proyecto durante, durante, durante varios años, junto con personas como Satya, uh, que realmente ha estado, uh, poniendo todo el trabajo en eso recientemente y haciendo un gran proyecto con un P cinco y P seis, um, safe area. Context, um, es otro realmente genial del tipo que hizo third wave a Janik. Uh, ni siquiera voy a intentar decir su, su apellido francés. Lo siento, Janik, si estás viendo esto, uh, y esa es una forma realmente fantástica de hacerlo. Como creo que si recién te unes al ecosistema de React Native ahora, um, es fácil dar por sentado lo fácil que es lidiar con áreas seguras en dispositivos. Ya sea como la barra de estado o el indicador de inicio o no. Claro. Cosas así. Como simplemente instalas un reactivo safe area context y tienes realmente agradables, uh, como, um, API's idiomáticas de react para lidiar con, con estas cosas y es fantástico. Así que, um, sí, diría que esos son, esos son mis favoritos.

Genial. Tenemos otra pregunta de Ret Rado. Es otra pregunta general. ¿Dónde sigue faltando react native en comparación con las aplicaciones nativas de Android e iOS? Sí. Um, esa es una buena pregunta. Creo que hay algunas áreas que destacan. Um, una que realmente me gustaría ver es la capacidad de crear como editores de texto enriquecido directamente en primitivas de React Native.

Um, creo que la gente tiende a conectar un editor de texto enriquecido, um, o usar una vista web. Um, creo que sería realmente genial si tuviéramos, tuviéramos simplemente más primitivas enriquecidas para, um, para hacer este tipo de cosas. Podemos construir eso y tal vez, tal vez con algunas de las mejoras que vienen con fabric, eso podría ser posible. Um, creo que las listas son otra. Um, así que, uh, ya sabes, cosas como flatless y section lists, creo que hacen un buen trabajo, pero, uh, no tienen exactamente las mismas características de rendimiento que, uh, que las listas integradas. Y así en, en cualquiera de las plataformas. Y así sería, uh, realmente genial cuando fabric nuevamente, sea lanzado para tal vez ver si eso desbloqueará, um, permitiéndonos usar estos mismos tipos de APIs de reciclaje de vistas, um, y obtener las mismas características de rendimiento.

Genial. Y la última pregunta, y sé que esta pregunta, de hecho, esta pregunta podría ser toda una charla. Así que solo te voy a pedir que la condenses en como los mismos minutos en estos 30 segundos en esta última pregunta. Uh, ¿en qué dirección ves que Expo va en los próximos años? ¿Qué nuevas características están en la lista de deseos a largo plazo para más allá de EAS? Bueno, sí, es potencialmente una cosa muy grande. Podría abarcar un amplio conjunto de servicios y, um, en última instancia, como dar a las personas esta capacidad de incluir cualquier módulo nativo que deseen es algo que a corto y mediano plazo, como lograr eso de una manera que simplemente funcione increíblemente para todos va a ser algo que será un desafío y, uh, realmente estamos ansiosos por resolver para las personas y creemos que tendrá un gran impacto. Uh, pero una vez que logremos eso, um, hay muchas integraciones que podemos hacer con bibliotecas y el ecosistema y diferentes servicios, uh, para asegurar que puedas simplemente conectarlos y funcionen de inmediato y ya sea que eso sea, uh, herramientas como log rocket o, o, ya sabes, cualquier tipo de herramienta de pagos que estés usando o, uh, herramienta de mapas, ese tipo de cosas, como debería ser posible simplemente conectar esas a tu aplicación y, uh, y, y comenzar a funcionar. Y así, eso es, eso es un poco, uh, uh, hacia dónde vamos y realmente el alcance de los servicios que podemos ofrecer a través de EAS son, son potencialmente, um, como bastante ilimitados en términos de, um, las, las, uh, áreas de oportunidad para mejorar la experiencia de desarrollo móvil, um, y la experiencia de desarrollo multiplataforma.

Eso es genial. Muchas gracias por pasar el rato con nosotros, Sbrenn. Realmente, realmente lo aprecio. ¿Y dónde puede la gente encontrarte si quieren charlar contigo más tarde? Uh, Twitter es probablemente un buen lugar, uh, así que not Brent en Twitter. Y, uh, supongo que GitHub, si quieres seguir la actividad en GitHub, Brent Batney en GitHub. Genial. Me encanta el nombre de usuario en not Brent. Muchas gracias por pasar el rato con nosotros. Adiós. Gracias, adiós. Así que, aquellos de ustedes que todavía están por aquí, asegúrense de ir al slider y dar a la charla de Brent un gran cinco estrellas de cinco. También pueden unirse a Brent en su sala de oradores en este chat espacial. El enlace para unirse está en la línea de tiempo. Así que, definitivamente revisen eso si tienen más preguntas para él. Solo quiero recordar a la gente porque me encantan los premios. Espero que a ustedes les encanten los premios. Tenemos un sorteo en Twitter. Y la forma de participar en este sorteo es tomando una foto de tu configuración y tuiteándola usando el hashtag React Summit. Espero ganar. Tal vez debería obtener algo gratis como maestro de ceremonias. Pero espero ganar también. Solo lo quiero. Nos vemos justo después de un breve descanso.