Medición y Mejora del Rendimiento de React Native

Rate this content
Bookmark

La web tiene varias herramientas para medir el rendimiento, pero ¿qué hay de nosotros, los desarrolladores de React Native? ¿Alguna vez has agregado alguna optimización en tu código (como un memo aquí y allá) y te has preguntado si realmente tiene un impacto en el rendimiento?

Presentando un complemento de Flipper para medir el rendimiento de React Native, con un caso concreto de cómo lo utilizamos para llevar el rendimiento de nuestra aplicación a la máxima calidad.

Bonus: ¡una inmersión profunda en los gráficos de llama de React DevTools!

19 min
21 Jun, 2022

Video Summary and Transcription

Esta Charla analiza el rendimiento de las aplicaciones móviles y proporciona consejos para el análisis de rendimiento. Incluye una prueba de rendimiento en la aplicación de noticias TF1 y demuestra cómo analizar el rendimiento de JS con React DevTools. La Charla también explora la optimización del renderizado en componentes de React, como FlatList y listas anidadas con carruseles. Concluye con estrategias para optimizar la lista virtualizada y el carrusel para lograr un mejor rendimiento.

Available in English

1. Introducción al rendimiento de aplicaciones móviles

Short description:

Hola a todos. Soy Alex, un líder técnico en BAM. Hablemos sobre el rendimiento de las aplicaciones móviles. Un buen rendimiento significa funcionar a 60 fps, dibujando 60 imágenes por segundo. En las aplicaciones de React Native, el hilo JS puede causar falta de respuesta. Utiliza el Monitor de Rendimiento de React Native y el complemento Flipper para monitorear. Realiza pruebas en dispositivos de gama baja y realiza medidas de rendimiento de manera determinista. Automatiza el comportamiento para reproducir condiciones.

Estoy muy emocionado de hablarles en la React Summit. Soy Alex. Soy un líder técnico en BAM. Desarrollamos aplicaciones móviles en Kotlin, Flutter y, por supuesto, React Native, y me encanta el tema del rendimiento de las aplicaciones móviles, así que vamos a sumergirnos.

¿Qué significa que una aplicación móvil tenga un buen rendimiento? Bueno, según este video de Google, que estará disponible en las diapositivas, tus aplicaciones deben poder funcionar a 60 fps, 60 imágenes por segundo. Esto significa que tu aplicación debe poder dibujar 60 imágenes por segundo cuando te desplazas hacia abajo, por ejemplo, para dar una impresión de suavidad al usuario. Básicamente, es como una película. Son imágenes animadas, básicamente.

La pregunta es, ¿qué pasa con las aplicaciones de React Native? Bueno, esto también se aplica a las aplicaciones de React Native, pero hay una complejidad añadida, el hilo JS. Debido a que la mayoría de tu lógica se ejecutará en el JS, es probable que la mayor parte de tu lógica empresarial resida en el lado del JS, debes asegurarte de que no esté demasiado ocupado. Por ejemplo, aquí tengo esta aplicación con un botón Haz clic en mí. Cuando hago clic en él, se actualiza el estado. He hecho clic una, dos, tres veces, pero Kill.js es demasiado costoso, así que cuando hago clic en él, el lado del JS se bloquea. Así que, incluso si hago clic en Haz clic en mí muchas veces después de hacer clic en Kill.js, no sucede nada, y no es hasta que Kill.js ha terminado que el JS realmente vuelve a responder, y puedes ver que se actualiza de cuatro a 12 veces así. Así que es muy importante echar un vistazo también al lado del JS, porque tu aplicación podría estar funcionando nativamente a 60 FPS pero ser completamente irresponsiva. Es por eso que React Native ofrece esta vista, el Monitor de Rendimiento de React Native, que muestra FPS de la interfaz de usuario y del JS, y es por eso que creamos este complemento Flipper, para poder mostrarlo en un gráfico. Además, como bonificación adicional, te proporciona una puntuación agradable para que puedas ejecutar pruebas de rendimiento. Pero, lo más probable es que esta puntuación pueda depender de muchos factores, en realidad, así que permíteme darte algunos consejos generales sobre medidas de rendimiento.

