Una Guía sobre el Comportamiento de Renderizado en React

Rate this content
Bookmark
Slides

React es una biblioteca para "renderizar" la interfaz de usuario a partir de componentes, pero muchos usuarios se confunden acerca de cómo funciona realmente el renderizado en React. ¿Qué significan términos como "renderizado", "reconciliación", "Fibers" y "committing"? ¿Cuándo ocurren los renderizados? ¿Cómo afecta el Contexto al renderizado y cómo causan actualizaciones bibliotecas como Redux? En esta charla, aclararemos la confusión y proporcionaremos una base sólida para entender cuándo, por qué y cómo React realiza los renderizados. Veremos: - Qué es el "renderizado" en realidad - Cómo React encola los renderizados y el comportamiento de renderizado estándar - Cómo se utilizan las claves y los tipos de componentes en el renderizado - Técnicas para optimizar el rendimiento del renderizado - Cómo el uso del contexto afecta el comportamiento de renderizado - Cómo se integran las bibliotecas externas en el renderizado de React

25 min
24 Oct, 2022

Video Summary and Transcription

Esta transcripción proporciona una breve guía sobre el comportamiento de renderizado en React. Explica el proceso de renderizado, comparando elementos nuevos y antiguos, y la importancia de un renderizado puro sin efectos secundarios. También cubre temas como el agrupamiento y el doble renderizado, la optimización del renderizado y el uso de contexto y Redux en React. En general, ofrece ideas valiosas para los desarrolladores que buscan comprender y optimizar el renderizado en React.

Available in English

1. Introducción a la representación de React

Short description:

Hola, soy Mark Eriksson, un ingeniero senior de front-end en Replay.io. Estoy aquí para compartir una guía breve sobre el comportamiento de la representación de React.

Hola, soy Mark Eriksson, y hoy me gustaría compartir contigo una guía relativamente breve sobre el comportamiento de la representación de React. Algunas cosas rápidas sobre mí. Soy un ingeniero senior de front-end en Replay.io, donde estamos construyendo un depurador de viaje en el tiempo para JavaScript. Si no lo has visto, por favor échale un vistazo. Responderé preguntas prácticamente en cualquier lugar donde haya un cuadro de texto en Internet. Recolecto enlaces interesantes a cualquier cosa que parezca útil. Escribo publicaciones de blog extremadamente largas, como la publicación de 8,500 palabras en la que se basa esta charla, y soy un mantenedor de Redux. Pero la mayoría de la gente realmente me conoce como ese tipo con el avatar de los Simpsons.

2. Understanding React Rendering

Short description:

La representación es el proceso en el que React solicita a los componentes que describan la interfaz de usuario en función de las props y el estado actuales. Luego, aplica las actualizaciones al DOM. React recopila un árbol de objetos que describen la apariencia del componente y lo compara con el árbol anterior. La fase de renderizado recorre el árbol de componentes y forma el árbol final. La fase de confirmación aplica los cambios en el DOM y ejecuta los métodos del ciclo de vida. Las pasadas de renderizado de React comienzan con llamadas a setState. El comportamiento predeterminado es que los componentes padres rendericen recursivamente a sus hijos.

Entonces, comencemos preguntando, ¿qué es la representación? La representación es el proceso en el que React solicita a tus componentes que describan cómo quieren que se vea la interfaz de usuario ahora, en función de sus props y estado actuales. Luego, toma eso y aplica las actualizaciones necesarias al DOM.

Ahora voy a hablar en términos de React, DOM y la web, pero los mismos principios se aplican a cualquier otra representación de React, como React Native o React 3 Fiber. Cuando escribimos componentes, los hacemos devolver etiquetas JSX como <MiComponente>. En tiempo de compilación, estas se convierten en llamadas a funciones a través de React.createElement, que a su vez devuelve objetos con el tipo, props e hijos. Estos forman un árbol de objetos que describen cómo deberían verse los componentes ahora.

React llamará a tus componentes, recopilará este árbol de objetos y luego comparará el árbol actual de elementos con el último árbol de elementos que se renderizó la última vez. Este proceso se llama reconciliación. Cada pasada de representación se puede dividir en dos fases diferentes. La primera fase es la fase de renderizado. Aquí, React recorre el árbol de componentes, les pregunta a todos los componentes cómo quieren que se vea la interfaz de usuario ahora y luego recopila todo eso para formar el árbol final.

