Hablemos sobre las re-renders

Rate this content
Bookmark

React es una herramienta fantástica para implementar aplicaciones complicadas rápidamente, todos lo sabemos. Pero, ¿serán rápidas cuando se implementen rápidamente? Hablemos sobre las re-renders y su peligro en React: lo fácil que es cometer un error, por qué algunos pequeños errores pueden tener un gran impacto aguas abajo y cómo evitarlos y prevenirlos.

Esta es una charla en profundidad que se centra en por qué los componentes de React se vuelven a renderizar, qué tipo de impacto puede tener en el rendimiento y qué hacer al respecto.

23 min
17 Jun, 2022

Video Summary and Transcription

Esta charla aborda el rendimiento de React y cómo las re-renders pueden afectarlo. Se destacan errores comunes y conceptos erróneos, como el uso excesivo de los hooks useMemo y useCallback. Se enfatiza la importancia de React.memo para evitar re-renders innecesarios de los componentes hijos. Se identifica la creación de componentes en funciones de renderizado como un gran problema de rendimiento y se explican los beneficios de mover el estado hacia abajo y envolver el estado alrededor de los hijos. La charla también cubre la optimización del renderizado de componentes a través de la memorización y proporciona un resumen de los puntos clave.

Available in English

1. Introducción a React Performance y Re-renders

Short description:

Hola a todos. Mi nombre es Nadia. Soy una arquitecta de front-end, programadora y escritora. Trabajé en Atlassian y ahora soy una ingeniera fundadora en una startup llamada PIN. Hoy quiero compartir mi conocimiento sobre el rendimiento de React y cómo los re-renders lo afectan. Un re-renderizado ocurre cuando un componente actualiza sus datos. Hay tres formas de desencadenar un re-renderizado: cambio en el estado o las props, cambio en el valor del contexto y re-renderizado del componente padre. Los re-renders innecesarios pueden ralentizar la aplicación y deben evitarse.

Mi nombre es Nadia. Así que, primero un poco de introducción. Soy una arquitecta de front-end. Soy una programadora. Soy una escritora. Trabajé en Atlassian durante unos años. Trabajé en el front-end de Jira, y ahora soy una ingeniera fundadora en una pequeña startup llamada PIN en Australia.

Entonces, el tema del rendimiento de React y especialmente cómo los re-renders afectan el rendimiento de React es algo así como una pasión para mí. Me parece fascinante que solo un pequeño cambio en el lugar correcto pueda destruir por completo o mejorar enormemente el rendimiento de una aplicación enorme. Así que todo el conocimiento sobre este tema es lo que quiero compartir con ustedes hoy.

Pero primero, ¿qué es exactamente un re-renderizado y por qué queremos hablar de los re-renders en el contexto del rendimiento? En términos generales, tenemos dos etapas principales de un ciclo de vida de React en las que debemos preocuparnos. La primera es el renderizado inicial cuando una aplicación se monta por primera vez y aparece en la pantalla, y luego el re-renderizado. Un re-renderizado es el segundo y todos los consecutivos renderizados de una aplicación que ya está en la pantalla. Y desde una perspectiva de código, tenemos al menos tres formas de desencadenar el re-renderizado de un componente. La primera y más conocida es cuando cambia el estado o las props, esto hace que un componente se vuelva a renderizar. La segunda es cuando usamos un contexto, entonces cuando cambia un valor, todos los componentes que usan este valor también se volverán a renderizar. Y la tercera y más subestimada es cuando un componente padre se vuelve a renderizar o si lo vemos desde arriba, eso significa que cuando un componente se vuelve a renderizar a sí mismo, volverá a renderizar a todos los hijos que tiene. Si queremos visualizar este último, porque es el más importante, se verá algo así. Tenemos un árbol de componentes, el superior se volverá a renderizar, y luego este re-renderizado desencadenará un re-renderizado de todos los hijos allí, y luego todos los hijos debajo, por lo que será una cadena completa de re-renders que se desencadena desde arriba.