El primero es este. Debes realizar pruebas en un dispositivo de gama baja. Quiero decir, si solo pruebas en un dispositivo de gama alta, es probable que te pierdas la mayoría de los problemas que tus usuarios podrían estar experimentando. Un iPhone 13 puede ejecutar JavaScript o algún cálculo 10 veces más rápido que un Samsung Galaxy A21s, así que, bueno, ya sabes qué hacer. Definitivamente deberías probar en un dispositivo Android de gama baja. El segundo consejo es este. Debes hacer que tus medidas sean lo más deterministas posible. Las medidas de rendimiento son difícilmente deterministas, así que puedes hacer varias iteraciones y promediar el resultado. También puedes asegurarte de mantener las mismas condiciones tanto como sea posible para cada medida, por ejemplo, la red, los datos que estabas cargando, etc. Y, quiero decir, si quieres reproducir las mismas condiciones, es ideal poder automatizar el comportamiento que deseas probar. Y para eso, no necesariamente necesitas un marco de pruebas de extremo a extremo.

2. Consejos para el análisis de rendimiento

Short description:

Para garantizar medidas de rendimiento precisas en el lado del JS, desactiva JSDev. Utiliza React Devtools y JS Flame Graph para el análisis. En el lado de la interfaz de usuario, utiliza Android Studio, Systrace Profiler o Xcode Instrument.

Puedes usar ADB en Android, por ejemplo. Aquí, con ADB Shell Input Swipe, puedes activar un desplazamiento en tu aplicación. El tercer consejo es este. Desactiva JSDev si quieres tener medidas de rendimiento reales en el lado del JS, debes desactivar esto, porque podrías encontrar un problema que en realidad no verás en producción. Y el cuarto consejo es, bueno, debes encontrar algunos problemas al medir. Simplemente utiliza las mejores herramientas de análisis. En el hilo JS, eso sería React Devtools, o incluso ejecutar un JS Flame Graph con el perfilador Hermes. Y en el lado de la interfaz de usuario, utiliza herramientas nativas como Android Studio, Systrace Profiler o Xcode Instrument en iOS.

3. Prueba de rendimiento en la aplicación de noticias TF1

Short description:

Prueba de rendimiento de la aplicación de noticias TF1 en un dispositivo de gama baja. Objetivo: JSFPS por encima de 0, UIFPS a 60. Se utilizó un Samsung J3 2017. Se midió durante 10 segundos, se recargó con el modo JSDev desactivado. Puntuación del complemento: 40/100. JS no respondió durante 4 segundos. Hilo de interfaz de usuario bien.

Muy bien, vamos a sumergirnos en un ejemplo concreto ahora. TF1 es un canal de noticias de televisión y estamos construyendo su aplicación de noticias, y queríamos asegurarnos de que el rendimiento estuviera a la altura de nuestros estándares de calidad. Así que revisamos el feed de inicio y nuestro objetivo era que cuando desplazáramos hacia abajo, básicamente en un dispositivo de gama baja, deberíamos tener JSFPS siempre por encima de 0 para mantener la capacidad de respuesta del lado de JS, y el UIFPS siempre a 60 para poder ser muy fluido.

Siguiendo los cuatro consejos esenciales que mencioné antes, básicamente utilizamos un Samsung J3 del 2017, es nuestro dispositivo de gama baja favorito, es bastante básico. Configuramos la medición durante 10 segundos, arbitrariamente, pero es importante mantener el mismo tiempo para cada medición para poder comparar. Recargamos con el modo JSDev desactivado. Esperamos a que se cargue el feed y pulsamos Iniciar medición en el complemento Flipper. Ejecutamos ADB shell y PutsWide, blah, blah, blah, y esperamos hasta el final de los 10 segundos, y luego repetimos esto 5 veces solo para poder ver si obtenemos un resultado similar y promediarlo. Y el resultado fue este. El complemento nos dio una puntuación de 40 sobre 100, JS estuvo inactivo durante unos 4 segundos, el hilo de la interfaz de usuario estaba más o menos bien. Pero básicamente, esto significa que la aplicación en realidad no respondió durante unos 4 segundos, lo cual, no hace falta decirlo, era completamente inaceptable.

