La mentira del 1.0

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

Cuando se habla de trabajar con React Native, la versión y el ciclo de lanzamiento suelen surgir como uno de los puntos problemáticos. Pero, ¿por qué es eso? ¿Qué tan complicado es crear una nueva versión de React Native? Seguramente se ve similar al proceso de lanzamiento que estás utilizando... o tal vez no. En esta charla te guiaré a través de los muchos pasos y complejidades involucrados en la publicación de una nueva versión de React Native, y desafiaré una idea fundamental: que el 1.0 es la solución a todos los problemas. ¡Espero que estés listo, va a ser salvaje!

This talk has been presented at React Summit Remote Edition 2020, check out the latest edition of this React Conference.

FAQ

Lorenzo, también conocido como Kalset, es un ingeniero de software en Formidable en la oficina del Reino Unido y un mantenedor principal de React Native. Organiza meetups en Londres para mantenedores de código abierto y tiene experiencia significativa trabajando con React Native.

El versionado permite introducir un nivel de estabilidad declarando explícitamente que una versión del código es suficientemente buena para ser entregada como una unidad. Esto ayuda en la reproducibilidad y en asegurar que todas las dependencias y el código sean consistentes para futuras pruebas y desarrollos.

El proceso de lanzamiento de una versión de React Native es complejo e involucra numerosos pasos, incluyendo pruebas manuales, generación de documentación y comunicación con la comunidad. Se realiza mucha iteración y pruebas para asegurar que cada lanzamiento sea estable y confiable.

Upgrade Helper es una aplicación web diseñada para ayudar a la comunidad de React Native en el proceso de actualización de una versión a otra. Facilita la visualización de diferencias y cambios necesarios para migrar eficientemente entre versiones de React Native.

Las versiones de React Native son complicadas debido a la rapidez con la que el código evoluciona y la integración con múltiples ecosistemas como Android e iOS. Además, la gestión de lanzamientos involucra coordinación con Facebook, que utiliza un monorepo para React Native, lo cual puede introducir desafíos adicionales.

Que React Native no haya alcanzado la versión 1.0 no implica que no sea utilizable. Lorenzo explica que la versión 1.0 es más una promesa de estabilidad y soporte a largo plazo, pero React Native ya es ampliamente utilizado y viable para producción, como lo demuestra su adopción exitosa por muchas empresas.

22 min
02 Aug, 2021

Comments

Sign in or register to post your comment.
Video Summary and Transcription
Bienvenido a una charla sobre los lanzamientos de React Native, donde el orador comparte su experiencia y perspectiva. Se discuten las complejidades de los lanzamientos de React Native, incluyendo los desafíos de las pruebas manuales y los conflictos con las dependencias. Se destaca la participación de la comunidad y la mejora de la comunicación con Facebook. El orador también menciona la automatización incremental del proceso de lanzamiento. React Native 1.0 se ve como una promesa de un producto finalizado con soporte a largo plazo. Se menciona el plan a largo plazo para la nueva arquitectura de React Native, con un enfoque en minimizar los cambios disruptivos.
Available in English: The 1.0 is a Lie

1. Introduction to React Native Releases

Short description:

Bienvenidos a mi charla sobre las versiones de React Native. He sido desarrollador en React Native durante los últimos tres años y un lanzador desde la versión 57. Esta charla se basa en mi experiencia y punto de vista. Me interesa saber qué versión de React Native has estado utilizando y cuánto tiempo has estado en el campo. También tendremos una sesión de preguntas y respuestas después de la presentación. Sumergámonos en las versiones y discutamos por qué las hacemos.

Bienvenidos a todos. Estoy muy contento de estar aquí y hablar con todos ustedes. Y hoy, voy a hablarles sobre algo que es realmente importante para mí, y probablemente para la mayoría de ustedes, desarrolladores de React Native.

Así que vamos directo al grano. Soy Lorenzo. Puede que me conozcan como Kalset. Soy ingeniero de software en Formidable para la oficina del Reino Unido en Londres, donde vivo. Soy un mantenedor principal de React Native, lo cual es tal vez por lo que pueden conocerme, y también organizador de Provided As Is, que es un meetup aquí en Londres para mantenedores de código abierto, que suelo llamar en broma terapia grupal para mantenedores.