Y en términos generales, un re-renderizado en sí mismo no es algo con lo que queramos luchar porque es una parte esencial del ciclo de vida de React, es cuando React actualiza todos los datos que han cambiado. Lo que queremos evitar a toda costa son los re-renders innecesarios. Y con re-renderizado innecesario me refiero a algo como esto. Así que imagina que tenemos un componente de entrada en algún lugar de abajo, escribimos algo allí y luego este componente naturalmente se volverá a renderizar. Eso es bueno y eso es esperado. Lo que no queremos es que cuando escribimos en este pequeño componente de entrada, se vuelva a renderizar toda la aplicación. Esto, dependiendo del tamaño de la aplicación, puede ser extremadamente lento. Y en el mundo de hoy, los usuarios esperarán que todas las interacciones en la página sean realmente, realmente rápidas. Así que los re-renders innecesarios son un asesino del rendimiento.

2. Errores de rendimiento de React y hooks inútiles

Short description:

Y para demostrar lo malo que puede ser el rendimiento, implementé una aplicación que renderiza una lista de componentes. Los errores en el código hicieron que la aplicación fuera insoportablemente lenta. Un error común es el mito de useMemo y useCallback, que lleva a una aplicación llena de hooks useMemo y useCallback. Sin embargo, memoizar todo puede hacer que la aplicación sea incomprensible y no depurable. Además, envolver onClick en useCallback puede ser inútil porque los componentes secundarios aún pueden volver a renderizarse cuando el componente padre se vuelve a renderizar.

Y para demostrarles lo malo que pueden ser, incluso implementé un poco de una aplicación. Esta es una aplicación que renderiza una lista de componentes y tiene un poco de interactividad. Echen un vistazo. En la pestaña de Rendimiento, hago clic en todas partes y todo es instantáneo. En la izquierda, exactamente la misma aplicación, pero cometí un par de errores allí y vean lo increíblemente lento que es todo esto. Solo unos pocos errores pequeños en los lugares correctos y destruí por completo esta aplicación. Y es solo una lista de componentes.

Entonces, los errores comunes que conducen a un rendimiento como ese, y también consejos y trucos útiles de rendimiento para evitar el re-renderizado de toda la aplicación, es lo que quiero compartir con ustedes hoy. Comencemos con los errores. El primero de ellos es uno de mis favoritos, lo llamo el mito de useMemo y useCallback. Como probablemente la mayoría de ustedes sabe, React utiliza la igualdad referencial cuando compara props o dependencias en todos los diferentes hooks. Y la igualdad referencial es básicamente esto. Tenemos dos arrays o dos objetos. Si queremos compararlos, si lo hacemos de esta manera, el resultado será falso, porque los estamos comparando por referencia, no por el valor real.

Y desde la perspectiva de React, suena así. Tenemos un componente que renderiza un componente hijo. Paso un valor a este componente hijo que es un array. Si lo hago de esta manera, durante un re-renderizado, este valor se convertirá en un valor completamente diferente. Entonces, si React compara esas props, React pensará que el valor de la prop ha cambiado. Y si escribo hooks useMemo y useCallback, hooks que te permiten memoizar este valor y básicamente preservar la referencia a este valor entre re-renderizados. Entonces, si extraigo este array en el hook useMemo, entonces cuando ocurra un re-renderizado, React pensará que el valor en un componente hijo será exactamente el mismo. Y el hecho de que una de las razones más importantes por las que un componente se vuelve a renderizar es un cambio en el estado o en la prop, en combinación con cómo funcionan esos hooks, lleva a la creencia generalizada de que si memoizamos todas las props de un componente, eso evitará que este componente se vuelva a renderizar. Y esto resulta en algo que llamo el infierno de los hooks useMemo o useCallback, porque memoizar absolutamente todo hace que tu aplicación esté llena de useMemo, que envuelves en useCallback, y luego otro useCallback, es solo useMemo y useCallback por todas partes, y la aplicación se vuelve incomprensible y completamente ilegible y no depurable. Así que creo que eso se vuelve realmente horrible.

Pero la peor parte de todo esto es que a veces es realmente inútil, porque estamos olvidando un componente clave en toda esta construcción. Si echamos un vistazo, por ejemplo, a este código, vemos un componente que tiene un componente hijo y luego onClick, Prop, y queremos evitar que los componentes secundarios se vuelvan a renderizar envolviendo onClick en el hook useCallback. Pero ¿qué puede desencadenar exactamente que los componentes secundarios se vuelvan a renderizar? Hemos evitado los cambios en Prop. Lo único que queda es cuando un componente padre se vuelve a renderizar. Entonces, desencadenaremos un estado, por ejemplo, un componente hijo se volverá a renderizar y React en realidad no verificará si Prop ha cambiado o no en esta etapa, porque la forma natural de React de lidiar con los componentes es que los componentes se vuelven a renderizar y luego se vuelven a renderizar cada uno de los componentes secundarios. Envolver onClick aquí en useCallback es completamente inútil, no estamos haciendo nada aquí.

