Sobre el Origen de React

Rate this content
Bookmark

Esta charla examina cómo han evolucionado los componentes en React. Miraremos hacia atrás en versiones anteriores de React, las características principales y cómo hitos como Fiber y Concurrent cambiaron la forma en que escribimos componentes en React. Algunos detalles adicionales: quiero dar a los asistentes una idea de cómo lucían los componentes en diferentes puntos importantes de la historia de React. Los componentes escritos en 2013 no se parecen a los componentes escritos en 2015 o hoy en día. Esta es una historia de React que para algunos será un paseo por el carril de los recuerdos y para otros, información completamente nueva.

22 min
25 Oct, 2021

Video Summary and Transcription

Esta charla explora la evolución de los componentes en React, comenzando desde la versión .12. Se discute la introducción de los componentes de clase y la depreciación de los mixins. Se destaca la aparición de los componentes de orden superior como una mejor opción para la reutilización de código. También se cubre la introducción de los hooks en React 16.8 y se mencionan posibles ramas futuras de evolución, como los componentes de servidor y los componentes de función en los hooks.

Available in English

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

Short description:

Bienvenidos a Sobre el Origen de React. Soy Jen Craden, una ingeniera de software senior en Netflix, aquí para hablar sobre la evolución de los componentes. React toma prestado de Sobre el Origen de las Especies, y al igual que los pinzones de Darwin, los componentes de React han evolucionado y se han adaptado. Esta charla proporciona contexto sobre las estructuras antiguas de React y explica qué ha cambiado y por qué.

Soy Jen Craden, y soy una ingeniera de software senior en Netflix, donde trabajo en el equipo de Plataforma Node.js. Así que, hoy estoy aquí para hablarles sobre la evolución. Bueno, la evolución de los componentes.

Esta charla toma prestado su título de Sobre el Origen de las Especies, uno de los libros más conocidos de la historia moderna. Y cuando ves este libro, o el nombre de Charles Darwin, quien lo escribió, probablemente te viene a la mente la palabra evolución. O tal vez sea selección natural. O si eres como yo, son los pinzones. Siempre pienso en los pinzones de Darwin.

Ahora, todas estas son asociaciones válidas, y en realidad todas están relacionadas. Así que, la evolución se basa en la selección natural, y Darwin llegó a la idea de la selección natural durante sus viajes a las Islas Galápagos. Donde observó pinzones. Todos iguales, pero diferentes de manera única. Así que, son los picos, cada uno adaptado a un tipo de alimento específico. Al ver esta graduación y diversidad de estructura en un pequeño grupo de aves relacionadas entre sí en este archipiélago, una especie había sido tomada y modificada para diferentes propósitos. Esos son los pinzones. Pero esta graduación y diversidad de estructura, esta especie tomada y modificada para diferentes propósitos, tal vez también podría ser React components.

Verás, estamos en un punto de la historia de React ahora donde podemos mirar hacia atrás y ver cómo ha evolucionado. Te prometo que esto no es una lección de historia. No vamos a estar memorizando fechas o discutiendo los grandes debates de RFC de 2016 o algo por el estilo. Esta charla pretende ser útil. Las versiones antiguas de React todavía están en producción. Y dependiendo de cuándo hayas aprendido React, es posible que veas un componente de una versión anterior y tengas algunas preguntas. Ahí es donde entra esta charla. Te ayudará a identificar algunas de las estructuras antiguas y proporcionará contexto sobre qué ha cambiado y por qué. Ahora, si has estado escribiendo React desde los primeros días, esta charla es más un viaje por el camino de la memoria. Así es como me sentí al escribirla. He estado trabajando con React desde la versión .12 y fue lanzada a finales de 2014. En ese momento, React ya estaba disponible públicamente desde hace más de un año. Su lanzamiento público inicial fue a mediados de 2013.

2. Evolución de los Componentes de React

Short description:

Los componentes de React alrededor de la versión .12 marcaron el punto de partida. Este período sirvió como referencia para la estructura y el comportamiento de los componentes. Se utilizaba React.createClass, ya que los componentes de clase y función, así como los fragmentos, no existían. Los métodos del ciclo de vida, como component will mount y did mount, se mantuvieron consistentes. La reutilización de código se lograba mediante mixins.

Pero no considero que ese sea nuestro punto de partida. De hecho, vamos a comenzar a analizar los componentes de React alrededor de la versión .12. Nuevamente, esto es cuando comencé a aprender React y eso se debe a que React realmente estaba tomando forma. Estaba comenzando a ganar popularidad en la comunidad de JavaScript, React era la palabra de moda.