4. Analizando el rendimiento de JS con React DevTools

Short description:

Para analizar el rendimiento de JS, utiliza React DevTools en Flippr. Haz clic en el botón en la parte superior derecha, marca la casilla para el perfilado en vivo y comienza a grabar. Reproduce las acciones deseadas, detén la grabación y revisa los resultados.

Dado que el problema estaba principalmente en el lado de JS, ejecutamos dos React DevTools, y está disponible de forma predeterminada en Flippr, lo cual es genial. Lo primero que debes hacer es hacer clic en este botón en la parte superior derecha, y allí puedes marcar la casilla, grabar por qué se renderizó cada componente con el perfilado en vivo. Esta es una opción interesante para activar. Veremos por qué muy pronto. Luego, simplemente haz clic en el botón azul aquí para comenzar a grabar. Realiza algunas acciones, en nuestro caso sería reproducir el mismo desplazamiento exacto con adb shell input swipe blah blah blah. Y luego presionamos el botón Detener grabación, y nos da un resultado similar a este.

5. Analizando la jerarquía de componentes de React y la renderización

Short description:

La jerarquía de componentes de React muestra el estado de renderización de cada componente. La lista virtualizada es el componente principal, con varios componentes secundarios llamados renderizadores de celdas. Cada componente tiene métricas de tiempo propio y tiempo total, que indican el tiempo que tarda en renderizarse sin y con hijos, respectivamente. En este caso, la lista virtualizada tarda 3 segundos en renderizarse, incluyendo todos los elementos de la lista.

Muy bien. Lo primero que quieres hacer es verificar esto. Esta es la lista de comentarios. Estas son las fases en las que React aplica realmente los cambios. Y por lo general, cuando se trata de problemas de rendimiento, quieres encontrar los comentarios más costosos en términos de cuánto tiempo tardaron. Y en nuestro caso, este sería el número 11. Es la barra más grande aquí. Así que hagamos clic en él, y esto es lo que nos muestra.

Bastante. Hay muchos colores aquí, pero básicamente esta es la jerarquía de tu componente React. En gris aquí, verás componentes que en realidad no se están renderizando, pero en nuestro caso la pantalla roja y algunos otros colores se están renderizando. Así que si nos acercamos un poco a esta parte, por ejemplo, verás la jerarquía de componentes que comienza con flatlist aquí en gris. Así que no se está renderizando. Entonces nuestro feed de inicio se implementó con flatlist, así que esto es. Y es una implementación interna en el código de React Native. Su hijo se llama lista virtualizada. Así que aquí está. Luego tenemos context.consumer, su hijo es virtualized list.contactProvider, etc., todos hasta llegar a context.provider, básicamente una lista de hijos. Y este chico tiene varios hijos llamados renderizadores de celdas. Básicamente, esto es lo que envuelve las cosas que pasas en tus elementos de renderizado. Entonces, en esencia, los renderizadores de celdas son nuestros elementos de lista de flatlist. También notarás que en cada componente tienes dos métricas. Tienes esta en el lado izquierdo, por ejemplo, aquí 4.9 milisegundos en nuestra lista virtualizada. Es el tiempo propio, es el tiempo que el componente tardó en renderizarse sin ninguno de sus hijos. Y el de la derecha es el tiempo total, es el tiempo total que el componente tardó en renderizarse incluyendo a todos sus hijos.

Así que básicamente aquí tenemos una lista virtualizada que tarda 3 segundos en renderizarse. Y podemos ver que básicamente todos los elementos de la lista también se están renderizando. Así que nuestra lista se está renderizando, todos los elementos de nuestra lista se están renderizando, y esto lleva un total de 3 segundos. Lo cual es un poco loco. Quiero decir, ¿recuerdas cuando hablamos de que el JS estaba bloqueado durante unos 3 o 4 segundos? Esto lo explica completamente, tenemos 3 segundos para eso.

6. Optimizando la Renderización de FlatList

Short description:

Diferencia entre la renderización inicial y la renderización posterior. FlatList es una lista virtualizada que muestra un subconjunto de elementos. Memoiza los elementos de la lista para evitar renderizaciones innecesarias. Los elementos grises están memoizados y ya no se vuelven a renderizar. Los elementos verdes forman parte de la implementación interna y no se pueden evitar que se rendericen. La puntuación de rendimiento mejoró de 40 a 52, con solo 3 segundos de falta de respuesta.

Entonces, ¿qué debemos hacer? Bueno, lo primero que debes hacer es diferenciar entre la renderización inicial, y cuando pasas el cursor sobre un componente, ya que activamos esta nueva opción anteriormente, verás algo como esto. Esta es la primera vez que se renderiza el componente. ¿O esos componentes realmente se están volviendo a renderizar? Han sido montados inicialmente, pero ¿se están renderizando una segunda vez o más veces? Y en este caso verás algo como esto, una lista virtualizada, es un cambio de estado, un último cambio, del cual realmente no sabemos nada porque es la implementación interna de FlatList.

En nuestro caso, en realidad, todos los componentes aquí se estaban volviendo a renderizar porque, recuerda, dije que habíamos cargado nuestro feed anteriormente, por lo que ya se estaban renderizando algunos elementos en el feed, por lo que cuando nos desplazamos hacia abajo, básicamente se están volviendo a renderizar incluso los elementos superiores en el feed. Y esto es una locura, ¿verdad? No es necesario que se rendericen. ¿Entonces qué está pasando? Bueno, la primera iteración que hicimos para solucionarlo fue esta. Y todos deberían saber esto. Entonces, FlatList es una lista virtualizada y la virtualización funciona más o menos así. Tienes una larga lista de elementos, por ejemplo, no sé, 10,000, pero por supuesto, por razones de rendimiento, no podrás mostrarlos todos al mismo tiempo. Utilizas una lista virtualizada para mostrar solo lo que el usuario ve y algunos elementos arriba y algunos elementos abajo para garantizar un desplazamiento suave. Es importante tener en cuenta que en React Native, esta es la propiedad de FlatList llamada tamaño de la ventana y en React Native, en realidad, va a renderizar 10 pantallas de elementos por encima del área de visualización actual y 10 pantallas por debajo de ella. Por lo tanto, en realidad renderiza muchos elementos. Es algo importante a tener en cuenta. Pero, ¿cómo funciona esto? Bueno, básicamente, FlatList mantiene un estado en su implementación interna del primer elemento a renderizar y el último elemento a renderizar. Entonces, cuando nos desplazamos hacia abajo, bueno, esos cambian. Y esto desencadena una nueva renderización de la lista virtualizada, lo cual es normal. Básicamente, esto significa que renderItem, lo que pasas en tu renderItem, se llama enScroll. Esto es por diseño, lo que significa que debes seguir absolutamente las mejores prácticas definidas en la documentación de React Native sobre FlatList, y debes memoizar todos los elementos de tu lista. Y eso es lo que hicimos, y pasamos de esto a esto.

La gran diferencia que debes notar es esta. Básicamente, tenemos mucho gris aquí. Los elementos que memoizamos ahora no se vuelven a renderizar, y eso es lo que queremos. Todavía tenemos algunas cosas verdes arriba. Esto es básicamente la implementación interna de las listas virtualizadas, cambios de estado, etc. Por lo tanto, no podemos evitar que se rendericen, y lo que realmente es costoso aquí son los hijos, y todavía tenemos algunas cosas verdes aquí. Llegaremos a eso en un minuto, porque primero, ya tenemos algunas cosas menos verdes, tenemos algunas cosas más, quiero decir, tenemos menos cosas renderizándose, así que solo revisemos nuestra puntuación de rendimiento. Revisemos nuestras medidas, como antes en el complemento Flipper, y esto es lo que nos muestra ahora. Pasamos de 40 a 52, Chase solo está inactivo durante unos 3 segundos, y el hilo de la interfaz de usuario sigue alrededor de 60. Ok, no es fantástico, pero solo con un simple memo, hemos logrado una mejora muy buena para el rendimiento.

7. Explorando Listas Anidadas y Renderizado de Carruseles

Short description:

Sumergámonos más en las listas anidadas. Los elementos verdes en la parte inferior no son listas virtualizadas, sino carruseles horizontales implementados con carruseles Snap de React Native. Estos carruseles, junto con la lista principal, se vuelven a renderizar al desplazarse debido a un cambio de contexto. Para optimizar el rendimiento, memoizamos los elementos de las diapositivas, lo que resulta en más elementos grises en la parte inferior.

Pero vayamos más a fondo. En la segunda iteración, lo titulé La Alegría de las Listas Anidadas, y pronto entenderás por qué, porque, sí, ¿recuerdas esas cosas verdes en la parte inferior? Acerquémonos para ver qué es esto. Tenemos nuestra celda de renderizado en la parte superior, esto envuelve lo que pasamos en nuestro elemento de renderizado, luego tenemos las cosas grises, porque las memoizamos, pero aquí tenemos algo que aún se renderiza en verde. Y no es una lista virtualizada. Esto se debe a que tenemos carruseles horizontales implementados con carruseles Snap de React Native, que a su vez utiliza una lista plana. Entonces, básicamente aquí puedes ver nuestros siete carruseles que se muestran en nuestro feed de inicio, volviéndose a renderizar. ¿Pero por qué se vuelven a renderizar cuando nos desplazamos hacia abajo? Bueno, ¿recuerdas el estado, el estado de la ventana del que hablamos antes para la lista principal? Lo pasa como contexto a la lista secundaria anidada. Por lo tanto, podemos ver aquí que las listas virtualizadas se vuelven a renderizar debido a un cambio de contexto. Y esto significa que cuando nos desplazamos por la lista principal, las listas anidadas, incluso las horizontales, también se llamará al elemento de renderizado. Por lo tanto, tenemos que memoizar todo, y en nuestro caso serían los elementos de las diapositivas. Y eso es lo que hicimos, y pasamos de esto a esto. Puede ser difícil de ver, pero ahora tenemos mucho más gris en la parte inferior.

8. Optimizando el Renderizado del Carrusel

Short description:

Observamos que aparecen nuevos elementos de lista al desplazarnos hacia abajo, lo cual es esperado. Sin embargo, el excesivo renderizado resultó en una mejora mínima en el rendimiento. Tras una investigación más detallada, descubrimos que la propiedad 'loop' del carrusel Snap de React Native estaba causando que se renderizaran diapositivas adicionales. Al desactivar esta propiedad, redujimos el número de diapositivas y mejoramos significativamente el rendimiento.

Oh, tenemos algunas cosas que aparecen en el lado derecho. Podemos verificar qué es esto. Bien, en realidad se están volviendo a renderizar por primera vez, lo que significa que probablemente son nuevos elementos de lista que aparecen al desplazarnos hacia abajo. Esto está bien.

Veamos primero el excesivo renderizado. Ahora tenemos esto. Muchos elementos grises en la parte inferior. Verifiquemos más puntaje. Y pasamos de 52 a 54. Básicamente, casi lo mismo. No es una mejora muy significativa. Así que necesitamos profundizar más.

Muy bien, veamos un poco más esos carruseles. Si nos acercamos a este aquí, podemos ver que básicamente es una lista virtualizada que se vuelve a renderizar. De acuerdo con nuestro carrusel, hemos trabajado con 10 diapositivas. Espera, ¿10 diapositivas? No, en realidad nuestros carruseles solo tienen 4 diapositivas. Oh, pero eso es correcto. Agregamos la propiedad 'loop' en el carrusel Snap de React Native, lo que significa que en realidad agrega 3 diapositivas en cada diapositiva de tu carrusel al principio y al final para lograr el efecto de bucle infinito. Los más astutos habrán notado que esto suma 10. Así que decidimos desactivar esta propiedad por razones de rendimiento.

Ahora pasamos de esto a esto. Podemos ver que en efecto solo tenemos 4 diapositivas que se renderizan. Así que verifiquemos nuestro puntaje. Nuestro puntaje es mucho mejor. Hemos llegado a 70. C, GS, es solo eso por un segundo. Genial, genial. Aún está bien. Muy bien. Estamos llegando allí, pero aún no es perfecto.

9. Optimizando la Lista Virtualizada y el Carrusel

Short description:

Sumergámonos más en la lista virtualizada e identifiquemos el componente animado costoso. Al evitar la anidación de listas virtualizadas y recodificar el carrusel con una vista de desplazamiento y la propiedad 'paging enable', mejoramos significativamente el rendimiento. Nuestro puntaje ahora es de 90, sin FPS de JS en cero y una interfaz de usuario siempre receptiva. Intenta medir el rendimiento de tu aplicación, identificar y solucionar problemas, y realizar un seguimiento de las mejoras en el puntaje. ¡Gracias por ver!

Entonces, vamos aún más profundo. Haz clic en este primer carrusel, esta lista virtualizada. Podemos ver todos los elementos. Si nos acercamos al primero, esto es lo que vemos. Aquí tenemos nuestra lista virtualizada. Aún tarda 75 milisegundos en no hacer nada, básicamente. Pero notamos este componente animado en color naranja. React DevTools imprimirá, en un color diferente, como naranja aquí, los elementos que tienen un tiempo propio muy largo. Por lo tanto, son muy costosos de renderizar en comparación con sus hijos. Y este componente aquí es costoso de renderizar.

Pero, ¿de dónde viene? La parte superior aquí es del código de FlatList, de la lista virtualizada al renderizar la celda. Esta parte gris es nuestra diapositiva. Está memoizada. Entonces, aquí, esto proviene de la celda natural de React Native. En realidad, el componente animado está aquí para tener una transición genial y agradable. Pero no solo es bastante costoso de renderizar, ni siquiera está memoizado, y debería estarlo. Podríamos solucionar el código de la celda natural de React Native. O en este punto, nos damos cuenta de que la anidación de listas virtualizadas es complicada. Entonces, la pregunta es, ¿podemos evitarla? Y la respuesta es sí, porque recuerda lo que dije sobre la virtualización de forma predeterminada en React Native, mostrando el equivalente a 21 pantallas de elementos. En nuestro caso, solo tenemos cuatro elementos, por lo que la virtualización aquí para el carrusel no aporta ningún beneficio. Así que decidimos recodificarlo nosotros mismos con una vista de desplazamiento y la propiedad 'paging enable', básicamente. Y ahora solo tenemos gris aquí cuando nos desplazamos hacia abajo. Nada se vuelve a renderizar en exceso.

Verifiquemos nuestro puntaje. Ahora estamos en 90, y el JS nunca está en cero, y el hilo de la interfaz de usuario siempre está bien. ¡Lo logramos! Te animo a que lo pruebes, mide el rendimiento de tu aplicación, toma un dispositivo Android de gama baja, encuentra áreas con el complemento con FPS en cero en el lado de JS o por debajo de 60, analiza esos problemas y soluciónalos, y verifica la mejora en tu puntaje. Eso es todo. Gracias por ver, espero que hayas disfrutado de la charla. Si tienes alguna pregunta, no dudes en contactarme en Twitter o seguirme, tuiteo principalmente sobre el rendimiento de React Native. ¡Gracias!

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

JSNation 2023JSNation 2023
29 min
Modern Web Debugging
Few developers enjoy debugging, and debugging can be complex for modern web apps because of the multiple frameworks, languages, and libraries used. But, developer tools have come a long way in making the process easier. In this talk, Jecelyn will dig into the modern state of debugging, improvements in DevTools, and how you can use them to reliably debug your apps.
JSNation 2022JSNation 2022
21 min
The Future of Performance Tooling
Top Content
Our understanding of performance & user-experience has heavily evolved over the years. Web Developer Tooling needs to similarly evolve to make sure it is user-centric, actionable and contextual where modern experiences are concerned. In this talk, Addy will walk you through Chrome and others have been thinking about this problem and what updates they've been making to performance tools to lower the friction for building great experiences on the web.
DevOps.js Conf 2022DevOps.js Conf 2022
31 min
pnpm – a Fast, Disk Space Efficient Package Manager for JavaScript
You will learn about one of the most popular package managers for JavaScript and its advantages over npm and Yarn.A brief history of JavaScript package managersThe isolated node_modules structure created pnpmWhat makes pnpm so fastWhat makes pnpm disk space efficientMonorepo supportManaging Node.js versions with pnpm
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!

Workshops on related topic

React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
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.