Ahora, la fase de renderizado se puede dividir en varios pasos. De hecho, a partir de React 18, React podría renderizar algunos componentes, hacer una pausa, permitir que el navegador se actualice, renderizar algunos más, tal vez manejar algunos datos entrantes como una acción de pulsación de tecla y una entrada de texto, y luego, una vez que todos los componentes se hayan renderizado, pasar a la fase de confirmación. Durante la fase de confirmación, React ha determinado qué cambios deben aplicarse al DOM y ejecuta todos esos cambios de forma síncrona en una secuencia. También ejecuta los ciclos de vida de la fase de confirmación, como UseLayoutEffectHook o ComponentDidMount y DidUpdate en componentes de clase. Luego, después de un breve retraso, ejecutará los UseEffectHooks más tarde. Esto le da al navegador la oportunidad de pintar entre las actualizaciones del DOM y la ejecución de los UseEffects.

Cada pasada de representación de React comienza con alguna forma de llamada a setState. Para componentes de función, son los setters del hook UseState y el método dispatch de UseReducer. Para componentes de clase, es this.setState o this.forceUpdate. También puedes desencadenar representaciones volviendo a ejecutar el método ReactDom.Render de nivel superior. O también está el nuevo hook UseSyncExternalStore, que escucha las actualizaciones de bibliotecas externas como Redux. Antes de UseSyncExternalStore, las bibliotecas como React Redux todavía tenían que llamar a setState de alguna forma internamente. Los componentes de función en realidad no tienen un método forceUpdate, pero puedes hacer básicamente lo mismo creando un hook UseReducer que simplemente incremente un contador cada vez.

Ahora es muy importante entender que el comportamiento predeterminado de React es que cada vez que un componente padre se renderiza, React renderiza recursivamente a todos los hijos dentro de este componente. Creo que aquí es donde mucha gente se confunde. Supongamos que tenemos un árbol de cuatro componentes, A, B, C y D. Llamamos a setState dentro del componente B. React encola una nueva representación.

3. Proceso y principios de representación de React

Short description:

React comienza a representar desde la parte superior del árbol de componentes y continúa hacia abajo, incluso si los componentes no están marcados para actualizaciones. La representación no siempre resulta en actualizaciones en el DOM. React compara los elementos nuevos y antiguos para determinar si se produjeron cambios. La representación es necesaria para que React determine si se necesitan actualizaciones. Al escribir componentes, la representación debe ser pura y no tener efectos secundarios.

React comienza desde la parte superior del árbol, mira A y ve que no se marcó para una actualización. Representará B. B dice que su hijo debe ser C. Y como B se representó, React continúa y representa el componente C. C dice que tiene un hijo. React sigue adelante. React también representa a D. Entonces, aunque C y D no se marcaron para actualizaciones al llamar a setState, React siguió adelante y representó todos los componentes anidados dentro de B.

Otra cosa con la que la gente se confunde es pensar que React representa componentes porque las props cambiaron. No. Por defecto, simplemente sigue todo el camino hacia abajo del árbol de componentes. A React no le importa si las props cambian. Simplemente se recorre todo el subárbol.

Es importante entender que la representación no siempre implica actualizaciones en el DOM. Cuando React salió por primera vez, el equipo de React habló sobre la idea de que la representación es conceptualmente similar a volver a dibujar toda la interfaz de usuario desde cero. Pero en la práctica, lo que sucede es que un componente puede devolver el mismo tipo de descripción que la última vez. Y así, React compara los nuevos elementos con los antiguos y ve que en realidad no ha cambiado nada. Por lo tanto, no se necesitan actualizaciones para esta sección del DOM. Pero para determinarlo, React tuvo que pasar por el proceso de representación y preguntar al componente qué quiere. Las representaciones no son algo malo. Así es como React sabe si necesita aplicar alguna actualización en el DOM en absoluto.

