Escala tu aplicación de React sin micro-frontends

Rate this content
Bookmark

A medida que tu equipo crece y se convierte en múltiples equipos, el tamaño de tu base de código también crece. Llegas a las 100k líneas de código y el tiempo de compilación se acerca peligrosamente a los 10 minutos 😱 Pero eso no es todo, tus verificaciones estáticas de CI (linting, cobertura de tipos, código muerto) y pruebas también están tardando cada vez más...

¿Cómo puedes mantener a tus equipos avanzando rápidamente y enviando funciones a los usuarios de manera regular si tus PRs tardan una eternidad en ser probados y desplegados?

Después de explorar algunas opciones, decidimos seguir el camino de Nx. ¡Veamos cómo migrar una gran base de código a Nx y aprovechar sus compilaciones incrementales!

21 min
21 Jun, 2022

Video Summary and Transcription

Esta charla discute cómo escalar una aplicación de React sin micro-frontends y los desafíos de una base de código en crecimiento. Se presenta Annex como una herramienta para reconstrucciones inteligentes y caché de cálculos. Se enfatiza la importancia de las bibliotecas para organizar el código y promover una arquitectura limpia. Se explora el uso de la caché, NxCloud y la compilación incremental para optimización. Se sugiere actualizar las dependencias y utilizar herramientas de perfilado para mejorar aún más el rendimiento. Se resalta la división de la aplicación en bibliotecas y los beneficios de un sistema de compilación como NX.

Available in English

1. Scaling React App Without Micro-Frontend

Short description:

Bienvenidos a mi charla sobre cómo escalar tu aplicación de React sin microfrontend. Discutiré el problema de escalar una base de código, mi experiencia para solucionarlo y lo que he aprendido en el camino. Cuando una base de código crece, el CI se vuelve más lento, lo que provoca un ciclo de retroalimentación más lento para los desarrolladores y usuarios insatisfechos. En mi caso, el tiempo de construcción llegó a más de 30 minutos, lo cual era inaceptable. Intenté sobreingenierizar el CI, pero se volvió difícil de gestionar. Luego, descubrí Annex y aprendí cómo usarlo correctamente para volver a ejecutar solo las cosas que han cambiado.

Primero, un rápido aviso legal, esta charla trata sobre la escalabilidad de tu base de código desde la perspectiva de un desarrollador y no de las actuaciones orientadas al usuario. Eso es todo para el aviso legal.

Hola de nuevo, soy Jonathan Wagner, soy gerente de ingeniería en DataUK y he estado trabajando durante los últimos 4 años en más de 10 proyectos en producción y durante los últimos 8 meses he estado trabajando con NX, que es un sistema de construcción que te ayuda a construir más rápido y hacer las cosas más rápido. Eso será el núcleo de la charla aquí. Echemos un vistazo a lo que vamos a hablar.

En primer lugar, discutiré un poco sobre el problema, qué sucede cuando escalas una base de código y luego mi experiencia para solucionarlo y lo que he aprendido en el camino, qué he intentado, qué no funcionó, qué funcionó. Así que primero, el problema. Mencioné que tener una base de código que crece significa que tu CI se vuelve un poco más lento y cuando se vuelve más lento, significa que tienes un ciclo de retroalimentación más lento, lo que significa que tus desarrolladores están insatisfechos, lleva más tiempo desarrollar funciones y al final tus usuarios están insatisfechos, lo cual definitivamente no queremos.

Entonces, cuando tu base de código crece, tienes verificación de tipos, tienes ESLint, tal vez tienes algunas pruebas de código muerto, algunas pruebas unitarias, pruebas de extremo a extremo, muchas pruebas y el tiempo de construcción y luego todo lleva un poco de tiempo y se acumula y en mi caso llevó más de 30 minutos y eso es lo que me hizo reaccionar. Idealmente quiero que mi sitio tarde 10 o 15 minutos, cuando llega a 30 minutos significa que algo ha salido terriblemente mal y quiero solucionarlo. En este caso, ni siquiera podemos ver el tiempo de construcción, simplemente se dispara, llega a 3-4 horas, lo que significa que le está costando mucho dinero a la empresa y es frustrante para todos.