Verán, hoy quiero hablarles sobre las versiones, pero quiero asegurarme de empezar con el pie derecho. Para darles un poco de contexto, he sido desarrollador en React Native, utilizando React Native, durante los últimos tres años casi. Así que he estado aquí desde la versión 30, más o menos. Y he sido un lanzador desde la versión 57. Esa que ven ahí, en particular, es mi primera versión. Esto quiere decir que he estado aquí bastante tiempo, pero por favor, recuerden que esta charla es desde mi experiencia, mi punto de vista. Así que no tomen nada de lo que digo como oficial.

Además, quiero saber de ustedes. Sé que tenemos un chat en marcha. Voy a leer todas sus respuestas y comentarios mientras hago la presentación. Pero por favor, díganme qué versión han estado utilizando y cuánto tiempo han estado en el campo de React Native. Es realmente interesante, por lo general, saber hasta qué punto podemos retroceder. A veces la gente incluso viene desde la versión 20. Y también, recuerden que si tienen alguna pregunta para mí, tenemos una sesión de preguntas y respuestas después de esto, y tenemos una sala de oradores, y también hay un salón de consejos. Así que hay mucho tiempo para preguntarme cualquier cosa que se les ocurra mientras ven esta presentación.

Así que sumerjámonos en las versiones. Y la primera parte de la que quiero hablar es ¿por qué hacemos versiones? Suena bastante simple, ¿verdad? Queremos proporcionar de alguna manera nuestro código a otras personas para que lo puedan utilizar, ¿verdad? Pero no es solo eso. Técnicamente, cuando expones tu código en GitHub, por ejemplo, el archivo packages.json de NPM te permite apuntar técnicamente a cualquier repositorio sin necesidad de un lanzamiento estricto en el registro de NPM. Pero hacemos versiones. Hacemos versionado porque queremos introducir un nivel de estática. Queremos decir, okay, esta es una versión.

2. Code Versioning and Reproducibility

Short description:

Esta es una versión del código que he decidido que es lo suficientemente buena como para ser entregada como un paquete. Prefiero la estática estricta para la reproducibilidad, especialmente en el mundo móvil. Me permite probar versiones anteriores de la aplicación con un código preciso.

Esta es una versión del código. Este es un paquete que he decidido que es lo suficientemente bueno como para ser entregado como una especie de unidad. Es eso. Además, esta es una de las razones por las que las dependencias dinámicas, el uso del cara para algunas dependencias, no me gusta mucho eso. Prefiero la estática estricta. ¿Por qué me gusta eso? Porque permite la reproducibilidad. En particular en el mundo móvil, realmente quiero minimizar la posibilidad de que no pueda llegar al punto en el tiempo a esa instantánea precisa para ese código. Por ejemplo, si necesito probar la versión anterior de la aplicación que lancé, necesito asegurarme de que el código y cada pieza de código que estoy usando, o en su mayor parte, tanto como pueda controlar, sea precisamente el mismo para poder trabajar en él.

3. Different Release Examples

Short description:

Comencemos con un ejemplo sencillo: subo el código de mi sitio web a GitHub, lo que activa un gancho de Git que lleva a Netlify a hacer su magia. Para una aplicación más compleja, creamos una rama desde la rama principal, generamos una etiqueta y ejecutamos una serie de disparadores en nuestra herramienta de CI. Una vez que todo está en verde, la aplicación se empaqueta y se envía a las tiendas. El proceso de lanzamiento de React Native es aún más complejo, con múltiples pasos y consideraciones.

Dicho esto, ¿cómo lanzamos una versión? Para abordar esta pregunta, he decidido utilizar algunos ejemplos. Comencemos con uno sencillo. Calcet.dev es mi sitio web y es horrible. Por favor, por favor, por favor no vayas. No lo mires. Es feo. Me vas a odiar por ir allí. Así que no me odies. Solo confía en que existe. Lo subo a GitHub, luego hay un gancho de Git que se activa, y eso lleva a Netlify a hacer su magia, y luego el código está listo. Está ahí fuera. Se lanza, y se va hacia el atardecer.