Hay algunas reglas que debemos seguir al escribir componentes que hacen representación. Y lo más importante es que la representación debe ser pura y no puede tener efectos secundarios. La definición típica de un efecto secundario es cualquier cosa que afecte al mundo fuera de este componente y esta llamada de representación. Sin embargo, no todos los efectos secundarios son obvios. Y el hecho de que haya un efecto secundario no significa que toda la aplicación se vaya a romper y explotar. Por ejemplo, si se muta una prop, eso es definitivamente un efecto secundario y es malo, y causará problemas, pero hablando técnicamente, una declaración de console.log también es un efecto secundario. Y tenerlo en el componente no romperá las cosas. Sebastian Markbaga del equipo de React escribió un artículo en el que hablaba sobre las reglas de React y podemos resumirlo diciendo que la lógica de representación no debe mutar datos existentes, hacer cálculos aleatorios, hacer solicitudes de red o programar actualizaciones de estado adicionales. Sin embargo, la lógica de representación puede mutar literalmente objetos creados dentro de este componente durante el proceso de representación.

4. Detalles de la Representación en React

Short description:

Vale la pena tomarse el tiempo para leer las instrucciones. React almacena la información del componente en una estructura de datos llamada fibra. Recorre el árbol de fibras durante la representación, comparando los tipos de elementos para mayor eficiencia. Evita crear nuevos tipos de componentes dentro de otro componente. Las claves se utilizan para identificar y rastrear cambios en las listas.

Puede generar errores si algo sale mal y puede inicializar algunos valores de forma diferida. Así que vale la pena tomarse el tiempo para leer esas instrucciones.

Otra cosa que creo que mucha gente no se da cuenta es que tu componente no está almacenado realmente en React. React almacena información sobre el árbol de componentes internamente en una estructura de datos llamada fibra. Y las fibras son simplemente objetos JavaScript que describen una instancia de componente en el árbol. Tienen una referencia al tipo de componente, tienen punteros a componentes padre, hermanos e hijos. Almacenan las props y el estado actual e entrante, e información sobre si este componente necesita algo como contexto. Estos son los datos reales para cada componente.

Así que durante el proceso de representación, React en realidad recorre este árbol de objetos de fibra. Lee las props de allí, las pasa a los componentes, lee el estado anterior, aplica las actualizaciones de estado en cola y actualiza la información de seguimiento en el camino. Ahora, no necesitas mirar estos valores para poder usar React, pero puede ser útil saber que así es como React almacena todo internamente.

Dijimos antes que React compara los árboles de elementos antiguos y nuevos para averiguar qué ha cambiado. Y ese proceso puede ser muy costoso. React intentará reutilizar tanto del árbol de componentes existente y los nodos DOM como sea posible. Pero también toma algunos atajos para acelerar este proceso. Y el más grande es que compara los tipos de elementos actuales y nuevos en cada punto dado del árbol. Y si el tipo de elemento ha cambiado a una nueva referencia, asume que todo el subárbol existente de componentes probablemente sería completamente diferente, y desmontará todos los componentes en ese árbol, lo que significa eliminar todos los nodos DOM en esa ubicación en el árbol. Y luego recreará todo desde cero.

Un error común que veo es cuando las personas intentan crear nuevos tipos de componentes dentro de otro componente mientras se está representando. Y esto es malo porque cada vez que el componente padre se representa, el componente hijo será una nueva referencia. Y eso significa que siempre fallará la comparación. Y cada vez que el componente padre se representa, React destruirá el componente hijo anterior, desmontará todos los nodos DOM dentro de él y tendrá que recrearlos. Así que nunca, nunca crees tipos de componentes dentro de un componente. Siempre créalos por separado en el nivel superior.

Otra cosa que afecta a la reconciliación son las claves. Ahora pasamos lo que parece ser una prop llamada clave como identificador, pero en realidad no es una prop real. Es una instrucción para React de cómo diferenciar estas diferentes cosas. Y de hecho, React siempre elimina la clave de las props. Por lo tanto, nunca puedes tener props.key dentro de un componente, siempre será undefined. La mayoría de las veces usamos claves cuando estamos representando listas, porque si la lista va a cambiar en absoluto, React necesita saber qué elementos se agregaron, actualizaron o eliminaron. Idealmente, las claves deben ser IDs únicos de tus datos.

5. Consejos de Representación en React

Short description:

Si tienes una lista de tareas, utiliza el ID de la tarea como clave. Nunca uses valores aleatorios como claves. Aplica una clave a un componente de React para destruirlo y recrearlo intencionalmente. React agrupa múltiples cambios de estado en una sola representación. Después de llamar a setState, el valor actualizado no está disponible de inmediato debido a la representación asíncrona y el cierre.