Intentemos ver un ejemplo más preciso aquí, así que tenemos una base de código en crecimiento que significa que tal vez tengamos unas 800 pruebas. Imagina que tienes una solicitud de extracción donde hago un cambio de una línea, lo subes todo y el CI vuelve a ejecutar todo, lo que significa que tienes que esperar 20 minutos, tal vez 30 minutos para que las pruebas pasen. ¿Te parece normal que un cambio de una línea active 20 minutos de ejecución del CI? No lo creo. Y nx tampoco lo cree. Según la documentación de nx, en realidad dicen que la duración de la operación invocada debería ser proporcional al tamaño del cambio, y algo muy fuerte. Parece simple pero es bastante complicado de implementar. Implica un poco de almacenamiento en caché, mucho almacenamiento en caché y luego poner todo eso junto correctamente. Pero no lo sabía al principio. Así que obviamente intenté sobreingenierizar mi CI y eso significó hacer mucha paralelización, poner algunas pruebas para omitir las pruebas de frontend o backend, dependiendo de lo que se haya cambiado. Y eso significó escribir muchas reglas personalizadas, que eran complicadas e introdujeron algunas regresiones. E incluso cambiar las compilaciones de TypeScript a algo basado en Rust como swc. Y haciendo todo esto, logré algunas mejoras, llegué a 20 minutos cada una, pero eso significaba que tenía un CI complicado de gestionar. Teníamos 27 trabajos diferentes y eso significaba entender cómo todos interactuaban entre sí, cuáles eran condicionales a cuáles, y se volvió complicado de gestionar y mantener. Así que ese es el punto de partida de a dónde quería ir después. Creo que pasamos horas y horas optimizando el CI. ¿A dónde vamos desde aquí? ¿Cómo lo hacemos más rápido sin sobreingenierizarlo más? Aquí comienza el viaje. Descubriendo Annex, descubriendo un poco más sobre cómo usar Annex correctamente, cuál es el truco secreto y cómo el almacenamiento en caché pone todo junto y lo une todo.

2. Annex y el Concepto de Bibliotecas

Short description:

Annex realiza reconstrucciones inteligentes solo en las cosas que han cambiado y han sido afectadas. Utiliza caché de cálculos y te ayuda a generar cosas para que no tengas que hacerlas cada vez. El truco secreto es utilizar bibliotecas en todas partes. Una biblioteca es simplemente una carpeta donde puedes ejecutar operaciones específicas para el código que concierne. Las bibliotecas ayudan a organizar el código en la estructura de carpetas y se pueden generar fácilmente. Cuando ocurre un cambio, Annex solo prueba y vuelve a verificar los proyectos afectados, siguiendo el principio fundamental de probar solo lo que ha cambiado. Las bibliotecas también promueven una arquitectura limpia al obligar a los desarrolladores a considerar dónde colocar su código y evitar el código espagueti.

Básicamente, eso es lo que hace Annex. Realiza reconstrucciones inteligentes, solo en las cosas que han cambiado y han sido afectadas. Para eso, utiliza caché de cálculos y te ayuda a generar cosas para que no tengas que hacerlas manualmente cada vez. Básicamente, Annex ya estaba configurado en el proyecto. No lo estábamos utilizando para el sistema de construcción. Solo lo estábamos utilizando para la gestión de monoreportes. Y cuando me di cuenta de todo lo que podía hacer, eso abrió la puerta a mucho más.