Ahora, por supuesto, esto es muy sencillo. Intentemos algo mejor, algo que viene de mi pasado, en mi experiencia. Esta es potencialmente una aplicación en la que trabajé, no quiero decir mucho al respecto, pero básicamente teníamos una serie de confirmaciones. Cada vez que queríamos hacer un nuevo lanzamiento, creamos una rama desde la rama principal. Generamos una etiqueta en esta nueva rama. Lo subimos, y tenemos una herramienta de CI que ejecuta una serie de disparadores que se activan con esta etiqueta. Y una vez que todo está en verde y todo está listo, tenemos una aplicación lista para ser empaquetada, lista para ser enviada a las tiendas, donde los usuarios pueden descargarla y dirigirse hacia el atardecer.

Y ahora, React Native, este es el ejemplo difícil. Ejecutamos un script y se ejecuta... Simplemente se va hacia el atardecer. Sí, está bien, por supuesto. Eso no es todo, ¿verdad? Sí, por supuesto, no lo es. Este es el verdadero proceso para lanzar una versión de React Native. Probablemente no puedas leer todos los pasos y no te preocupes, está bien. Esto es solo para mostrar cuánto trabajo se realiza en un lanzamiento de React Native que hacemos actualmente. En particular, esto es lo que hemos utilizado para la versión 62. También tuve que combinar algunos pasos para que sea legible. Una cosa en particular, que quiero señalar, es que el paso que te mostré antes está en realidad allí.

4. Complexidades en los Lanzamientos de React Native

Short description:

La complejidad de los lanzamientos de React Native se deriva de varios factores. En proyectos de código abierto, es crucial cuidar de la comunidad y garantizar que los desarrolladores puedan consumir los lanzamientos de manera efectiva. Las pruebas manuales son necesarias debido al ritmo acelerado del código y las dependencias de otras bibliotecas. Aunque Facebook es el propietario de React Native, la comunidad se encarga de los lanzamientos, lo cual presenta sus desafíos. El código se mueve rápidamente y las versiones de parche pueden ser difíciles debido a conflictos. A pesar de estas complejidades, se están realizando mejoras impulsadas por el compromiso de cuidar de la comunidad.