Entonces, si tengo una lista de tareas, preferiría utilizar el to-do.id como mis claves. Puedes utilizar los índices del array como alternativa si los datos no van a cambiar con el tiempo. Y nunca, nunca uses valores aleatorios como claves.

También vale la pena señalar que puedes aplicar una clave a cualquier componente de React en cualquier momento. Y hay momentos en los que puede que quieras usar esto para decirle a React: `Oye, tenía este componente aquí, pero en realidad quiero que lo destruyas y lo vuelvas a crear cuando algo cambie`. Un buen ejemplo de esto sería si tengo un formulario que se inicializa mediante props. Tiene su propio estado interno. Y si el usuario selecciona un elemento diferente, quiero que se vuelva a crear el formulario desde cero para que todo se inicialice correctamente.

Cada vez que llamamos a setState, se encola otra representación. Pero React intenta ser eficiente con esto. Y si se encolan múltiples representaciones en el mismo ciclo de eventos, React las agrupará en una sola representación. Ahora, en React 17, esto solo ocurría automáticamente dentro de los controladores de eventos como onClick. En React 18, React siempre agrupa múltiples cambios de estado en una sola representación todo el tiempo. En este ejemplo, tenemos dos cambios de estado antes de una llamada await, y dos cambios de estado después de una llamada await. En React 17, los primeros dos se agruparían juntos porque son síncronos durante el controlador de eventos. Pero como el await causa un nuevo ciclo de eventos, en React 17, cada uno de estos otros cambios de estado causaría una representación separada de forma síncrona tan pronto como se realice la llamada. En React 18, los primeros dos cambios de estado causan una representación y los otros dos cambios de estado se agrupan juntos en una segunda representación.

Otra fuente común de confusión es la idea de qué sucede con mi valor después de llamar a setState. Realmente veo que esto sucede todo el tiempo. Las personas intentan llamar a setState con un nuevo valor, y luego intentan registrar la variable de estado pensando que ya se ha actualizado. Y esto no funciona por un par de razones. La respuesta corta habitual es que decimos: `bueno, la representación de React es asíncrona`. Y eso es técnicamente cierto. Técnicamente hablando, será síncrono. Pero al final del ciclo de eventos, desde el punto de vista de este código, es asíncrono porque no ocurrirá de inmediato. Pero el verdadero problema aquí es que el controlador de eventos es un cierre. Solo puede ver valores como counter en el momento en que este componente se representó por última vez. La próxima vez que este componente se represente, habrá una nueva copia de la función handle click, y verá la nueva copia de counter la próxima vez. Por lo tanto, tratar de usar este valor justo después de llamar a setState casi siempre es una mala idea. Hay algunos casos excepcionales con la representación.

6. React Rendering: Batching and Double Rendering

Short description:

Si llamas a setState en useLayoutEffect o ComponentDidMount o DidUpdate, se ejecutará de forma síncrona. Esto te permite obtener nodos DOM, medir su tamaño y volver a representar en función de esa información. React DOM y React Native tienen métodos para alterar el comportamiento de agrupación. En React 17 y versiones anteriores, las llamadas se pueden envolver en actualizaciones agrupadas. En React 18, hay un método de sincronización de descarga para forzar actualizaciones inmediatas. La representación doble en modo estricto detecta errores. Los componentes de función pueden llamar a setState condicionalmente, similar a getDerivedStateFromProps en componentes de clase.

Uno de ellos es que si llamas a setState en useLayoutEffect o ComponentDidMount o DidUpdate, se ejecutará de forma síncrona. Y la razón principal de esto es que es posible que hagas una primera representación y luego quieras obtener los nodos DOM, medir su tamaño y volver a representar en función de esa información. Y al hacer la representación de forma síncrona, React actualiza el DOM antes de que el navegador tenga la oportunidad de pintar, y el usuario nunca ve la apariencia intermedia.