3. Evitando el re-renderizado de componentes secundarios

Short description:

La única forma de evitar que el componente secundario se vuelva a renderizar cuando el componente padre se vuelve a renderizar es envolverlo en React.memo. Y solo en este escenario, cuando un componente padre se vuelve a renderizar, se detendrá el re-renderizado de este componente secundario. En este caso, el componente React se detendrá y luego comenzaremos a comparar todas las props con el valor anterior, y si todas son iguales, entonces no se volverá a renderizar nada.

La única forma de evitar que el componente secundario se vuelva a renderizar cuando el componente padre se vuelve a renderizar es envolverlo en React.memo. Y solo en este escenario, cuando un componente padre se vuelve a renderizar, se detendrá el re-renderizado de este componente secundario. En este caso, el componente react se detendrá y luego comenzaremos a comparar todas las props con el valor anterior, y si todas son iguales, entonces no se volverá a renderizar nada. Desde la perspectiva del código, cuando solo tenemos el componente secundario y luego un useCallback que envuelve una prop, es inútil. No hace nada. Solo consume un poco de potencia computacional. Debería ser algo como esto, o simplemente recordar usar useCallback envuelto en React.memo, y solo entonces useCallback será realmente útil.

4. Creación de componentes en funciones de renderizado

Short description:

Crear componentes en funciones de renderizado es un gran problema de rendimiento en aplicaciones de React. Cuando los componentes se crean dentro de un componente padre, React los recrea desde cero durante cada renderizado del componente padre. Esto no solo ralentiza la aplicación, sino que también causa parpadeos visibles en la pantalla e introduce errores con el enfoque. La solución es crear componentes de elementos fuera de los componentes grandes y evitar crear componentes en línea.

Segundo error, y este es el mayor problema de rendimiento en aplicaciones de React. Crear componentes en funciones de renderizado. Nuevamente, recuerda la aplicación. La aplicación es solo una lista. La aplicación acepta países como una propiedad y luego iteramos sobre esos países y renderizamos algo. En la vida real, obviamente queremos que este botón tenga algunos estilos, tenga alguna funcionalidad, por lo que en la vida real querría extraer este botón y convertirlo en un componente. Y lo que la gente suele hacer es extraerlo como un componente y crearlo dentro de este mismo componente, lo crea dentro de un componente padre. Por lo general, la razón de esto es que es mucho más fácil pasar datos adicionales a él que se derivan del estado, pero aún así. Pero cuando hacemos algo como esto, durante cada renderizado del componente de la lista grande, React recreará el componente del elemento por completo desde cero. React simplemente desmontará todo lo que ya está renderizado y luego volverá a montar todos esos componentes de la lista. Esto no solo será realmente, realmente lento, el montaje es dos veces más lento que solo un renderizado. También será visible en la pantalla, porque lo que sucederá es que un componente de lista con elementos, renderizará. React pensará que todos los elementos creados dentro de la lista son un nuevo componente ahora, por lo que destruirá todos esos elementos, los eliminará de la pantalla y luego los volverá a crear. A veces veremos un parpadeo visible en la pantalla. Y también numerosos errores con el enfoque. Entonces, la forma de solucionar esto, por supuesto, es simplemente nunca hacer algo como esto y crear componentes de elementos fuera de los componentes grandes, nunca crear componentes en línea.

5. Context Provider and Moving State Down

Short description:

El tercer error que causa renderizados de errores espontáneos e imperceptibles es el proveedor de contexto. Cuando cambia un valor de contexto, React necesita volver a renderizar cada componente que utiliza ese valor. Para solucionar esto, siempre usa memo en el valor de contexto. Otro truco para evitar renderizados innecesarios es el patrón llamado Mover el estado hacia abajo. Al extraer el estado en un componente separado, solo los hijos necesarios se volverán a renderizar cuando se actualice el estado.