Entonces, ahora que sabemos que Annex puede hacer todo esto, ¿cómo funciona en realidad? He mencionado un truco secreto. En realidad, no es tan secreto. Se anuncia en todas partes en la documentación de Annex. La idea es utilizar bibliotecas en todas partes. Puede que te preguntes, ¿qué es una biblioteca en Annex? Es simplemente una carpeta donde puedes ejecutar algunas operaciones, como pruebas, linting, básicamente cualquier cosa que desees. Se trata del código que concierne. Así que, si miramos, por ejemplo, nuestro proyecto, aquí teníamos el frontend, que era la aplicación que realmente se implementaba y utilizaban nuestros usuarios. Y luego, todo lo demás aquí abajo son bibliotecas. Entonces, la aplicación está utilizando bibliotecas. Y luego se implementa y las bibliotecas están ahí como una forma de organizar el código en la estructura de carpetas. Y lo bueno es que puedes generarlas fácilmente, por lo que es una forma común de crear una nueva y no te cuesta mucho. Y lo que también podemos ver aquí es que, en rosa, se resaltan los proyectos que han sido afectados por el cambio. Entonces, en este caso, hice un cambio en el sistema de diseño y me muestra que algunas bibliotecas y la aplicación también se han visto afectadas. Entonces, cuando ejecuto mis pruebas o cuando ejecuto el lint, solo se van a probar y verificar esos proyectos en rosa, es decir, las bibliotecas y la aplicación. No se va a tocar nada más, porque no ha cambiado. Esa es la belleza de ello. Ese es el principio fundamental. El concepto de bibliotecas puede ser un poco confuso. Así que veamos aquí lo que significa concretamente. Este es un ejemplo de repositorio de NX, donde tienes básicamente un par de aplicaciones, cards y products, y luego algunas bibliotecas. Y si nos enfocamos en las bibliotecas, en realidad es solo una configuración anidada, una configuración de jest y luego una configuración de TypeScript, y luego todo tu código fuente en la carpeta src, y es tan simple como eso. No hay mucho más, y es todo lo que necesitas para poder ejecutar tus operaciones en cada una de esas carpetas. El beneficio adicional de utilizar bibliotecas es que te obliga a tener una arquitectura limpia, porque tienes que hacerte la pregunta, ¿dónde debo poner mi código, debería ponerlo en la misma biblioteca o crear una nueva biblioteca? Es una pregunta que, al hacértela, te obliga a iniciar una discusión, pensarlo, colocarlo en el lugar correcto y te ahorra tiempo.

3. Caching, NxCloud y Incremental Build

Short description:

NX ofrece un almacenamiento en caché avanzado que analiza los archivos fuente, las operaciones y las opciones de tiempo de ejecución. Puedes colocar la caché en tu CI, pero es posible que no esté optimizada y no se pueda compartir con los desarrolladores locales. NxCloud, desarrollado por el equipo de Nx, configura fácilmente el almacenamiento en caché y la optimización de la ejecución de tareas. La compilación incremental permite reutilizar las salidas de las bibliotecas, pero tuve dificultades para lograr el rendimiento esperado. La compilación desde el origen tomaba alrededor de 60 segundos, y agregar la compilación incremental agregaba 20 segundos más. Es posible que una configuración personalizada de webpack haya afectado los resultados.

evita que el código espagueti ocurra en el futuro. Entonces, básicamente, te hace ganar tiempo solo al usar NX, pero este concepto de bibliotecas, es muy bueno decirlo así, pero para que funcione, como vimos aquí, para saber que algo ya se ha construido, necesitas almacenar esa información en algún lugar, y ahí es donde entra en juego el almacenamiento en caché. NX te proporciona un almacenamiento en caché avanzado donde analiza todos los archivos fuente, la operación que estás ejecutando, por lo que si es una prueba, tienes la clave como prueba, y puedes tener la compilación o cualquier otra cosa, la aplicación que estás construyendo o la biblioteca, y luego algunas otras opciones de tiempo de ejecución o configuraciones que tienes para React, Chest o algo más. Esto significa que NX tiene una gran tabla con una clave hash y luego la salida que se supone que debe darte en términos de archivos y en términos de salida en la consola en tu dominio. Sabiendo todo esto, sabía que había algún almacenamiento en caché. Teníamos una carpeta de caché, y pensé, ¿puedo poner la caché en mi CI y usarla así tal cual? La respuesta es sí, puedes hacerlo. Supongo que es el primer paso que puedes intentar, y significa que descargas toda la caché cada vez que haces una solicitud de extracción. En algunos casos, puede crecer y crecer hasta llegar a un gigabyte, lo que significa que lleva uno o dos minutos descargarlo y descomprimirlo, y a veces puedes pasar esos dos minutos descargando y descomprimiendo, y al final ni siquiera necesitas la caché porque no es relevante para la solicitud de extracción que tienes. No está tan optimizado y no se puede compartir con los desarrolladores locales, y puedes realizar una ejecución de tareas distribuida. Menciono todo esto porque eso es algo que hace NxCloud, por lo que NxCloud ha sido desarrollado por el equipo de Nx también y básicamente configura todo esto muy fácilmente para que solo tengas que ejecutar un comando en tu terminal. Prepara todo, no tienes que registrarte, y simplemente funciona en el CI. Funciona localmente para ti cada vez que construyes algo y otro desarrollador intenta construirlo, obtiene la misma caché porque se comparte entre los desarrolladores y optimiza el orden en el que se ejecutan las tareas para que todo sea más rápido. Básicamente, deberías usar NxCloud, tiene una característica increíble, es fácil de configurar y aporta tantos beneficios y es tan fácil de usar.