Los reconciliadores como React DOM y React Native tienen un par de métodos que pueden alterar este comportamiento de agrupación. En React 17 y versiones anteriores, podríamos envolver las llamadas en actualizaciones agrupadas para forzar la agrupación fuera de los controladores de eventos. En React 18, hacemos lo contrario. Debido a que la agrupación es la configuración predeterminada, hay un método de sincronización de descarga que obliga a React a aplicar las actualizaciones de inmediato. Además, lo que a todos les disgusta es la representación doble durante el modo estricto, y React hace esto para intentar detectar errores. Esto significa que no puedes usar console.log en medio de un componente de función para contar la cantidad de veces que se ha representado. En su lugar, colócalo en un useEffect o usa las React DevTools para medirlo. Y finalmente, hay un caso en el que los componentes de función pueden llamar a setState mientras se están representando, y eso es si lo hacen de forma condicional. Y si haces eso, React verá que llamaste a setState e inmediatamente ejecutará el componente nuevamente con el nuevo estado. Esto es equivalente al comportamiento de getDerivedStateFromProps en componentes de clase.

7. Optimizando la Representación de React y el Contexto

Short description:

Para optimizar la representación, evita las representaciones innecesarias utilizando react.memo o devolviendo el mismo objeto de referencia de elemento. Memoriza los componentes críticos, actualiza el estado de forma inmutable y utiliza el perfilador de React DevTools para medir el rendimiento. El contexto en React hace que todos los componentes consumidores se vuelvan a representar cuando se actualizan.

Entonces, ¿cómo hacemos que esto vaya más rápido? Podríamos decir que una representación se desperdicia si devuelve exactamente la misma salida que la última vez, y debido a que la salida de la representación debe basarse en las props y el estado, si el componente tiene las mismas props en el mismo estado, probablemente esté devolviendo la misma salida. Por lo tanto, podemos optimizar el comportamiento omitiendo la representación si las props no han cambiado. Y esto también omitirá todo el subárbol. La forma normal de hacer esto es envolver tu componente con react.memo, que verifica automáticamente si alguna de las props ha cambiado. En los componentes de clase, podrías usar ShouldComponentUpdate o PureComponent, o también envolverlo con react.memo. Hay otra forma de hacer esto, y es que el componente padre devuelva exactamente el mismo objeto de referencia de elemento que hizo la última vez. Y si haces eso, React omitirá la representación de este componente y de todos sus hijos. Puedes usar el hook UseMemo para guardar un elemento de React para más tarde, o también puedes usar props.children. La diferencia entre esto y React.memo es que React.memo está controlado efectivamente por el componente hijo, porque lo hemos envuelto. Pero el comportamiento de referencia del mismo elemento está controlado por el componente padre.

Entonces dijimos anteriormente que no es cierto que React represente los componentes hijos cuando las props cambian. React siempre representa todos los componentes de forma predeterminada. El único momento en que las referencias de las props importan es si el componente ya está optimizado usando React.memo. Ahora, ten en cuenta que si estás pasando nuevos hijos de esta manera, estás pasando una nueva referencia de props.children cada vez, y React.memo nunca realmente te ahorrará trabajo. Si necesitas pasar referencias consistentes a un hijo, entonces llama a useCallback o useMemo. Y finalmente, no envuelvas componentes de host como Button en React.memo. En realidad, no te ahorra nada.

Entonces, ¿deberías memorizar todo? La respuesta corta es no. El equipo de React sugiere que no lo hagas de forma predeterminada. Busca puntos críticos que sean costosos y solo memoriza los componentes críticos para mejorar el rendimiento. Además, las actualizaciones de estado siempre deben hacerse de forma inmutable. Si mutas los datos, es probable que cause errores. Además, React podría pensar que en realidad no ha cambiado nada y no volver a representar tu componente. Siempre, siempre realiza actualizaciones de estado de forma inmutable. Si necesitas medir el rendimiento, React DevTools tiene una pestaña de perfilador, y puedes grabarte a ti mismo usando la aplicación durante unos minutos y luego ver en el perfilador qué componentes se representaron y cuánto tiempo llevó. Puedes hacerlo en modo de desarrollo para tener una idea de los tiempos relativos, y también hay una compilación especial de perfilado de React para ver cómo serían los tiempos en producción. Entonces, ¿cómo afecta esto al contexto? El contexto se trata realmente de la inyección de dependencias de un valor en un subárbol. Para actualizarlo, debes llamar a SetStateInApparentComponent y pasar un nuevo valor, lo que hace que todos los componentes que consumen el contexto se vuelvan a representar. Actualmente, no hay forma de que un componente lea solo una parte de un valor de contexto. Si lees contextValue.a y la aplicación actualiza contextValue.b, debe crear un objeto completamente nuevo, por lo que el otro componente también se volverá a representar.

