Hablemos de Re-renderizados

Rate this content
Bookmark

React es una herramienta fantástica para implementar aplicaciones complicadas rápidamente, todos lo sabemos. Pero, ¿van a ser rápidas cuando se implementan rápidamente? Hablemos de re-renderizados y su peligro en react: lo fácil que es cometer un error, por qué algunos errores pequeños pueden tener un efecto enorme aguas abajo, y cómo evitarlos y prevenirlos.

Este es un tipo de charla de inmersión profunda, que se centra en por qué los componentes de React se re-renderizan, qué tipo de impacto de rendimiento puede tener, y qué hacer al respecto

Nadia Makarevich
Nadia Makarevich
23 min
17 Jun, 2022

Comments

Sign in or register to post your comment.

Video Summary and Transcription

Esta charla discute el rendimiento de React y cómo los re-renderizados pueden afectarlo. Destaca errores comunes y conceptos erróneos, como el uso excesivo de los hooks useMemo y useCallback. Se enfatiza la importancia de React.memo en la prevención de re-renderizados innecesarios de componentes hijos. La creación de componentes en funciones de renderizado se identifica como un gran asesino del 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 al rendimiento de React y las re-renderizaciones

Short description:

Hola a todos. Mi nombre es Nadia. Soy una arquitecta de front-end, programadora y escritora. He trabajado en Atlassian y ahora soy ingeniera fundadora en una startup llamada PIN. Hoy, quiero compartir mis conocimientos sobre el rendimiento de React y cómo las re-renderizaciones lo afectan. Una re-renderización es cuando un componente actualiza sus datos. Hay tres formas de desencadenar una re-renderización: cambio de estado o props, cambio de valor de contexto y re-renderización del componente padre. Las re-renderizaciones innecesarias pueden ralentizar la aplicación y deben evitarse.

Hola a todos. Mi nombre es Nadia. Entonces, primero una pequeña introducción. Soy una arquitecta de front-end. Soy programadora. Soy escritora. Trabajé en Atlassian durante algunos años. Así que trabajé en el front-end de Jira, y ahora soy una ingeniera fundadora en una pequeña startup que se llama PIN en Australia.

Entonces, el tema del rendimiento de React y especialmente cómo las re-renderizaciones afectan el rendimiento de React es algo así como una pasión mía. Me parece fascinante que solo un pequeño cambio en el lugar correcto puede destruir completamente o mejorar enormemente el rendimiento de una gran aplicación. Entonces, todo el conocimiento sobre este tema es lo que quiero compartir con ustedes hoy.

Pero primero, ¿qué es exactamente una re-renderización y por qué queremos hablar de re-renderizaciones en el contexto del rendimiento. En general, tenemos dos etapas principales del ciclo de vida de React que necesitamos cuidar. La primera es la renderización inicial cuando una aplicación se monta por primera vez y aparece en la pantalla, y luego la re-renderización. Una re-renderización es la segunda y todas ellas, todas las renderizaciones consecutivas de una aplicación que ya está en la pantalla. Y desde una perspectiva de código, tenemos al menos tres formas de desencadenar una re-renderización de un componente. La primera es la más conocida, es cuando un estado o props cambian, es cuando un componente será re-renderizado. La segunda es si usamos un contexto, entonces cuando un valor cambia, cada componente que usa este valor también se re-renderizará. Y la tercera y más subestimada es cuando un componente padre se re-renderiza o si miramos desde arriba, eso significa que cuando un componente se re-renderiza a sí mismo, re-renderizará a cada uno de sus hijos. Si queremos visualizar el último, porque es el más importante, se verá algo así. Tenemos un árbol de componentes, el de arriba se re-renderizará, y luego esta re-renderización desencadenará una re-renderización de todos los hijos allí, y luego todos los hijos debajo, por lo que será una cadena completa de re-renderizaciones que se desencadenan desde arriba.