Es uno de ellos, pero está realmente muy avanzado y hay mucho más en juego. Y estoy bastante seguro de que ahora mismo te estás preguntando ¿por qué es complicado? ¿Cuál es la complejidad? Y puedo abordar dos series diferentes de complejidades. El primer tipo está relacionado con una serie de cosas que ocurren en cualquier proyecto de código abierto de tamaño mediano a grande. Estas son complejidades genéricas que la mayoría de nosotros que hacemos código abierto podemos enfrentar. Por ejemplo, el hecho de que te preocupes por la comunidad. Puede sonar extraño, pero básicamente, cuando te preocupas por tu comunidad, cuando haces un lanzamiento, también quieres producir el material para que tus desarrolladores, los desarrolladores que usan tu biblioteca, puedan consumirlo correctamente. Entonces, en React Native, en particular, donde nos importa mucho, tenemos el blog de cambios, hacemos diferencias para que UpgradeHelper pueda mostrar lo que necesitas hacer, tenemos la documentación y muchas otras cosas. También hacemos muchas pruebas manuales porque sí, confiamos en CI, pero también desconfiamos. Además, el código se mueve muy, muy rápido. En particular, en React Native, tenemos alrededor de 400 confirmaciones cada mes, lo cual, ya sabes, es un desafío mantenerse al día con ese ritmo. Y hablando específicamente del código que se mueve rápido, dado que React Native depende de React, por ejemplo, depende de los ecosistemas de Android e iOS, también necesitamos movernos lo suficientemente rápido para poder alcanzar a todas estas otras bibliotecas. Puede parecer trivial, como, oh, bueno, React, solo necesitas actualizar la versión de la biblioteca, ¿verdad? Bueno, en realidad no. Para que React Native use una versión específica de React, necesita tener una confirmación de sincronización donde se requiere trabajo manual. Y dejé un ejemplo allí. Pero hablando de las complejidades específicas de React Native, he abordado dos en esta diapositiva. Uno, que probablemente es el que más malentendidos genera, es que Facebook es el propietario de React Native, pero la comunidad se encarga de los lanzamientos. Y esto es algo que, y hablaré un poco más sobre esto más adelante, ha estado mejorando, pero internamente, Facebook, en su monorepo, usa React Native. Es decir, no hacen React Native en sí, por lo que su experiencia con el código es diferente. Además, debido a que el código de React Native no es de código abierto en primer lugar, como sucede con React, sino que es un espejo del código que tienen en su monorepo, cuando una persona del equipo de React Native hace una confirmación internamente, luego se replica en la rama principal de la versión de código abierto sin pasar por el procedimiento estándar de PR. No pasa por el mismo CI. Por lo tanto, a veces, debido a que el CI interno y el CI externo son diferentes, a veces el CI externo puede fallar. Y también, Facebook siempre puede tener la última palabra o la última decisión. O pueden decidir algo sobre el lanzamiento y nosotros tenemos que cumplir con estos nuevos requisitos. Además, como mencioné, el código se mueve rápido, y el proceso de lanzamiento pasa por ramas, por lo que para cada lanzamiento estable, creamos una rama. A veces es difícil hacer lanzamientos de parches. Entonces, si, por ejemplo, 62.1, queríamos seleccionar una confirmación, pero esta confirmación se realizó, digamos, dos meses después del punto en el que creamos la rama, seleccionarla, que es un procedimiento en Git para tomar una confirmación y reaplicarla en una rama, puede generar conflictos. Por lo tanto, eso introduce un poco de complejidad. Entonces, como mencioné, aunque existen estas complejidades, en particular el aspecto de Facebook, está mejorando, está mejorando mucho, y hablaré un poco más sobre eso en un momento. Pero ahora, revisemos esos pasos. Como estaba diciendo, mucho trabajo, muchas iteraciones, muchos pasos que hacemos aquí no son estrictamente por el código, sino porque nos importa.

5. Participación de la Comunidad y Mejora de la Comunicación

Short description:

Como puedes ver, hacemos muchas cosas para generar material relacionado con la comunidad, incluyendo documentación, publicaciones de blog y diferencias para el asistente de actualización. También realizamos pruebas manuales para asegurarnos de que el código se comporte como se espera. Resolvemos lo que podemos y trabajamos en soluciones alternativas para lo que no podemos. Una solución útil que implementamos es la fase RC, donde cada lanzamiento se prueba antes de llegar al punto cero. Hemos aumentado el número de personas involucradas en el proceso y ha habido una mejora en la comunicación con Facebook, gracias a Eloy del equipo de Microsoft. Esta mayor participación y comunicación son reconfortantes y probablemente seguirán aumentando con el tiempo.

