La mentira del 1.0

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.

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.

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í.

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.

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.

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.

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.

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