Pero hemos analizado las bibliotecas, hemos analizado el almacenamiento en caché para unir todo junto. Intentemos ver lo que he intentado y dónde realmente he tenido dificultades en todo esto. Aquí vienen las lecciones aprendidas. He jugado un poco con la compilación incremental y con intentar dividir una base de código grande existente. Veamos qué sucedió aquí. Entonces, el concepto de la compilación incremental es que deseas reutilizar las salidas de tus bibliotecas. El comportamiento inicial, como el comportamiento predeterminado, es que cuando deseas construir tu aplicación frontend, utilizas una herramienta como webpack y Babel para transformar tus archivos TypeScript en JavaScript y luego tus archivos JavaScript en otra versión de JavaScript que entienda tu navegador. Y luego realizas alguna minificación para hacerlo un poco más pequeño, alguna eliminación de árbol para eliminar lo que no utilizas y eso es básicamente todo el empaquetado que ocurre dentro de webpack para que tengas un paquete pequeño que puedas lanzar a nuevos usuarios. El nuevo comportamiento sugerido por la compilación incremental de NX, en lugar de construir todo cuando lo necesitas, construyes incrementalmente cada biblioteca. Eso significa que la primera vez que deseas construirlo, construyes todas tus dependencias y luego, cuando realizas un cambio, digamos en el sistema de diseño, reconstruyes el sistema de diseño, la interfaz de usuario, las pruebas web, el dominio frontend y reutilizas la compilación anterior de los demás y básicamente vuelves a empaquetar todo en la aplicación frontend. Se supone que es más rápido y eso es lo que NX te dice en la documentación donde muestran este gráfico donde en azul podemos ver el tiempo de construcción para una compilación normal y luego para una ejecución en frío con la compilación incremental y luego otra ejecución, esta vez en caliente, para la compilación incremental. Intenté configurar esto y no obtuve exactamente los mismos resultados. Básicamente, lo que podemos ver aquí es que para la construcción desde el origen, llevaba alrededor de 60 segundos en frío y en caliente, sin diferencias, y luego, al agregar la compilación incremental, tuve 20 segundos más. Parece un poco normal porque tengo que construir todas las bibliotecas primero, pero luego esperaba que cuando estuviera en caliente no tuviera que construir las bibliotecas, solo tendría que construir la aplicación nuevamente. Así que esperaría que esta línea aquí fuera mucho más rápida. Investigué un poco más y descubrí algunas cosas. En mi configuración, teníamos una configuración personalizada de webpack donde estábamos configurando algunos cargadores de Babel adicionales, algunos cargadores de CSS y otros. La suposición que hice es que básicamente estaba construyendo mis bibliotecas de forma independiente de antemano y luego, al construir la aplicación, estaba tomando la salida de mis bibliotecas y construyendo eso

4. Optimizando el Tiempo de Compilación y el Perfilado

Short description:

Hacer todo dos veces no proporcionó los beneficios esperados, así que exploré otras opciones. Actualizar nuestras dependencias, específicamente BrowserList, redujo significativamente el tiempo de compilación de 12 minutos a seis minutos. Además, la herramienta de perfilado de NX ayudó a identificar áreas para una mayor optimización, como dividir el sistema de diseño en dos sistemas separados.