Como puedes ver, todo lo amarillo, son cosas que hacemos para generar material relacionado con la comunidad, como la documentación, las publicaciones de blog, las diferencias para el asistente de actualización, y también realizamos muchas pruebas manuales para asegurarnos de que podamos confiar en la IA, pero también para asegurarnos de que el código se comporte de manera confiable. Verás, todo esto es porque, y esto comenzó incluso antes de este comentario, pero este comentario realmente resaltó el problema de los lanzamientos directos necesarios y ha dejado a todo el equipo trabajando en este problema con la pregunta constante en la mente de cómo resolver este problema. Y creo que la respuesta más fácil a esto es que resolvemos lo que podemos y trabajamos en soluciones alternativas para lo que no podemos. Ya sabes, como acabo de mencionar, es realmente complicado, por lo que no podemos abordar todos los problemas. Por ejemplo, cuando se trata de resolver, una cosa que hemos hecho, que ha sido bastante útil, es la introducción de la fase RC, como la llamamos. Y algunos de ustedes pueden estar pensando, oh sí, hemos estado haciendo eso desde siempre. No, en realidad la primera vez que lo hicimos fue en la versión 60, lo cual incluso me confundió. Pensé, oh no, deberíamos haberlo hecho incluso mucho antes que eso. Pero también la razón por la que comenzamos a hacerlo es porque cada lanzamiento se prueba antes de llegar al punto cero y nos aseguramos de que la versión sea estable y se hayan solucionado todas las principales regresiones antes de eso. Además, hemos involucrado a más personas en el proceso, cuando comencé a hacer esto, básicamente solo estaba Mike, luego me uní a él, y generalmente éramos él o yo, y luego conseguimos a Ciarpini o Hector Ramos para que nos ayudaran con el sitio web y la parte de la documentación, pero ahora, y es tan refrescante y agradable verlo, tenemos al menos cuatro o cinco personas constantemente involucradas en cada lanzamiento, e incluso hay más personas que participan de manera más puntual, hacen una contribución, ayudan, y luego vuelven a enfocarse en lo que estaban haciendo. Y también, como mencioné anteriormente, ha habido un aumento significativo en la comunicación con Facebook últimamente. No es solo algo general, también gracias a Eloy del equipo de Microsoft, como mencioné anteriormente, y todos los demás miembros del equipo de Facebook realmente han dado un paso adelante. Eli en particular ha sido un gran defensor de este nuevo nivel de comunicación como se destaca en este problema, abrió este problema sobre la versión 63, que ni siquiera se ha creado en términos de ramificación. Y es increíble porque se tomó el tiempo para decirnos lo que va a suceder en esa versión, qué trabajo se requiere y algunas fechas relacionadas, lo cual es increíble. Para mí, ver este nuevo nivel de participación es realmente reconfortante y puedo ver que esto aumentará cada vez más con el tiempo.

6. Automatización del Proceso de Lanzamiento

Short description:

Somos conscientes de que no podemos automatizar completamente todo el proceso de lanzamiento, por eso iteramos incrementalmente en este proceso. El Upgrade Helper y el repositorio Upgrade Support son formas en las que la comunidad puede unirse y ayudarse mutuamente en las actualizaciones. Estamos mejorando constantemente el proceso, como mejorar el script para las pruebas de extremo a extremo y hacer que la generación de nuevos DEVS sea automática.

Hablando de soluciones, por ejemplo, estamos bastante seguros de que nunca llegará al punto de que una actualización sea un script de una sola línea. A lo largo del tiempo, en los últimos años, han intentado seguir ese enfoque en la CLI, pero en nuestra experiencia, nunca lo han soportado completamente o han dejado su base de código limpia después de ejecutarlo. Por eso creamos Upgrade Helper, que es una aplicación web, y espero que todos sepan qué es en este punto, ha estado presente durante un par de versiones, y el nuevo repositorio Upgrade Support. Ambos son formas en las que la comunidad puede unirse y ayudarse mutuamente en la actualización de una versión a otra. También somos conscientes de que no podemos automatizar completamente todo el proceso de lanzamiento, por eso iteramos incrementalmente en este proceso en la lista de puntos, como nunca ha sido esa lista desde el principio. Es un progreso, un trabajo que comenzamos en ese entonces y que sigue mejorando en este momento. Por ejemplo, Eloy está trabajando en otra solicitud de extracción para mejorar el script que usamos para las pruebas de extremo a extremo de forma manual cuando hacemos la ramificación y las pruebas localmente. Y también Lucas ha estado trabajando mucho en el Upgrade Helper. Ahora están planeando hacer que toda la parte de generación de nuevos DEVS sea completamente automática. Entonces, nuevamente, es un proceso constante de mejora sobre lo que no podemos resolver completamente.

7. Lanzamientos de React Native: 1.0 y Usabilidad

Short description:

Lanzar React Native es complicado, pero 1.0 no es la solución final. 1.0 es solo semántica, una promesa de un producto finalizado y soporte a largo plazo. React Native se puede utilizar antes de 1.0, al igual que Gmail estuvo en beta durante 5 años. React Native ya es ampliamente utilizable y ha sido utilizado con éxito por muchas empresas. He sido desarrollador de React Native durante años y todos mis proyectos siguen funcionando.

Entonces, para resumir, lanzar React Native espero que en este punto te haya convencido de que es realmente complicado. La base de código se mueve muy, muy rápido y todos los involucrados están trabajando para mejorarlo, para mejorar la experiencia. No solo lanzándolo, sino también el lanzamiento real y la experiencia para todos los que consumen React Native para que todos puedan tener una mejor experiencia con él.