Además, no hay cambios significativos en los componentes de React entre .3 y .12. Por lo tanto, este período de tiempo es nuestra referencia para cómo se estructuraban y se comportaban los componentes. Y este es uno de esos componentes. Ahora, algunos de ustedes nunca han visto esto antes y algunos de ustedes están experimentando flashbacks, pero sí, esto es React en sus primeros días.

Ahora, lo primero que probablemente notes es React.createClass. En este momento de la historia de React, no existen los componentes de clase ni los componentes de función. Tampoco tenemos fragmentos y se están renderizando elementos span adicionales. Eso es cierto. Y hay mucho más. No voy a poder enumerar todas las diferencias en React y su ecosistema entre entonces y ahora, pero en cuanto a la estructura del componente, este es nuestro ancestro más antiguo.

A medida que comenzamos a construir un árbol evolutivo de los componentes de React, este se convierte en la base del árbol. Todos los componentes a partir de aquí evolucionaron a partir de CreateClass. Y esas evoluciones siguen algunas ramas comunes. Entonces, si volvemos a mirar este componente, ¿qué atributos evolucionaron junto con la estructura del componente? Además de la creación del propio componente utilizando CreateClass, ¿qué hay de los métodos del ciclo de vida? Aquí he creado todos los métodos del ciclo de vida disponibles en React .12 y anteriores. Por lo tanto, eso incluye component will mount, component did mount, will receive props, will update, did update y will unmount. Estos probablemente te resulten más familiares que CreateClass en sí, y eso se debe a que estos métodos del ciclo de vida no cambian durante gran parte de la historia de React. Probablemente hayas visto o trabajado con estos ciclos de vida en algún momento. Lo que puede resultarte menos familiar son getInitialState y getDefaultProps, y estos hacen exactamente lo que esperarías, establecer el estado inicial o establecer las props predeterminadas. Por lo tanto, es una estructura poco familiar pero un concepto conocido. Al completar las ramas de nuestro árbol, los ciclos de vida se convierten en una de esas ramas. Estaremos atentos a cómo evolucionan estos ciclos de vida con el tiempo en conjunto con la estructura del componente.

Ahora, hay una rama más en este árbol evolutivo por explorar, y eso es la reutilización de código. ¿Cómo compartimos código entre componentes? Bueno, en los días de createClass, solíamos utilizar algo llamado mixins. Aquí tienes un mixin. Se parece notablemente a cómo creamos componentes, pero no pasamos este objeto a createClass.

3. Componentes de React y Reutilización de Código

Short description:

Vamos a proporcionar mixins a los componentes para reutilización de código. Los componentes de clase se introdujeron en la versión .13, lo que supuso un cambio fundamental en la construcción de componentes de React. Se extienden de React.component en lugar de utilizar createClass, y el estado se establece en el constructor mientras que DefaultProps es una propiedad de clase. Los componentes de clase no admiten mixins, lo que marca un inicio lento en la evolución de la reutilización de código en React.

En su lugar, vamos a proporcionarlo a un componente con la clave mixins y una matriz de mixins. Aquí estoy proporcionando el mixin de conteo a este componente. Y ahora puedo usar lo que se proporciona en los mixins como si existiera en el propio componente. Estoy usando this.increment, parte del mixin de conteo, y this.state.count, también parte del mixin de conteo. Así que ahora podemos completar la rama de reutilización de código de nuestro árbol con mixins como la primera evolución en esa rama. No pasa mucho tiempo, por cierto, para que este árbol crezca.