Tercer error que probablemente sea la fuente más importante de todos esos renderizados de errores espontáneos e imperceptibles en toda la aplicación es el proveedor de contexto. Entonces, el contexto es una herramienta realmente útil cuando necesitamos pasar algunos datos y evitar el encadenamiento de props. Con el contexto, podemos hacer esto. Podemos simplemente omitir todos los componentes intermedios y pasar los datos desde el componente superior al componente inferior. Sin contexto, lo que tendríamos que hacer es pasar los datos a través de cada componente individual entre el superior y el inferior, lo que hará que todos los componentes intermedios exploten con props y datos innecesarios y se conviertan en una pesadilla de refactorización en seis meses.

Pero hay un problema con el contexto. Cuando cambia un valor de contexto, React también necesita actualizar todo lo que utiliza ese valor de contexto. Y eso significa que React necesita volver a renderizar cada componente que utiliza el valor de contexto. Desde una perspectiva de codificación, se ve algo como esto. Tenemos un componente, tenemos un proveedor de contexto y necesitamos pasar el valor allí. ¿Qué sucederá si este componente se vuelve a renderizar por alguna razón? Recuerda, igualdad diferencial. Tenemos un objeto que pasamos al proveedor de contexto. El componente se vuelve a renderizar. React piensa que el objeto es un objeto diferente. Cambia, piensa que cambia un valor y luego volverá a renderizar innecesariamente cada componente que utiliza este contexto. La forma de solucionarlo sería simplemente usar siempre memo en este valor. Diría que este es uno de los casos muy raros de optimización prematura que realmente quieres, porque depurar los renderizados que ocurren debido a los cambios en el contexto es una pesadilla.

Ok. Ahora dejemos de deprimirnos por los errores y hablemos un poco sobre los trucos reales. Uno de los más importantes en tu arsenal contra renderizados innecesarios es el patrón llamado Mover el estado hacia abajo. Si observamos el código, tenemos un componente que renderiza muchas cosas, es muy pesado y en algún momento implementamos un botón allí, hacemos clic en el botón y se abre un cuadro de diálogo. Una funcionalidad muy simple en toda esta implementación. ¿Qué sucederá en este gran componente desde la perspectiva de los renderizados? Hacemos clic en un botón, actualizamos el estado y luego todo esto se vuelve a renderizar, porque cuando se actualiza el estado, cada hijo en el componente se volverá a renderizar. Y, por supuesto, algo así será realmente, realmente lento. Si es una aplicación muy grande, hacer clic en un botón y luego abrir un cuadro de diálogo podría causar un retraso visible, porque React necesita volver a renderizar todo antes de abrir realmente el cuadro de diálogo. Nuestros usuarios estarán muy decepcionados. La forma de solucionarlo es lo que se llama mover el estado hacia abajo. Este estado está bastante separado de la funcionalidad real de esta gran aplicación, por lo que podemos hacer es extraer todo esto y envolverlo en un componente en sí mismo. Y luego usarlo de nuevo en este gran componente. Entonces, desde la perspectiva de los renderizados, ¿qué sucederá? Hacemos clic en un botón, se actualiza el estado, los hijos se vuelven a renderizar, pero en este caso los hijos son solo un botón y un cuadro de diálogo.

6. Optimizando el Renderizado de Componentes

Short description:

El componente grande simplemente estará ahí sin hacer nada. Eso es exactamente lo que queremos. Y la apertura del diálogo será ahora lo más rápido posible. Envolver el estado alrededor de los hijos es otro patrón que no se aprecia lo suficiente y es poco conocido. Es similar a mover el estado hacia abajo. Cuando escuchamos un evento de desplazamiento, podemos extraer el estado fuera del div de envoltura y crear un nuevo componente. De esta manera, el componente hijo no se vuelve a renderizar, lo que hace que la aplicación sea más rápida. Otra técnica es memorizar parte del flujo de renderizado, donde se puede memoizar un gran fragmento del flujo que no depende del estado.

El componente grande simplemente estará ahí sin hacer nada. Eso es exactamente lo que queremos. Y la apertura del diálogo será ahora lo más rápido posible.

El segundo patrón, y probablemente el más subestimado de la serie, y también el menos conocido, es envolver el estado alrededor de los hijos. Es un poco similar a mover el estado hacia abajo. Entonces, nuevamente, tenemos un componente. En este caso, por ejemplo, queremos escuchar un evento de desplazamiento. Lo que haremos aquí, desde una perspectiva de volver a renderizar, es que el usuario se desplaza. Esto desencadena actualizaciones de estado. Se desencadena una actualización. Eso provoca un volver a renderizar de todo el componente grande. Y nuevamente, todo se vuelve a renderizar. Pero en este caso, no podemos simplemente mover el estado afuera porque este div realmente envuelve todo el componente. Pero lo que podemos hacer es extraerlo de todos modos, crear un nuevo componente con todo esto y luego pasar todo lo que estaba entre esos divs como hijos.