Y, nuevamente, no solo las personas de la comunidad. Es el equipo de Facebook y los equipos de Microsoft que han estado colaborando mucho y colaborando mucho más que solo yo personalmente.

Dicho esto, volvamos al título de mi charla, de alguna manera. Estoy bastante seguro de que en este punto estarás pensando, sí, claro, está bien, es complicado, pero ¿no sería 1.0 la solución final? ¿No resolvería todos mis problemas tener una versión 1.0? ¿Debería esperar a 1.0 para usar React Native en producción? Y a eso, mi respuesta es un claro no. Permíteme explicarlo. 1.0, en sí mismo, es solo semántica. 1.0 es una promesa. Es una promesa de tener un producto finalizado, como, está bien, ese cuadrado, ahora está completo, y es un cuadrado que puedo prometer que funcionará como debería, es como lo imaginé, y también trae consigo una promesa de soporte a largo plazo. Como no estamos acostumbrados a tener muchas versiones principales, una tras otra, en particular, para piezas más grandes de software sin cambios drásticos, y generalmente, esperaríamos que la versión principal se mantenga durante mucho tiempo. Pero dicho esto, 1.0 no significa que el producto no sea utilizable, como simplemente porque 1.0 no está ahí no significa que React Native no se pueda usar. Como Gmail. Como, vamos a un reino completamente diferente. Hablemos de un software que ha existido durante mucho tiempo. Probablemente la mayoría de ustedes no recuerden esto. Pero cuando se lanzó para el público, en realidad todavía estaba en beta. Como, tienes el logo de Gmail con la etiqueta beta y se mantuvo de esa manera durante 5 años. ¿Y por qué es eso? Bueno, porque esa etiqueta estaba ahí para decir hey gente, todavía estamos trabajando en ello. Todavía estamos ajustándolo y agregando cosas nuevas. Lo cual es algo que está sucediendo con React Native. Entonces, ¿estamos condenados? Como, ya que no obtenemos 1.0, ¿nunca deberíamos usar React Native en producción? Espero que a estas alturas ya sepas hacia dónde me dirijo con mi respuesta. Pero la respuesta, por supuesto, es definitivamente no. Como, React Native ya es ampliamente utilizable. Como, ya ha sido utilizado con éxito en todo el mundo. Muchas empresas lo han utilizado con éxito. Por supuesto, no todas, pero cientos y cientos lo han hecho. Y he sido desarrollador de React Native durante tres o cuatro años hasta ahora. Y todos los proyectos en los que he trabajado todavía están ahí, siguen existiendo, siguen funcionando, y todavía estoy muy seguro de que ha sido la apuesta correcta para esos proyectos.

8. Plan a largo plazo de React Native y Conclusiones

Short description:

React Native tiene un plan a largo plazo para la nueva arquitectura. Ya se están llevando a cabo discusiones con Facebook para manejar el lanzamiento de las primeras piezas. El objetivo es garantizar la menor cantidad de cambios disruptivos posible. El proceso de lanzamiento es complicado pero necesario. React Native está en constante evolución y la versión 1.0 aún está lejos. Disfruta usando React Native ahora. Gracias por unirte a la conversación y mantente atento a la sesión de preguntas y respuestas y a la sala del orador.

Además, como probablemente sepas, ya hay un plan a largo plazo en marcha para la nueva arquitectura de React Native. Y en particular, voy a decir esto, mantengámoslo en secreto entre nosotros básicamente, pero ya estamos hablando con Facebook sobre cómo deberíamos manejar el lanzamiento de una de las primeras piezas de la nueva arquitectura en el futuro, y estamos tratando de crear una hoja de ruta para eso. Así que hay un plan a largo plazo, ya estamos actuando en consecuencia y estamos tratando de asegurarnos de que sea la experiencia menos disruptiva posible para todos.