Y en general, una re-renderización en sí no es algo con lo que querríamos 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 las re-renderizaciones innecesarias. Y por re-renderización innecesaria, me refiero a algo así. Así que imagina que tenemos un componente de entrada en algún lugar en la parte inferior, escribimos algo allí, y entonces este componente naturalmente se re-renderizará a sí mismo. Eso está bien, y eso es lo esperado. Lo que no queremos es que cuando escribimos en este pequeño componente de entrada, se re-renderice 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. Por lo tanto, las re-renderizaciones innecesarias 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, memorizar 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 hijos 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. Así que esta es una aplicación que renderiza una lista de componentes, y tiene un poco de interactividad. Así que echen un vistazo. A la derecha, la pestaña Performance, hago clic en todas partes, y todo es instantáneo. A la izquierda, exactamente la misma aplicación, pero cometí un par de errores allí, y miren lo insoportablemente lenta que es todo esto. Solo unos pocos errores pequeños en los lugares correctos, y acabo de destruir esta aplicación. Y es solo una lista de componentes.

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

Y desde la perspectiva de React, suena así. Tenemos un componente, renderiza un componente hijo. Paso un valor a este componente hijo que es un array. Si lo hago así, durante una re-renderización, 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 memo y uso callback, hooks que te permiten memorizar este valor, y básicamente para preservar la referencia a este valor entre re-renderizaciones. Entonces, si extraigo este array en el hook useMemo, entonces cuando ocurre una re-renderización, 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 re-renderiza es un cambio de estado o prop, en combinación con cómo funcionan esos hooks, lleva a la creencia generalizada de que si memorizamos todas las props en un componente, eso evitará que este componente se re-renderice. Y esto resulta en algo que llamo un infierno de hooks useMemo o useCallback, porque memorizar absolutamente todo lleva a que tu aplicación se convierta, teniendo useMemo, envuelves en useCallback, y luego otro useCallback, es solo useMemo y useCallbacks en todas partes, y la aplicación se vuelve incomprensible y completamente ilegible y no depurable. Así que creo que estos se vuelven realmente horribles.

Pero la peor parte de todo esto es que en realidad a veces, es inútil, porque estamos olvidando un componente clave en toda esta construcción. Entonces, si echamos un vistazo, por ejemplo, a este code, vemos un componente, tiene un componente hijo y luego onClick, Prop, y queremos evitar que el componente hijo se re-renderice envolviendo onClick en un hook useCallback. Pero, ¿qué puede exactamente desencadenar que los componentes hijos se re-rendericen? Evitamos los cambios de Prop. Lo único que queda es cuando un componente padre se re-renderiza. Entonces, activaremos un estado, por ejemplo, un componente hijo se re-renderizará, y React en realidad no comprobará si Prop ha cambiado o no en esta etapa, porque la forma natural de React de tratar con los componentes es que los componentes se re-renderizan, y luego re-renderizan cada uno de los hijos. Envolver onClick aquí en useCallback es simplemente completamente inútil, no estamos haciendo nada aquí.

3. Previniendo la Re-renderización de Componentes Hijos

Short description:

La única forma de prevenir que el componente hijo se re-renderice cuando el componente padre se re-renderiza es envolviéndolo en React.memo. Y solo en este escenario, cuando un componente padre se re-renderiza, se detendrá la re-renderización de este hijo. 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 nada se re-renderizará.

La única forma de prevenir que el componente hijo se re-renderice cuando el componente padre se re-renderiza es envolviéndolo en React.memo. Y solo en este escenario, cuando un componente padre se re-renderiza, la re-renderización de este hijo se detendrá. 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 nada se re-renderizará. Entonces, desde la perspectiva de code, esto, cuando solo tenemos el componente hijo, y luego un useCallback que es, envuelve una Prop, es inútil. No hace nada. Solo consume un poco de poder computacional. Debería ser algo así, o simplemente recordar useCallback. envuelto en React.memo, y entonces, y solo entonces, un useCallback será realmente útil.

4. Creando Componentes en Funciones de Renderizado

Short description:

Crear componentes en funciones de renderizado es un gran asesino del rendimiento en las aplicaciones de React. Cuando los componentes se crean dentro de un componente padre, React los recrea desde cero durante cada re-renderizado del componente padre. Esto no solo ralentiza la aplicación, sino que también causa destellos 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 asesino del performance en las aplicaciones de React. Creando componentes en funciones de renderizado. De nuevo, recuerda la aplicación. La aplicación es solo una lista. Las aplicaciones, acepta países como una prop, y luego iteramos sobre esos países y renderizamos algo. En la vida real, obviamente querríamos que este botón tenga algunos estilos, tenga alguna funcionalidad, así que en la vida real querría extraer este botón y convertirlo en un componente. Y lo que la gente a menudo hace es que lo extrae como un componente y lo crea dentro de este exacto 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 data adicional a él que se deriva del estado, pero aún así. Pero cuando hacemos algo así, durante cada re-renderizado del componente de lista grande, React recreará el componente de elemento completamente desde cero. React simplemente desmontará todo lo que ya está renderizado y luego volverá a montar todos esos componentes de lista. Esto no solo va a 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 un componente de lista con elementos, listas de renderizados. React pensará que todo el elemento creado dentro de la lista es un nuevo componente ahora, por lo que destruirá todos esos elementos, los eliminará de la pantalla y luego los recreará. A veces veremos un destello 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 así, y simplemente crear componentes de elementos fuera de los componentes grandes, nunca crear componentes en línea.

5. Proveedor de Contexto y Moviendo el Estado Hacia Abajo

Short description:

El tercer error que causa renders de error espontáneos e imperceptibles es el proveedor de contexto. Cuando un valor de contexto cambia, React necesita volver a renderizar cada componente que usa ese valor. Para solucionar esto, siempre use memo en el valor del contexto. Otro truco para prevenir rerenders innecesarios es el patrón llamado Moviendo el Estado Hacia Abajo. Al extraer el estado en un componente separado, solo los hijos necesarios volverán a renderizar cuando se actualice el estado.

El tercer error que probablemente es la fuente más importante de todos esos renders de error 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 data y evitar el trilling de props. Entonces, con el contexto, podemos hacer esto. Podemos simplemente escapar de todos los componentes intermedios y pasar data desde el componente superior al componente inferior. Sin contexto, lo que tendríamos que hacer es pasar data 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 data innecesarios y se conviertan en una pesadilla de refactorización en seis meses.

Pero hay una advertencia con el contexto. Cuando un valor de contexto cambia, React también necesitará actualizar todo lo que está usando el valor del contexto. Y eso significa que React necesita volver a renderizar cada componente que usa el valor del contexto. Y desde una perspectiva de codificación, se ve algo así. Tenemos un componente, tenemos un proveedor de contexto, y necesitamos pasar un 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 un valor cambia, y luego volverá a renderizar innecesariamente cada componente individual que usa este contexto. Y la forma de solucionarlo sería simplemente usar memo en este valor siempre. Diría que este es uno de los casos muy prematuros de optimization que realmente quieres, porque debugging rerenders que están sucediendo debido a los cambios en el contexto es simplemente una pesadilla para hacer.

Bueno. Entonces, dejemos de deprimirnos por los errores y hablemos un poco sobre los trucos reales. Uno de los más importantes en tu arsenal contra los rerenders innecesarios es el patrón que se llama Moviendo el Estado Hacia Abajo. Entonces, si miramos el code, tenemos un componente, renderiza muchas cosas, es muy pesado, y en algún momento implementamos un botón allí, hacemos clic en el botón, se abre un diálogo de modelo. Funcionalidad súper simple esta implementación completa. Entonces, ¿qué sucederá en este gran componente desde la perspectiva de rerender? 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 como esto va a ser realmente, realmente lento. Si es una aplicación realmente grande, hacer clic en un botón y luego abrir un diálogo de modelo podría causar un retraso visible, porque React necesita volver a renderizar todo primero antes de abrir realmente el diálogo. Nuestros usuarios estarán muy decepcionados. La forma de solucionarlo es lo que se llama moviendo el estado hacia abajo. Este estado está bastante separado de la funcionalidad real de esta gran aplicación, entonces, lo que podemos hacer es simplemente extraer todo esto y envolverlo en un componente en sí. Y luego usarlo de nuevo en este gran componente. Entonces, ahora desde la perspectiva de ReRender, ¿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 diálogo de modelo.

6. Optimizando la Renderización de Componentes

Short description:

El gran componente simplemente se quedará allí y no hará nada. Eso es exactamente lo que queremos. Y la apertura del diálogo será ahora lo más rápida posible. Envolver el estado alrededor de los hijos es otro patrón que está infravalorado y es el menos conocido. Es similar a mover el estado hacia abajo. Al escuchar un evento de desplazamiento, podemos extraer el estado fuera del div envolvente y crear un nuevo componente. De esta manera, el componente hijo no se vuelve a renderizar, haciendo la aplicación más rápida. Otra técnica es memorizar parte de la secuencia de renderización, donde un gran fragmento de la secuencia que no depende del estado puede ser memorizado.

El gran componente simplemente se quedará allí y no hará nada. Eso es exactamente lo que queremos. Y la apertura del diálogo será ahora lo más rápida posible. El segundo patrón y probablemente este es el patrón más infravalorado de la serie y también el menos conocido. Eso es envolver el estado alrededor de los hijos. Es un poco similar a mover el estado hacia abajo. Entonces, de nuevo, tenemos un componente. En este caso queremos, por ejemplo, escuchar un evento de desplazamiento. Entonces, lo que haremos aquí, desde una perspectiva de re-renderización de nuevo, el usuario se desplaza. Estamos activando actualizaciones de estado. Se activa la actualización. Eso provoca una re-renderización de todo el gran componente. Y de nuevo, todo se vuelve a renderizar. Pero en este caso, no podemos simplemente mover el estado fuera porque este div está realmente envolviendo todo el componente. Pero lo que podemos hacer es que aún podemos extraerlo fuera, crear un nuevo componente de todo esto, y luego pasar todo lo que estaba entre esos divs como hijos.

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

Y por último, pero no menos importante, memorizando parte de la secuencia de renderización. Entonces, cuando tienes un gran componente, usas un poco de estado aquí y allá. Pero no puedes mover un estado hacia abajo ni simplemente envolverlo alrededor de los hijos, porque está simplemente disperso por la aplicación. Pero también, si quieres mejorar el performance de esta aplicación un poco, y tienes un gran fragmento de la secuencia que no depende del estado, lo que puedes hacer es simplemente memorizar toda esta secuencia. En este caso, de nuevo, se activa la actualización, se activa la re-renderización, no hay dependencia en este memo, así que useMemo simplemente devolverá exactamente el mismo valor que había antes.

QnA

Resumen de Rendimiento de React y Preguntas y Respuestas

Short description:

No actualizará nada. Siempre memoriza 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 las re-renderizaciones innecesarias. Si ambos no son posibles por alguna razón, también puedes memorizar partes costosas de la cadena de renderización. Si quieres leer un poco más sobre todo esto, o jugar con la mala aplicación y la buena aplicación, 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 necesitamos memorizar este objeto. De lo contrario, si el objeto no está memorizado, el componente que está envuelto en React memo seguirá siendo renderizado.

No actualizará nada. Y el performance de esta gran aplicación todavía será mucho mejor que sin esto.

Eso fue mucha información, espero que hayas encontrado al menos algo útil. Un pequeño resumen para todos. Si no estás usando useMemo y useCallbacks de la manera correcta, que es atrapar el componente en react.memo y memorizar cada uno de ellos, se vuelven inútiles. Puedes simplemente eliminarlos. Crear componentes dentro de las funciones de renderizado es el mayor asesino del performance. Nunca lo hagas. Debería ser tu mantra. Siempre memoriza 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 las re-renderizaciones innecesarias. Si ambos no son posibles por alguna razón, también puedes memorizar partes costosas de la cadena de renderización.

Si quieres leer un poco más sobre todo esto, o jugar con la mala aplicación y la buena aplicación, aquí están los enlaces. Siéntete libre de hacerlo. Escribo mucho sobre todas estas cosas y todos los diferentes patterns en mi blog. Siéntete libre de conectarte conmigo en Twitter o LinkedIn. Siempre feliz de charlar y responder preguntas. ¡Gracias! Muchas gracias Nadia, 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 que estoy usando yo mismo.