de nuevo. Básicamente, hacer todo dos veces. De ahí los 60 segundos que teníamos aquí. Así que intenté hacer algo inteligente y simplemente excluir de la sección bubble esta carpeta, para que la salida de mi biblioteca no se construyera de nuevo, y vi algunas mejoras. Así que estamos alrededor de 15 segundos aquí entre el primer intento incremental y el segundo, lo cual es un buen comienzo, pero dado el tiempo que invertí en hacer que todas las bibliotecas sean compilables y luego entender los problemas que tuvimos con Webpack y tratar de optimizar eso, no parece una buena inversión porque básicamente pasé horas en ello, tuve errores de compilación por todas partes y no veo ningún beneficio. Estoy seguro de que mi configuración de Webpack se puede optimizar mucho mejor y puedo lograr que se parezca a lo que tiene NX, pero ¿realmente vale la pena pasar horas y horas optimizándolo más? En mi opinión, aún no, tal vez en algún momento, pero hasta ahora tenemos otras formas de acelerar nuestra compilación. Una de ellas, de hecho, que descubrimos en el camino, fue simplemente actualizar nuestras dependencias. Así que esta es como una pequeña historia divertida sobre BrowserList, que básicamente utiliza una dependencia llamada canIuse que decide qué polyfill necesita tu navegador según la versión que desees y al actualizar BrowserList, se actualizó canIuse, lo que básicamente dijo que no necesitamos esos polyfills, ya no necesitamos compilar para ES5 y eso significa que solo necesitamos compilar el formato ESM y eso redujo nuestro tiempo de compilación de 12 minutos a seis minutos, lo cual nos llevó un par de horas y nos dio beneficios mucho más rápidos que las compilaciones incrementales que mencioné antes.

Otra cosa que descubrí en el camino fue una herramienta de perfilado de NX donde puedes ver y acercarte a lo que está sucediendo detrás de escena. Así que al activar una compilación de básicamente todo, puedes ver todas las dependencias aquí y puedes ver en qué orden ocurren y qué sucede en paralelo, y puede mostrarte si deberías poner más hilos en paralelo o cuál deberías dividir. Como en este caso, podemos ver que el sistema de design es bastante grande. Toma seis segundos. Tal vez el próximo candidato para dividir en dos design systems y esta vez, podríamos tener un design system específico para los forms y otro design system para todo lo demás. Así que te brinda información sobre qué podrías refactorizar a continuación

5. División de tu Aplicación y Beneficios de un Sistema de Construcción

Short description:

Para dividir tu aplicación de manera efectiva, apunta a tener aproximadamente el 20% del código en la aplicación y el 80% en bibliotecas. Comenzar con un proyecto nuevo hace que crear bibliotecas sea fácil, pero se vuelve desafiante con un proyecto existente. Mover componentes uno por uno y actualizar las importaciones es crucial. Adapta el proceso de división a tus equipos, comenzando con una biblioteca y permitiendo que crezca. Agregar NX a un proyecto grande lleva tiempo y esfuerzo, pero vale la pena. Tener un sistema de construcción como NX alivia el dolor de refactorizar y mejora la integración continua. Comienza a dividir tu aplicación ahora para facilitar su gestión. Contáctame si tienes alguna pregunta.

y lo que podrías estar haciendo. Así que sí, una herramienta muy buena. A continuación, veremos cómo dividir tu aplicación. Mencioné tener muchas bibliotecas. Parece muy simple y fácil así, pero ¿qué tipo de proporción deberíamos buscar? NX recomienda tener aproximadamente el 20% de tu código en la aplicación y el 80% en tus bibliotecas. Lo que eso significa es básicamente poner la mayor cantidad de código posible y luego trabajar con tus bibliotecas. Es un poco como lo que haces cuando usas bibliotecas externas como npm, pero en este caso, es tu propio código que has escrito, por lo que es un poco más seguro.

Eso suena muy bien dicho así, pero ¿cómo se ve cuando realmente lo haces en tu proyecto? Digamos que tienes dos escenarios. Cuando comienzas en un proyecto, puedes crear nuevas bibliotecas muy fácilmente y tienes un comando para automatizar eso. Es muy simple. Puedes crear bibliotecas para características, para tus elementos de IU, para el acceso a datos, utilidades y tantas como desees. Podrías tener mil bibliotecas y sería muy rápido. Solo necesitas compilar una pequeña parte cuando cambias tu aplicación. Pero se vuelve mucho más difícil cuando tienes un proyecto existente.