Entonces, puedes estar tranquilo de que estamos constantemente tratando de mejorar. Como mencioné anteriormente, para cerrar todo esto, el proceso de lanzamiento es complicado pero por buenas razones. React Native sigue evolucionando y todos lo saben y la versión 1.0 1.0.0 aún está lejos para React Native. Así que sí, básicamente, 1.0 es una mentira y puedes divertirte usando React Native ahora mismo.

Quiero agradecer a todos por quedarse, escuchar esta conversación, espero que hayan disfrutado aprendiendo un poco más sobre los lanzamientos. Mis contactos están allí, pueden contactarme en mi Twitter, tengo una dirección de correo electrónico allí y si están viendo esto en vivo, ahora vamos a tener una sesión de preguntas y respuestas y luego habrá una sala de oradores y luego habrá un lanzamiento anticipado, así que si tienen alguna pregunta adicional, por favor, por favor, por favor, pregúntenme allí y voy a publicar las diapositivas en mi Twitter muy pronto. Gracias por quedarse. 1.0 1.0 1.0 1.0 1.0

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

Elevando el Listón: Nuestro Viaje Haciendo de React Native una Opción Preferida
React Advanced 2023React Advanced 2023
29 min
Elevando el Listón: Nuestro Viaje Haciendo de React Native una Opción Preferida
This Talk discusses Rack Native at Microsoft and the efforts to improve code integration, developer experience, and leadership goals. The goal is to extend Rack Native to any app, utilize web code, and increase developer velocity. Implementing web APIs for React Native is being explored, as well as collaboration with Meta. The ultimate aim is to make web code into universal code and enable developers to write code once and have it work on all platforms.
Llevando los Componentes del Servidor React a React Native
React Day Berlin 2023React Day Berlin 2023
29 min
Llevando los Componentes del Servidor React a React Native
Top Content
React Server Components (RSC) offer a more accessible approach within the React model, addressing challenges like big initial bundle size and unnecessary data over the network. RSC can benefit React Native development by adding a new server layer and enabling faster requests. They also allow for faster publishing of changes in mobile apps and can be integrated into federated super apps. However, implementing RSC in mobile apps requires careful consideration of offline-first apps, caching, and Apple's review process.
Herramienta Multiplataforma de React Native Kotlin
React Day Berlin 2022React Day Berlin 2022
26 min
Herramienta Multiplataforma de React Native Kotlin
Top Content
The Talk discusses the combination of React Native and Kotlin Multiplatform for cross-platform app development. Challenges with native modules in React Native are addressed, and the potential improvements of using Kotlin Multiplatform Mobile are explored. The integration of Kotlin Multiplatform with React Native streamlines native implementation and eliminates boilerplate code. Questions about architecture and compatibility, as well as the possibility of supporting React Native Web, are discussed. The React Native toolkit works with native animations and has potential for open-source development.
“Microfrontends” para móviles en React Native
React Advanced 2023React Advanced 2023
24 min
“Microfrontends” para móviles en React Native
Top Content
Micro frontends are an architectural style where independent deliverable frontend applications compose a greater application. They allow for independent development and deployment, breaking down teams into feature verticals. React Native's architecture enables updating the JavaScript layer without going through the app store. Code Push can be used to deploy separate JavaScript bundles for each micro frontend. However, there are challenges with managing native code and dependencies in a micro frontend ecosystem for mobile apps.
Construyendo Bibliotecas de Componentes Multiplataforma para Web y Nativo con React
React Advanced 2021React Advanced 2021
21 min
Construyendo Bibliotecas de Componentes Multiplataforma para Web y Nativo con React
Top Content
This Talk discusses building cross-platform component libraries for React and React Native, based on a successful project with a large government-owned news organization. It covers the requirements for React Native knowledge, building cross-platform components, platform-specific components, styling, and the tools used. The Talk also highlights the challenges of implementing responsive design in React Native.

Workshops on related topic