La siguiente versión de React se basa en esta base y vamos a empezar a ver estructuras más familiares como los componentes de clase. Los componentes de clase se introducen en la versión .13. Esto es importante. Es un cambio fundamental en cómo construimos los componentes de React. Ahora, createClass todavía es compatible, pero pronto las clases se convertirán en la opción predeterminada. Y no vamos a pasar mucho tiempo mirando los componentes de clase, pero quiero señalar algunas diferencias clave con respecto a createClass. La primera es que no llamamos a createClass. En su lugar, nos extendemos de React.component. Ahora, getInitialState y getDefaultProps ya no existen. Establecemos el estado en el constructor y establecemos DefaultProps como una propiedad de clase. Bien, vamos a añadir componentes de clase a nuestro árbol. Estos son una evolución directa de createClass. Pero, ¿qué pasa con las otras ramas? ¿Hubo algún cambio? En cuanto a los ciclos de vida, realmente nada. Como se mencionó, la inicialización del estado y DefaultProps es un poco diferente, pero los métodos del ciclo de vida en sí siguen estando. Por lo tanto, los componentes de clase siguen conectados a la rama de los ciclos de vida. ¿Y qué pasa con la reutilización de código? ¿Seguimos utilizando mixins con los componentes de clase? No. Por lo tanto, los componentes de clase no admiten mixins. Y resulta que este es el inicio lento de la evolución de la reutilización de código en React. Por lo tanto, la evolución tiende a ser un proceso lento. La selección natural ocurre de generación en generación, pequeños cambios, adaptaciones permiten a las especies sobrevivir y transmitir esos rasgos a la siguiente generación. Ahora, las polillas moteadas son un ejemplo famoso de selección natural y acción. De alguna manera, a lo largo de 50 años, a partir de la década de 1850, las polillas de color claro cambiaron de color. A principios de 1900, las polillas moteadas oscuras eran la población dominante. Lo fascinante es por qué las polillas cambiaron de color, ¿qué más estaba sucediendo durante esos 50 años? No eran solo las polillas las que estaban evolucionando.

4. Evolución de React y la Deprecación de Mixins

Short description:

La revolución industrial forzó la evolución en las especies. Los mixins no fueron deprecados en React hasta la versión .13, pero los componentes de clase sin mixins impulsaron a React a evolucionar más allá de ellos. Los componentes de función fueron introducidos como una sintaxis más simple para los componentes existentes, adoptados por la comunidad de React. Sin embargo, carecían de ciclos de vida y opciones de reutilización de código. Una publicación de blog titulada 'Mixins Considerados Dañinos' en 2016 señaló la próxima deprecación de mixins en React.

La revolución industrial significó la construcción de fábricas, fábricas que funcionaban con carbón y producían un humo oscuro que cubría el paisaje, por lo que las polillas moteadas de color claro tenían menos capacidad para camuflarse. Los depredadores podían detectarlas en contraste con el paisaje más oscuro, y su tasa de supervivencia disminuyó, pero las polillas moteadas oscuras, su tasa de supervivencia aumentó. Así que a veces la selección natural es simplemente una casualidad, una mutación que resulta ser una mejora de la versión anterior, pero a veces la evolución se ve forzada en una especie.

Y debo dejar claro que `forzada` no implica intención. Los mixins ni siquiera fueron deprecados en la versión .13, y no había intención de deprecar mixins en versiones futuras. La regla era simplemente si se requería un mixin, usar create class. Los componentes de clase estaban destinados a evolucionar, React más cercano al JavaScript idiomático. Los mixins no eran parte de JavaScript, por lo que tenía sentido no incluirlos. Ahora, la falta de soporte no pretendía alejar a React de los mixins, aunque eso es lo que sucedió. No fue intencional, pero los componentes de clase sin mixins nos obligaron a evolucionar más allá de ellos.

Sin embargo, la evolución es un proceso lento, por lo que antes de que eso suceda, tenemos un nuevo desarrollo en React. Componentes sin estado, o como los llamamos ahora, componentes de función. Entonces, `sin estado` no era el mejor término para estos porque los componentes sin estado ya existían. Podías crear un componente solo con la función render. Los ciclos de vida, el estado e incluso las props siguen siendo 100% opcionales en los componentes de React. Por lo tanto, es mejor describirlos por lo que son, componentes de función. Estos se presentan como una nueva sintaxis más simple para los componentes que ya estábamos escribiendo, y debo decir que son hermosos. Cuando se lanzan, es encantador. Aún mejor con la deconstrucción de props, como, oh, mira eso, es tan hermoso. Cuando se lanzan, la comunidad de React abraza por completo los componentes de función. Estos son una adición bienvenida al árbol evolutivo de React.

Ahora, en ese momento, no hay ciclos de vida en los componentes de función y no hay opciones para reutilización de código. Al igual que los componentes de clase, los componentes de función acercan a React al JavaScript idiomático. Por lo tanto, esta evolución tiene sentido. Pero ahora tenemos create class, componentes de clase, componentes de función y create class todavía es un requisito para los mixins. Eso va a cambiar pronto. De hecho, ha estado en proceso durante un tiempo. A principios de 2016, se publica una nueva publicación de blog en el blog oficial de React. Su título es `Mixins Considerados Dañinos`. ¿Qué pasó? Entonces, a partir de .13, los mixins no están deprecados y van a ser deprecados, ¿qué cambió? Mira, los mixins no eran una gran solución desde el principio.