Digamos que tienes cientos de miles de líneas y quieres comenzar a dividirlo. Intenté hacer eso, y tenía un flujo de algunas páginas que sabía que no estaba tocando y estaba probando y construyendo cada vez que hacía un cambio. Así que quería sacar eso y básicamente no probarlo de nuevo porque sabía que no cambiaría. Así que intenté hacer eso, simplemente creando una nueva biblioteca, moviendo el código a esa biblioteca. Y luego vi errores por todas partes. No se construía, no se compilaba, había importaciones de la biblioteca a la aplicación, lo que significaba que algunas cosas eran cíclicas, lo que significaba problemas en todas partes. Y me di cuenta de que si quieres dividirlo, primero debes dividir las hojas de tu árbol. Así que en lugar de mover todas las páginas, tuve que mover los componentes uno por uno primero. Y cada vez que mueves uno, debes actualizar las importaciones, arreglar todo, hacer un commit, probar, asegurarte de que todo funcione. Así que no es un trabajo simple de simplemente crear dos bibliotecas, dividir tu código en dos, y beneficiarte de NX de inmediato. Tendrás que hacerlo poco a poco. Y mi recomendación para esto es adaptarlo a tus equipos. Entonces, si tienes equipos de dominio, por ejemplo, como en la aplicación de Spotify, donde tienes podcasts, tienes radios, tienes listas de reproducción, cada uno de ellos contiene muchas características diferentes, pero el primer paso sería que cada equipo trabaje en su biblioteca, y luego podrían tener cierta superposición, podrían tener más de una biblioteca, pero la idea es que comiencen con solo una y luego mejore y crezca. Entonces sí, comenzar con un proyecto grande, agregar NX a un proyecto grande, obtienes algunos beneficios de inmediato, pero para obtener todo el poder, lleva mucho tiempo. No sucede con solo chasquear los dedos. Será mucho refactorizar, mucho esfuerzo, y mucho entrenamiento para tus equipos. Así que tenlo en cuenta. Pero si solo tienes una conclusión rápida sobre eso, tener un sistema de construcción es el siguiente paso después de optimizar tu CI. Cuando tu base de código crece, básicamente elimina el dolor de refactorizarlo y mejora tu CI. NX es un candidato muy bueno para eso. No es el único, pero en mi experiencia, ha sido un placer usarlo. Cuando tienes una aplicación grande, dividirla es difícil. Pero cuanto antes comiences, más fácil será. Mi consejo es que comiences ahora, y avísame si tienes algún problema. Gracias a todos. No dudes en contactarme si tienes alguna pregunta, y nos vemos en la sesión de preguntas y respuestas. ¡Adiós!

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 2021React Advanced Conference 2021
39 min
Don't Solve Problems, Eliminate Them
Top Content
Humans are natural problem solvers and we're good enough at it that we've survived over the centuries and become the dominant species of the planet. Because we're so good at it, we sometimes become problem seekers too–looking for problems we can solve. Those who most successfully accomplish their goals are the problem eliminators. Let's talk about the distinction between solving and eliminating problems with examples from inside and outside the coding world.
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Top Content
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
React Advanced Conference 2021React Advanced Conference 2021
47 min
Design Systems: Walking the Line Between Flexibility and Consistency
Top Content
Design systems aim to bring consistency to a brand's design and make the UI development productive. Component libraries with well-thought API can make this a breeze. But, sometimes an API choice can accidentally overstep and slow the team down! There's a balance there... somewhere. Let's explore some of the problems and possible creative solutions.
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
React 18! Concurrent features! You might’ve already tried the new APIs like useTransition, or you might’ve just heard of them. But do you know how React 18 achieves the performance wins it brings with itself? In this talk, let’s peek under the hood of React 18’s performance features: - How React 18 lowers the time your page stays frozen (aka TBT) - What exactly happens in the main thread when you run useTransition() - What’s the catch with the improvements (there’s no free cake!), and why Vue.js and Preact straight refused to ship anything similar

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
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 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Top Content
Featured WorkshopFree
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application 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 DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn
React Summit 2022React Summit 2022
136 min
Remix Fundamentals
Top Content
Featured WorkshopFree
Building modern web applications is riddled with complexity And that's only if you bother to deal with the problems
Tired of wiring up onSubmit to backend APIs and making sure your client-side cache stays up-to-date? Wouldn't it be cool to be able to use the global nature of CSS to your benefit, rather than find tools or conventions to avoid or work around it? And how would you like nested layouts with intelligent and performance optimized data management that just works™?
Remix solves some of these problems, and completely eliminates the rest. You don't even have to think about server cache management or global CSS namespace clashes. It's not that Remix has APIs to avoid these problems, they simply don't exist when you're using Remix. Oh, and you don't need that huge complex graphql client when you're using Remix. They've got you covered. Ready to build faster apps faster?
At the end of this workshop, you'll know how to:- Create Remix Routes- Style Remix applications- Load data in Remix loaders- Mutate data with forms and actions