Presentando FlashList: Construyamos juntos una lista performante en React Native
React Advanced 2022React Advanced 2022
81 min
Presentando FlashList: Construyamos juntos una lista performante en React Native
Top Content
Featured Workshop
David Cortés Fulla
Marek Fořt
Talha Naqvi
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
Detox 101: Cómo escribir pruebas de extremo a extremo estables para su aplicación React Native
React Summit 2022React Summit 2022
117 min
Detox 101: Cómo escribir pruebas de extremo a extremo estables para su aplicación React Native
Top Content
Workshop
Yevheniia Hlovatska
Yevheniia Hlovatska
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
Cómo construir una animación interactiva de “Rueda de la Fortuna” con React Native
React Summit Remote Edition 2021React Summit Remote Edition 2021
60 min
Cómo construir una animación interactiva de “Rueda de la Fortuna” con React Native
Top Content
Workshop
Oli Bates
Oli Bates
- 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
Despliegue de aplicaciones React Native en la nube
React Summit 2023React Summit 2023
88 min
Despliegue de aplicaciones React Native en la nube
WorkshopFree
Cecelia Martinez
Cecelia Martinez
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.
Pruebas Efectivas con Detox
React Advanced 2023React Advanced 2023
159 min
Pruebas Efectivas con Detox
Workshop
Josh Justice
Josh Justice
Así que has configurado Detox para probar tu aplicación React Native. ¡Buen trabajo! Pero aún no has terminado: todavía hay muchas preguntas que necesitas responder. ¿Cuántas pruebas escribes? ¿Cuándo y dónde las ejecutas? ¿Cómo te aseguras de que hay datos de prueba disponibles? ¿Qué haces con partes de tu aplicación que utilizan APIs móviles que son difíciles de automatizar? Podrías invertir mucho esfuerzo en estas cosas, ¿vale la pena?
En esta masterclass de tres horas abordaremos estas preguntas discutiendo cómo integrar Detox en tu flujo de trabajo de desarrollo. Saldrás con las habilidades e información que necesitas para hacer de las pruebas Detox una parte natural y productiva del desarrollo diario.
Tabla de contenidos:
- Decidir qué probar con Detox vs React Native Testing Library vs pruebas manuales- Configuración de una capa de API falsa para pruebas- Cómo hacer que Detox funcione en CI en GitHub Actions de forma gratuita- Decidir cuánto de tu aplicación probar con Detox: una escala móvil- Integración de Detox en tu flujo de trabajo de desarrollo local
Prerrequisitos
- Familiaridad con la construcción de aplicaciones con React Native- Experiencia básica con Detox- Configuración de la máquina: un entorno de desarrollo CLI de React Native en funcionamiento que incluye Xcode o Android Studio
Creación para Web y Móvil con Expo
React Day Berlin 2022React Day Berlin 2022
155 min
Creación para Web y Móvil con Expo
Workshop
Josh Justice
Josh Justice
Sabemos que React es para la web y React Native es para Android e iOS. Pero ¿has oído hablar de react-native-web? ¡Para escribir una aplicación para Android, iOS y la web en un solo código base! Al igual que React Native abstrae los detalles de iOS y Android, React Native Web también abstrae los detalles del navegador. Esto abre la posibilidad de compartir aún más código entre plataformas.
En este masterclass, aprenderás a configurar el esqueleto de una aplicación React Native Web que funcione de manera excelente y se vea increíble. Puedes utilizar el código resultante como base para construir la aplicación que desees, utilizando los paradigmas de React y muchas bibliotecas de JavaScript a las que estás acostumbrado. ¡Te sorprenderá la cantidad de tipos de aplicaciones que realmente no requieren un código base separado para móvil y web!
Qué se incluye1. Configuración de navegadores de cajón y de pila con React Navigation, incluyendo la capacidad de respuesta2. Configuración de React Navigation con URLs3. Configuración de React Native Paper, incluyendo el estilo del cajón y los encabezados de React Navigation4. Configuración de un tema de color personalizado que admita el modo oscuro5. Configuración de favicons/iconos de aplicaciones y metadatos6. Qué hacer cuando no puedes o no quieres proporcionar la misma funcionalidad en la web y en el móvil
Requisitos previos- Familiaridad con la construcción de aplicaciones con React o React Native. No es necesario conocer ambos.- Configuración de la máquina: Node LTS, Yarn, ser capaz de crear y ejecutar correctamente una nueva aplicación Expo siguiendo las instrucciones en https://docs.expo.dev/get-started/create-a-new-app/