Pasemos a algunas preguntas. Si estás en la audiencia y tal vez te estás yendo rápidamente a otra charla, eso es totalmente aceptable. Mantengamos el ruido bajo para que podamos escuchar todas estas preguntas, incluso en la parte de atrás. Bien, vamos directamente a ello. ¿Qué sucederá si pasamos el objeto a un componente hijo, que se exporta con React memo? No estoy seguro si he leído eso correctamente. Si un componente hijo está envuelto en React memo, supongo, y simplemente lo estamos renderizando entonces necesitamos memorizar este objeto. De lo contrario, si el objeto no está memorizado, el componente que está envuelto en React memo seguirá siendo renderizado. Porque React piensa que las props son diferentes, por lo que se activará una renderización. Eso tiene sentido. Eso tiene sentido.

React memo y Renderizado de Hijos

Short description:

React memo con el hijo no es el comportamiento predeterminado para renderizar hijos. Memorizar todo puede hacer que la aplicación sea un poco más lenta, aumentando el renderizado inicial. Puede o no salvarte de las re-renderizaciones.

Y una cosa, esto es también algo que se me ocurrió. ¿Por qué React memo con el hijo no es simplemente el comportamiento predeterminado para renderizar hijos? Porque tiene mucho sentido usarlo de esa manera. Tiene mucho sentido. Pero hasta donde yo sé, el equipo de React, no soy parte de él, así que solo uso internet. Experimentaron con hacer exactamente eso durante la construcción. Pero simplemente memorizar todo también tiene sus costos. Entonces, si simplemente memorizas todo, podría hacer que tu aplicación sea un poco más lenta. Porque de nuevo, si todo está envuelto en React memo, pero no estás envolviendo todo en el useMemo y useCallback, esos son inútiles, pero aún estás haciendo cosas durante eso. Por lo tanto, puede aumentar tu renderizado inicial. Puede o no salvarte de las re-renderizaciones, pero definitivamente aumentará tu inicial renderizado. También tiene sentido. Y otra que tenemos, ¿está bien renderizar un componente incluso si no es visible o abierto por defecto? Bueno, depende. En mi cabeza, también estaba pensando que a veces podemos y a veces no podemos, pero ¿tienes algún tipo de pensamientos o perspectiva sobre la respuesta? Por ejemplo, para diálogos de modelo, si quieres hacerlo como una transición suave que lentamente aparece, tendrías que renderizarlo un poco antes. Entonces está ahí pero invisible y luego aparece. Así que este es el caso en el que querrías renderizarlo, pero aún es invisible. Eso tiene sentido. Eso tiene sentido. Creo que eso es todo lo que tenemos de preguntas. ¿Hay alguna más? ¿Quizás hay algunas que me perdí? Asegúrate de seguir enviando tus preguntas. Puedes unirte en el Slido en 1721. Y si tienes más preguntas también, tal vez quieras profundizar, puedes encontrar a Nadia en la sala de discussion de los oradores justo a la vuelta de la esquina. Muy bien, gente, muchas gracias, Nadia. Demosle otra ronda de aplausos.

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

A Guide to React Rendering Behavior
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
Building Better Websites with Remix
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 Compiler - Understanding Idiomatic React (React Forget)
React Advanced Conference 2023React Advanced Conference 2023
33 min
React Compiler - Understanding Idiomatic React (React Forget)
Top Content
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. 
Using useEffect Effectively
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.
Speeding Up Your React App With Less JavaScript
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Top Content
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.
Routing in React 18 and Beyond
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 Performance Debugging Masterclass
React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Top Content
Featured WorkshopFree
Ivan Akulov
Ivan Akulov
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 🤐)
Concurrent Rendering Adventures in React 18
React Advanced Conference 2021React Advanced Conference 2021
132 min
Concurrent Rendering Adventures in React 18
Top Content
Featured WorkshopFree
Maurice de Beijer
Maurice de Beijer
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 Hooks Tips Only the Pros Know
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
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, TypeScript, and TDD
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
Paul Everitt
Paul Everitt
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.
Web3 Workshop - Building Your First Dapp
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Top Content
Featured WorkshopFree
Nader Dabit
Nader Dabit
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.
Designing Effective Tests With React Testing Library
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Top Content
Featured Workshop
Josh Justice
Josh Justice
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