5. Evolución de la Reutilización de Código en React

Short description:

Los mixins en React se utilizaron inicialmente como una vía de escape, pero a medida que React evolucionó y la composición se hizo popular, se descubrió que los mixins eran perjudiciales. Los componentes de orden superior (HOC) surgieron como una mejor opción para la reutilización de código, proporcionando funcionalidad adicional a los componentes. Aunque los HOC tenían algunos problemas como colisiones de nombres, ofrecían un enfoque compositivo para la reutilización de código en React. Con la introducción de los componentes de orden superior, React estaba en camino de convertirse en una tecnología moderna. Se saltó la versión 15 de React y la versión 16 introdujo fragmentos, límites de errores, portales y más.

Sufren problemas de indirección, mantenimiento y, lo más importante, rompen la composición. La composición es un concepto fundamental en React. Este artículo de blog todavía está disponible si quieres leerlo, pero la versión resumida es que los mixins no estaban destinados a esto. Se crearon como una vía de escape. Han pasado tres años desde que se lanzó React. El panorama ha cambiado. Ahora, varias bibliotecas de Vue adoptan un modelo de componentes similar a React. El uso de la composición en lugar de la herencia para construir interfaces de usuario declarativas ya no es una novedad.

Anteriormente, los mixins no se consideraban perjudiciales en la historia de React, pero a medida que React se volvió más popular y se adoptó la composición, nos dimos cuenta de que los mixins eran perjudiciales y que no necesitábamos la vía de escape que proporcionaban. Había opciones mejores que se ajustaban al modelo compositivo de React, como los componentes de orden superior. Un componente de orden superior es una función que toma un componente y devuelve un nuevo componente, y a menudo se le proporciona funcionalidad adicional. Este componente withCounter es un componente de orden superior, y por cierto, eso es un poco largo, así que voy a empezar a llamarlos HOC. Este HOC recibe un componente y proporciona un contador y una función para incrementar ese contador.

Aquí hay un componente de botón que espera una función de incremento y un contador, y aquí proporciono el componente de botón al HOC y obtengo un nuevo botón de contador con toda la funcionalidad que necesito. Este es un ejemplo muy forzado, pero esa es la idea principal. Los HOC todavía tienen problemas como colisiones de nombres, pero ahora tenemos una opción para reutilizar código con componentes de clase y es compositiva. Ahora podemos agregar componentes de orden superior como la próxima generación de reutilización de código en React. Sé que no parece así, pero con esa adición, estamos realmente cerca de tener un React moderno.

Más cerca de lo que piensas. Este árbol en realidad no cambia durante mucho tiempo. La próxima versión importante de React es la versión 15. Sí, lo sé. Pasamos de la versión .14 a la 15. Las versiones anteriores de React estaban destinadas a llegar a una versión estable 1.0, pero React ya era estable y lo había sido durante un tiempo. Así que simplemente pasamos a la versión 15. Y la versión 15 tiene muchas actualizaciones, pero nada que cambie fundamentalmente la estructura de los componentes. Así que la vamos a omitir y pasar a la siguiente versión importante. La versión 16. En su lanzamiento inicial, la versión 16.0 introduce fragmentos, límites de errores, portales y más.

6. Evolución de React: Ciclos de vida y Hooks

Short description:

Las versiones 16.3 y 16.8 introdujeron la deprecación de los ciclos de vida y los hooks. Fiber, el reconciliador de React, permitió pausar y reanudar el trabajo, lo que hizo que algunos métodos de ciclo de vida fueran inseguros. Se introdujeron nuevos métodos de ciclo de vida para manejar estos cambios. Los hooks son una evolución de los componentes de función, proporcionando una nueva opción para la reutilización de código. La línea de tiempo termina con React 17, que no tiene nuevas características visibles para los desarrolladores.