¿Qué sucederá aquí desde una perspectiva de volver a renderizar y cómo usarlo? Ahora, nos desplazamos. Desencadenamos una actualización de estado. Se desencadena una actualización. Provoca volver a renderizar. El componente de desplazamiento se vuelve a renderizar a sí mismo. Pero todo lo que está aquí dentro pertenece al padre. El componente hijo no sabe nada de todo esto. Desde la perspectiva del componente de desplazamiento, todo esto es solo una propiedad. Todo esto no se volverá a renderizar. Ahora esta aplicación vuelve a ser lo más rápida posible, sin ninguna memorización, sin nada.

Y por último, pero no menos importante, memorizar parte del flujo de renderizado. Entonces, cuando tienes un componente grande, usas algo de estado aquí y allá. Pero no puedes mover el estado hacia abajo ni envolverlo alrededor de los hijos, porque está disperso por toda la aplicación. Pero también, si quieres mejorar el rendimiento de esta aplicación un poco, y tienes un gran fragmento del flujo que no depende del estado, lo que puedes hacer es simplemente memoizar todo este flujo. En este caso, nuevamente, se desencadena una actualización, se desencadena un volver a renderizar, no hay dependencia en esta memoización, por lo que useMemo simplemente devolverá exactamente el mismo valor que antes.

QnA

Resumen de Rendimiento de React y Preguntas y Respuestas

Short description:

No actualizará nada. Siempre memoiza los valores en el proveedor de contexto. Envolver el estado hacia abajo y envolver el estado alrededor de los hijos son las herramientas más importantes en tu lucha contra los re-renderizados innecesarios. Si ninguna de estas opciones es posible por alguna razón, también puedes memoizar partes costosas de la cadena de renderizado. Si quieres leer un poco más sobre todo esto o probar la aplicación mala y la aplicación buena, aquí están los enlaces. Siéntete libre de hacerlo. Pasemos a algunas preguntas. ¿Qué sucederá si pasamos el objeto a un componente hijo que se exporta con React.memo? Si un componente hijo está envuelto en React.memo y simplemente lo estamos renderizando, entonces debemos memoizar este objeto. De lo contrario, si el objeto no se memoiza, el componente envuelto en React.memo seguirá siendo renderizado.

No actualizará nada. Y el rendimiento de esta gran aplicación seguirá siendo mucho mejor que sin esto.

Esa fue mucha información, espero que al menos hayas encontrado algo útil. Un pequeño resumen para todos. Si no estás utilizando useMemo y useCallback de la manera correcta, que es envolver los componentes en React.memo y memoizar cada uno de ellos, se vuelven inútiles. Puedes simplemente eliminarlos. Crear componentes dentro de funciones de renderizado es el mayor asesino de rendimiento. Nunca lo hagas. Debería ser tu mantra. Siempre memoiza los valores en el proveedor de contexto. Eso evitará que los consumidores de contexto de React se vuelvan a renderizar innecesariamente. Envolver el estado hacia abajo y envolver el estado alrededor de los hijos son las herramientas más importantes en tu lucha contra los re-renderizados innecesarios. Si ninguna de estas opciones es posible por alguna razón, también puedes memoizar partes costosas de la cadena de renderizado.

Si quieres leer un poco más sobre todo esto o probar la aplicación mala y la aplicación buena, aquí están los enlaces. Siéntete libre de hacerlo. Escribo mucho sobre todos estos temas y diferentes patrones en mi blog. No dudes en contactarme en Twitter o LinkedIn. Siempre estoy feliz de charlar y responder preguntas. ¡Gracias! Muchas gracias Nadia, esa fue una charla realmente increíble. Tuve que tomar una foto de esa diapositiva al final, porque hay algunas de esas conclusiones que quiero asegurarme de usar yo mismo.