8. Optimizando la Representación de React y Redux

Short description:

Actualizar el estado encola una representación. React se representa de forma recursiva de forma predeterminada. Algunas formas de evitar representaciones innecesarias incluyen el uso de React.memo o props.children. React Redux pasa el almacén de Redux desde el contexto y cada componente se suscribe por separado. Ejecutar nuevos selectores es menos costoso que hacer otra pasada de representación en React. Connect envuelve componentes y actúa como React.memo. El equipo de React está trabajando en un nuevo compilador llamado React forget para mejorar el rendimiento. Se ha discutido agregar una opción de selectores para usar el contexto.

Entonces sabemos que actualizar el estado encola una representación. React se representa de forma recursiva de forma predeterminada, le das un nuevo valor a un proveedor de contexto y eso proviene del estado del componente normalmente, lo que significa que, de forma predeterminada, llamar a SetStateInApparent hará que toda la aplicación se vuelva a representar, independientemente de si el contexto está involucrado o no. Esto es simplemente el comportamiento predeterminado.

Entonces, ¿cómo evitamos esto? Hay un par de formas. La primera es colocar el primer hijo del proveedor de contexto dentro de React.memo. La otra opción es usar props.children, en cuyo caso, se aplica la misma optimización de elementos. Ahora, cuando un componente lee el valor del contexto, se representará y todos los hijos anidados se volverán a representar desde allí. Nuevamente, comportamiento normal.

Entonces, ¿cómo funciona React Redux? Bueno, React Redux pasa el almacén de Redux desde el contexto y luego cada componente se suscribe al almacén de Redux por separado. Y cada vez que se despacha una acción, lee el estado, extrae un valor del selector y compara para ver si ha cambiado. Eso es muy diferente a cómo se representa el contexto. Normalmente, el costo de ejecutar nuevos selectores es menor que el costo de que React haga otra pasada de representación. Por lo tanto, está bien tener muchos selectores de uso y muchos componentes conectados, pero los selectores deben ser muy rápidos. Y esa es una de las razones por las que tenemos la biblioteca reselect para la memorización.

Entonces, connect envuelve componentes y actúa como React.memo. De hecho, en realidad tiene React.memo dentro. UseSelector está dentro de un componente y no puede evitar que se represente cuando lo hace el padre. Entonces, si tienes componentes de función y useSelector y tienes árboles grandes que se representan, envuélvelos en React.memo tú mismo. Hay algunas mejoras más en camino. El equipo de React está trabajando en un nuevo compilador llamado React forget, que automáticamente memorizará no solo las matrices de dependencia de tus hooks, sino que también optimizará la salida del elemento utilizando el mismo enfoque de memorización. Esto tiene una verdadera posibilidad de mejorar drásticamente el rendimiento de las aplicaciones de React automáticamente. Y luego se ha discutido agregar una opción de selectores para usar el contexto, lo que te permitiría volver a representar solo si cambia una cierta parte del valor del contexto. Ambas cosas son para tener en cuenta. Después de que termine esta charla, publicaré las diapositivas en mi blog y proporcionaré enlaces a algunos recursos e información adicional. Espero que esto te dé una mejor idea de cómo funciona React para que puedas usarlo de manera más eficiente. Gracias y diviértete usando React. ♪♪♪

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 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.
React Advanced Conference 2021React Advanced Conference 2021
27 min
(Easier) Interactive Data Visualization in React
Top Content
If you’re building a dashboard, analytics platform, or any web app where you need to give your users insight into their data, you need beautiful, custom, interactive data visualizations in your React app. But building visualizations hand with a low-level library like D3 can be a huge headache, involving lots of wheel-reinventing. In this talk, we’ll see how data viz development can get so much easier thanks to tools like Plot, a high-level dataviz library for quick & easy charting, and Observable, a reactive dataviz prototyping environment, both from the creator of D3. Through live coding examples we’ll explore how React refs let us delegate DOM manipulation for our data visualizations, and how Observable’s embedding functionality lets us easily repurpose community-built visualizations for our own data & use cases. By the end of this talk we’ll know how to get a beautiful, customized, interactive data visualization into our apps with a fraction of the time & effort!

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