La mentira del 1.0

Rate this content
Bookmark

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!

22 min
02 Aug, 2021

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

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

React Advanced Conference 2023React Advanced Conference 2023
29 min
Raising the Bar: Our Journey Making React Native a Preferred Choice
At Microsoft, we're committed to providing our teams with the best tools and technologies to build high-quality mobile applications. React Native has long been a preferred choice for its high performance and great user experience, but getting stakeholders on board can be a challenge. In this talk, we will share our journey of making React Native a preferred choice for stakeholders who prioritize ease of integration and developer experience. We'll discuss the specific strategies we used to achieve our goal and the results we achieved.
React Finland 2021React Finland 2021
27 min
Opensource Documentation—Tales from React and React Native
Documentation is often your community's first point of contact with your project and their daily companion at work. So why is documentation the last thing that gets done, and how can we do it better? This talk shares how important documentation is for React and React Native and how you can invest in or contribute to making your favourite project's docs to build a thriving community
React Day Berlin 2023React Day Berlin 2023
29 min
Bringing React Server Components to React Native
React Server Components are new topic in community, bunch of frameworks are implementing them, people are discussing around this topic. But what if we could use React Server Components in React Native? And bring all optimisation features that RSC allows to mobile apps? In this talk I would present what we are able to do with RSC in React Native!
React Advanced Conference 2021React Advanced Conference 2021
21 min
Building Cross-Platform Component Libraries for Web and Native with React
Top Content
Building products for multiple platforms such as web and mobile often requires separate code-based despite most of the components being identical in look and feel. Is there a way where we could use shared React component library on different platforms and save time? In this presentation I'll demonstrate one way to build truly cross-platform component library with a unique approach of using React & React Native in combination.

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
Top Content
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
Top Content
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
60 min
How to Build an Interactive “Wheel of Fortune” Animation with React Native
Top Content
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
React Advanced Conference 2023React Advanced Conference 2023
159 min
Effective Detox Testing
Workshop
So you’ve gotten Detox set up to test your React Native application. Good work! But you aren’t done yet: there are still a lot of questions you need to answer. How many tests do you write? When and where do you run them? How do you ensure there is test data available? What do you do about parts of your app that use mobile APIs that are difficult to automate? You could sink a lot of effort into these things—is the payoff worth it?
In this three-hour workshop we’ll address these questions by discussing how to integrate Detox into your development workflow. You’ll walk away with the skills and information you need to make Detox testing a natural and productive part of day-to-day development.
Table of contents:
- Deciding what to test with Detox vs React Native Testing Library vs manual testing- Setting up a fake API layer for testing- Getting Detox running on CI on GitHub Actions for free- Deciding how much of your app to test with Detox: a sliding scale- Fitting Detox into you local development workflow
Prerequisites
- Familiarity with building applications with React Native- Basic experience with Detox- Machine setup: a working React Native CLI development environment including either Xcode or Android Studio
React Summit 2023React Summit 2023
88 min
Deploying React Native Apps in the Cloud
WorkshopFree
Deploying React Native apps manually on a local machine can be complex. The differences between Android and iOS require developers to use specific tools and processes for each platform, including hardware requirements for iOS. Manual deployments also make it difficult to manage signing credentials, environment configurations, track releases, and to collaborate as a team.
Appflow is the cloud mobile DevOps platform built by Ionic. Using a service like Appflow to build React Native apps not only provides access to powerful computing resources, it can simplify the deployment process by providing a centralized environment for managing and distributing your app to multiple platforms. This can save time and resources, enable collaboration, as well as improve the overall reliability and scalability of an app.
In this workshop, you’ll deploy a React Native application for delivery to Android and iOS test devices using Appflow. You’ll also learn the steps for publishing to Google Play and Apple App Stores. No previous experience with deploying native applications is required, and you’ll come away with a deeper understanding of the mobile deployment process and best practices for how to use a cloud mobile DevOps platform to ship quickly at scale.
React Advanced Conference 2022React Advanced Conference 2022
131 min
Introduction to React Native Testing Library
Workshop
Are you satisfied with your test suites? If you said no, you’re not alone—most developers aren’t. And testing in React Native is harder than on most platforms. How can you write JavaScript tests when the JS and native code are so intertwined? And what in the world are you supposed to do about that persistent act() warning? Faced with these challenges, some teams are never able to make any progress testing their React Native app, and others end up with tests that don’t seem to help and only take extra time to maintain.
But it doesn’t have to be this way. React Native Testing Library (RNTL) is a great library for component testing, and with the right mental model you can use it to implement tests that are low-cost and high-value. In this three-hour workshop you’ll learn the tools, techniques, and principles you need to implement tests that will help you ship your React Native app with confidence. You’ll walk away with a clear vision for the goal of your component tests and with techniques that will help you address any obstacle that gets in the way of that goal.you will know:- The different kinds React Native tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting text, image, and native code elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RNTL tests and how to handle them- Options for handling native functions and components in your JavaScript tests
Prerequisites:- Familiarity with building applications with React Native- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Native Testing Library- Machine setup: Node 16.x or 18.x, Yarn, be able to successfully create and run a new Expo app following the instructions on https://docs.expo.dev/get-started/create-a-new-app/