Pasemos a algunas preguntas. Si estás en la audiencia y tal vez te vas rápidamente a otra charla, está bien. Mantengamos el ruido bajo para que podamos escuchar todas estas preguntas, incluso en la parte de atrás. Muy bien, vamos directo a ello. ¿Qué sucederá si pasamos el objeto a un componente hijo que se exporta con React.memo? No estoy seguro de haberlo leído correctamente. Si un componente hijo está envuelto en React.memo, supongo, y simplemente lo estamos renderizando, entonces debemos memoizar este objeto. De lo contrario, si el objeto no se memoiza, el componente envuelto en React.memo seguirá siendo renderizado. Tiene sentido. Tiene sentido.

React memo y Renderizado de Componentes Hijos

Short description:

React memo con el componente hijo no es el comportamiento predeterminado para renderizar componentes hijos. Memoizar todo puede hacer que la aplicación sea ligeramente más lenta, aumentando la renderización inicial. Puede o no ahorrarte re-renderizados.

Y una cosa, esto también es algo que me vino a la mente. ¿Por qué React memo con el componente hijo no es simplemente el comportamiento predeterminado para renderizar componentes hijos? Porque tiene mucho sentido usarlo de esa manera. Tiene mucho sentido. Pero según lo que sé, el equipo de React, no formo parte de él, solo uso internet. Experimentaron haciendo exactamente eso durante la construcción. Pero memoizar todo también tiene sus costos. Entonces, si memoizas todo, podría hacer que tu aplicación sea ligeramente más lenta. Porque nuevamente, si todo está envuelto en React memo, pero no estás envolviendo todo en el memo y el callback utilizado, esos son inútiles, pero aún estás haciendo cosas durante eso. Entonces puede aumentar tu renderización inicial. Puede o no ahorrarte re-renderizados, pero definitivamente aumentará tu renderización inicial. También tiene sentido. Y otra pregunta que tenemos, ¿está bien renderizar un componente incluso si no es visible o está abierto por defecto? Bueno, depende. En mi cabeza, también estaba pensando que a veces sí y a veces no, pero ¿tienes algún tipo de pensamiento o perspectiva sobre la respuesta? Por ejemplo, para los diálogos de modelo, si quieres que aparezcan suavemente, tendrías que renderizarlos de antemano un poco. Entonces está ahí pero invisible y luego aparece. Ese es el caso en el que querrías renderizarlo, pero aún es invisible. Eso tiene sentido. Eso tiene sentido. Creo que es todas las preguntas que tenemos. ¿Hay alguna más? ¿Tal vez haya algunas que me haya perdido? Asegúrate de seguir haciendo tus preguntas. Puedes unirte a Slido en 1721. Y si tienes más preguntas, tal vez quieras profundizar, puedes encontrar a Nadia en la sala de discusión de los oradores justo en la esquina. Muy bien, muchas gracias, Nadia. Demos un aplauso má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 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
Top Content
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Top Content
Remix is a new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
React Advanced Conference 2023React Advanced Conference 2023
33 min
React Compiler - Understanding Idiomatic React (React Forget)
React provides a contract to developers- uphold certain rules, and React can efficiently and correctly update the UI. In this talk we'll explore these rules in depth, understanding the reasoning behind them and how they unlock new directions such as automatic memoization. 
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 Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Too much JavaScript is getting you down? New frameworks promising no JavaScript look interesting, but you have an existing React application to maintain. What if Qwik React is your answer for faster applications startup and better user experience? Qwik React allows you to easily turn your React application into a collection of islands, which can be SSRed and delayed hydrated, and in some instances, hydration skipped altogether. And all of this in an incremental way without a rewrite.
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Top Content
Concurrent React and Server Components are changing the way we think about routing, rendering, and fetching in web applications. Next.js recently shared part of its vision to help developers adopt these new React features and take advantage of the benefits they unlock.In this talk, we’ll explore the past, present and future of routing in front-end applications and discuss how new features in React and Next.js can help us architect more performant and feature-rich applications.

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 Advanced Conference 2021React Advanced Conference 2021
132 min
Concurrent Rendering Adventures in React 18
Top Content
Featured WorkshopFree
With the release of React 18 we finally get the long awaited concurrent rendering. But how is that going to affect your application? What are the benefits of concurrent rendering in React? What do you need to do to switch to concurrent rendering when you upgrade to React 18? And what if you don’t want or can’t use concurrent rendering yet?

There are some behavior changes you need to be aware of! In this workshop we will cover all of those subjects and more.

Join me with your laptop in this interactive workshop. You will see how easy it is to switch to concurrent rendering in your React application. You will learn all about concurrent rendering, SuspenseList, the startTransition API and more.
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