Pero no hubo cambios reales en los componentes o ciclos de vida hasta un poco más tarde. Por lo tanto, me refiero a las versiones 16.3 y 16.8 como dos lanzamientos importantes que no fueron lanzamientos importantes. Técnicamente, estos son lanzamientos menores, pero es cuando se introducen las deprecaciones de los ciclos de vida y los hooks están disponibles. Las deprecaciones de los ciclos de vida son un poco impactantes. Recuerda que React fue introducido y desde entonces no ha habido cambios significativos en los ciclos de vida, pero en la versión 16.3, se marcan tres ciclos de vida como inseguros. Los ciclos de vida en sí no se eliminan, pero para usarlos, ahora necesitas usar el prefijo inseguro.

Y esto es para el montaje del componente, la actualización del componente y la recepción de props del componente. Ahora, ¿por qué estos cambios y por qué ahora? La respuesta es Fiber. Fiber es el reconciliador de React y te lo voy a explicar muy, muy rápido. Si estás interesado en esto, hay muchos recursos más detallados, pero para contextualizar estos cambios en los ciclos de vida, esto es lo que necesitas saber. Antes de Fiber, el reconciliador usaba la recursión, pero la recursión no te permite detener y comenzar un proceso. Fiber puede hacerlo, por lo que React puede hacer un trabajo, pausar, permitir que el navegador haga un trabajo y luego reanudar su propio trabajo, y así sucesivamente. Y debido a que el trabajo se puede pausar y reanudar, algunos métodos de ciclo de vida eran inseguros. Esperamos que el montaje del componente sea seguido por el desmontaje del componente, pero con Fiber es posible que el montaje del componente se llame varias veces y que el desmontaje del componente no se llame en absoluto. Por lo tanto, el trabajo puede detenerse antes de que se monte el componente y por eso es inseguro. Para ayudar con estos cambios, se introdujeron nuevos métodos de ciclo de vida. Así que tenemos el método getDerivedStateFromProps y el método getSnapshotBeforeUpdate. No voy a perder tiempo explicando estos, hay una gran documentación disponible si no te resultan familiares, pero estos son los primeros nuevos ciclos de vida en toda la historia de React, y esta también es la última evolución en ese lado del árbol. El lado más centrado en los componentes de clase, los ciclos de vida y los HOC. A medida que avanzamos en nuestra línea de tiempo, se introducen los hooks.

Nuevamente, no voy a explicar los hooks, pero son una evolución de los componentes de función. Ahora podemos usar estado en los componentes de función y hay otros hooks que nos permiten acceder a las capacidades que antes estaban limitadas solo a los componentes de clase. Sin embargo, notarás que no conecto la rama de los ciclos de vida con los hooks. Y eso es porque los hooks no son ciclos de vida. No hay ciclos de vida reales en los componentes de función, eso es el futuro de React. useEffect puede ejecutarse una vez, se puede proporcionar una función de limpieza, pero eso no son ciclos de vida. Los hooks también son una opción completamente nueva para la reutilización de código que no está relacionada con los HOC o los mixins, es una nueva rama por sí misma. Y así, llegamos al final de la línea de tiempo. Llegó rápido, lo sé. La versión 17 se lanzó sin nuevas características visibles para los desarrolladores y aquí estamos en el React moderno.

7. Evolución de React: ¿Qué sigue?

Short description:

Nuestro árbol evolutivo sigue sin cambios. La investigación del equipo de React sobre los componentes del servidor y los componentes de función en hooks podrían ser ramas potenciales para la evolución futura. A medida que avanzamos, es posible que olvidemos cómo solían ser las cosas, pero es un viaje emocionante ver cuánto hemos avanzado. Gracias a todos por escuchar.

Nuestro árbol evolutivo sigue sin cambios. Esto podría hacernos preguntar, ¿qué sigue? Tengo algunas suposiciones, quiero decir, el equipo de React compartió su investigación sobre los componentes del servidor el año pasado, eso podría ser una rama en este árbol. O al mirar los componentes de función en hooks, esa parte del árbol está un poco vacía, así que tal vez ahí es donde veremos alguna evolución.

La verdad es que no lo sé realmente. Lo que sí sé es que, al escribir esta charla, me di cuenta de cuánto había olvidado sobre los primeros tiempos de React. Supongo que esa es la ventaja de poder avanzar sin mirar atrás. Y si eres nuevo en React, te va a pasar a ti también, vas a olvidar cómo solían ser las cosas.

Oh, y no puedo esperar ese momento para ti, porque no solo React evolucionó en ese tiempo, tú también lo hiciste. Vas a poder ver cuánto has avanzado. Y con eso, solo quiero decir, gracias a todos por escuchar. Nos vemos en línea y algún día en el mundo real también. ♪♪

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 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