Trata bien a tus usuarios con Renderizado Segmentado

Rate this content
Bookmark
Slides

Si crees que el renderizado estático se limita a contenido genérico y público que es el mismo para todos los usuarios de tu sitio web, esta charla es para ti. El Renderizado Segmentado es un nuevo patrón para Jamstack que te permite personalizar contenido de forma estática, sin ningún tipo de renderizado del lado del cliente o renderizado del lado del servidor por solicitud. Obtén el mejor rendimiento posible para casos de uso como tematización, internacionalización, pruebas A/B, multiinquilinato y comienza a tratar bien a tus usuarios.

21 min
24 Oct, 2022

Video Summary and Transcription

La charla discute el concepto de renderizado segmentado para la personalización en el desarrollo web. Explora diferentes técnicas de renderizado, incluyendo el renderizado del lado del servidor, la generación estática de semillas y el renderizado dinámico. El problema de los invitados ricos y los clientes pobres se aborda a través del renderizado segmentado. La implementación del renderizado segmentado con Next.js involucra un servidor proxy ligero y la reescritura de URL. La charla también destaca los beneficios del renderizado invisible del lado del servidor y sugiere una futura API unificada para el renderizado del servidor.

Available in English

1. Introducción

Short description:

Hola a todos y bienvenidos a mi charla, Trata bien a tus usuarios con el renderizado segmentado. Mi nombre es Eric Burel. Soy el fundador de LBKE, una pequeña empresa en Montpellier, Francia. Soy un desarrollador web pero también un consultor en financiamiento público para investigación empresarial. Soy el mantenedor de VulcanJS, un framework que quizás conozcas si vienes del ecosistema de Meteor.js y que ahora se ejecuta en Next.js y GraphQL.

Hola a todos y bienvenidos a mi charla, Trata bien a tus usuarios con el renderizado segmentado.

Primero, permíteme presentarme. Mi nombre es Eric Burel. Soy el fundador de LBKE, una pequeña empresa en Montpellier, Francia. Soy un desarrollador web pero también un consultor en financiamiento público para investigación empresarial. Soy el mantenedor de VulcanJS, un framework que quizás conozcas si vienes del ecosistema de Meteor.js ecosistema y que ahora se ejecuta en Next.js y GraphQL. Soy miembro del Colectivo DevoGraphics creado por Sacha Gref, quien dirige las encuestas State of GS, CSS y GraphQL. Soy responsable en particular del formulario de encuesta donde realmente completas la encuesta y enseño Next.js en Human Coders, una empresa de enseñanza en Francia. Puedes encontrarme en Twitter o en Medium donde publico algunos artículos sobre varios temas, especialmente sobre Next.js y GraphQL.

2. Personalización y Renderizado

Short description:

Voy a hablar sobre personalización y explicar qué es el segmento en el renderizado segmentado. La personalización web incluye ejemplos como la tematización, la internacionalización, el contenido pago versus gratuito y las pruebas A-B. Next.js es un framework que ofrece tres formas de renderizar aplicaciones, incluido el renderizado del lado del cliente.

Voy a hablar sobre personalización para explicar qué es el segmento en el renderizado segmentado. Entonces, ¿qué es la personalización web? Tomemos un ejemplo. Elegir un tema es el ejemplo más básico y más visible de personalización web. Digamos que en mi aplicación tengo tres temas posibles: fuego, agua y hierba, y cada tema cambiará la apariencia de la aplicación. Para implementar la tematización, la mayoría de las veces usaré una cookie. Esto es muy común en la personalización web para almacenar información específica sobre el usuario en una cookie. ¿Por qué? Porque se envían automáticamente junto con cada solicitud y si no son solo HTTP, también están disponibles para el código javascript. Por lo tanto, son muy útiles para mantener información, para saber quién es el usuario. ¿Cuál es su segmento? ¿A qué categoría pertenecen, por ejemplo? Aquí podría tener una cookie llamada `starter` con tres valores posibles: fuego, agua y hierba. Y dependiendo del valor, por supuesto, elijo un tema diferente en la aplicación. Pero no es el único caso de uso. Hay muchos casos de uso de personalización web. Tenemos este mismo caso de uso, pero también la internacionalización. Es un caso de personalización que a veces olvidamos, pero cuando cambiamos el idioma de una aplicación para adaptarlo al idioma del usuario, estamos haciendo lo que llamamos personalización. Estamos optimizando el sitio web y la experiencia del usuario según sus características. El idioma que creemos que hablan o el idioma que seleccionaron en un menú. Esto es personalización. Tener contenido pago versus gratuito también es personalización, especialmente si solo tienes el comienzo de un artículo antes de llegar a un muro de pago. Esto es personalización en el sentido de que los usuarios no pagos tienen una experiencia diferente de los usuarios pagos. Los usuarios pagos tienen su contenido y se invita a los usuarios no pagos a suscribirse. Tienen una experiencia diferente, una experiencia personalizada, y pertenecen a diferentes segmentos: usuarios invitados y usuarios pagos. Las pruebas A-B también son un caso de uso muy importante, tal vez más avanzado, pero si obtienes mucho dinero de un sitio web, probablemente ya hayas configurado pruebas A-B porque te ayuda a probar nuevas versiones de tu sitio web de forma incremental sin afectar toda tu base de datos de usuarios. La mayoría de las veces tenemos dos segmentos que en realidad se llaman buckets en el entorno de pruebas A-B, A y B, y tienes dos versiones diferentes del sitio web A y B según este segmento.

Volvamos a nuestro caso de uso de renderizado de la cosa correcta. Hablemos de Next.js porque Next.js es un framework muy interesante cuando se trata de renderizar porque incorpora tres formas de renderizar aplicaciones. La primera es el renderizado del lado del cliente. Esta es la forma más común de renderizar contenido en aplicaciones modernas de JavaScript, en software como servicio, porque es muy dinámico. Ocurre en el navegador del usuario, por lo que puedes hacer muchos cálculos allí. Solo se utiliza JavaScript del lado del cliente y para obtener datos para llenar el contenido de la página, se utilizarán las funciones incorporadas del navegador, como Fetch, o bibliotecas que se basan en estas funciones incorporadas, como SWR en el ecosistema de Vercell.

3. Técnicas de Renderizado

Short description:

El renderizado del lado del servidor es lo opuesto al renderizado del lado del cliente. La generación de semillas estáticas es un punto intermedio que permite generar múltiples versiones de una página según los parámetros. El renderizado dinámico, como el renderizado del lado del cliente, permite actualizaciones en tiempo real pero requiere más cálculos. La generación estática, aunque no es adaptable a solicitudes individuales, es más rápida y puede ser tentadora para la personalización.

El renderizado del lado del servidor es lo opuesto. Se realiza todo en el servidor para cada solicitud. Esto se asemeja, por ejemplo, a cómo funciona PHP. Cuando haces una solicitud, se accede a una página que es una plantilla. En este punto, el servidor obtendrá algunos datos de la base de datos y llenará la plantilla con los valores correctos, y obtendrás tu página renderizada que se envía tal cual al navegador como HTML puro. Y tienes la generación de semillas estáticas, que se encuentra en el medio, que básicamente es solo renderizado del lado del servidor, pero no emparejado con la solicitud, sino calculado en el momento de la construcción. Es similar de alguna manera a simplemente escribir HTML. Podrías simplemente escribir la página. Pero, por supuesto, sería bastante tonto escribir el contenido directamente. Entonces, la generación de semillas estáticas te permite hacer esto a gran escala. Tienes la misma página y el generador de semillas estáticas puede generar múltiples versiones según algunos parámetros que ingreses, como el idioma, el tema, etc. Se dividen en dos categorías. La primera sería las formas dinámicas de renderizar contenido. El renderizado del lado del cliente y el renderizado del lado del servidor emparejado con la solicitud son dinámicos porque el renderizado del lado del servidor ocurre para cada solicitud. Por lo tanto, los datos pueden actualizarse cada vez que el usuario actualiza el navegador, al menos. El renderizado del lado del cliente es aún más dinámico porque puede ser interactivo, ya que opera en el navegador del usuario. Puede realizar cálculos en cualquier momento. Incluso ni siquiera tiene que comunicarse con el servidor. Entonces, la mayoría de las veces tienes este patrón, este patrón de llamadas a APIs para obtener nuevos datos y renderizar todo en el lado del cliente. Esta es una forma muy jam-stackish de hacer las cosas. La generación de semillas estáticas es, bueno, estática. Porque las cosas se calculan en el momento de la construcción, no pueden evolucionar para cada solicitud porque aún no tienes la solicitud. Nadie ha solicitado tu servidor, simplemente lo estás construyendo e implementando en este punto. Pero es más rápido porque las cosas ya están calculadas y almacenadas en una caché, por lo que no hay nuevos cálculos. El servidor solo tiene que servir el HTML calculado. Y ¿qué usarás para la personalización? Podrías estar tentado de decir patrones dinámicos porque pueden adaptarse a la solicitud porque pueden ocurrir en el navegador del usuario, literalmente en su máquina. Es más fácil adaptarse y personalizar para un usuario preciso, por supuesto. Sin embargo, son más lentos. Necesitan más cálculos. Entonces también tienes la opción de usar la generación estática, pero ¿cómo? Es más rápido, por lo que es

4. Renderizado Segmentado para Clientes Ricos

Short description:

El uso de renderizado dinámico y más lento para contenido personalizado crea un problema de clientes ricos y pobres. Los visitantes no pagados y los usuarios invitados reciben renders estáticos más rápidos, mientras que los clientes autenticados con contenido personalizado experimentan un renderizado más lento. El renderizado segmentado aborda este problema al permitir renders estáticos para contenido personalizado.

tentador. Pero ¿cómo? Nuevamente, dado que no se mueve, ¿cómo lo haces? Y el uso sistemático de la solución dinámica y más lenta conduce a un problema que llamo el problema de clientes ricos y pobres. Utilizarás los renders estáticos más rápidos solo para contenido público, para contenido que está disponible para cualquier persona que navegue por la web. Por lo tanto, visitantes no pagados, usuarios invitados, así como usuarios conectados. Y utilizarás los renders dinámicos más lentos para contenido personalizado. Utilizarás el tiempo de CPU de los usuarios si haces renderizado del lado del cliente. Tendrás una computación más lenta en el backend si haces solicitudes emparejadas con el renderizado del lado del servidor. Básicamente, tus clientes autenticados que reciben contenido personalizado basado en sus propios datos personales tienen el patrón más pobre, el patrón más lento. Ellos son clientes pobres, mientras que los invitados que a menudo proporcionan menos valor en el sitio web porque no están conectados, no los conoces, no puedes dirigirte a ellos, no son clientes, tienen la mejor experiencia. Son clientes ricos. Este es el problema de clientes ricos y pobres. Y el renderizado segmentado es una forma de reducir este problema al permitir renders estáticos para contenido personalizado y tener clientes ricos.

5. Personalización Estática y Servidor Proxy

Short description:

Hablemos sobre la personalización estática utilizando patrones de renderizado segmentado. La implementación más sencilla es tener una URL por segmento, una URL por elección de tema para los usuarios. Pero esto conlleva algunos problemas. Los usuarios no deberían poder saber en qué segmento se encuentran. La URL puede volverse larga y fea. Para resolver este problema, introduzcamos un servidor proxy simple y ligero.

Entonces hablemos sobre la personalización estática utilizando patrones de renderizado segmentado. Hagamos un primer intento, intentemos utilizar la URL para personalizar el contenido de forma estática. Es muy fácil porque la mayoría de los generadores de semillas estáticas se basan en la URL, ya sea Next.js, Gatsby, Astro, y así sucesivamente. Les proporcionas URLs para renderizar y, dependiendo del parámetro, buscarán los datos correctos y renderizarán la página en consecuencia. Así es como funcionan. Por lo tanto, la implementación más sencilla es tener una URL por segmento, una URL por elección de tema para los usuarios. Entonces los usuarios que eligieron el tema de fuego tendrán una versión, los que eligieron el tema de agua tendrán otra versión, y los que eligieron el tema de hierba tendrán otra versión. Pero esto conlleva algunos problemas. Primero, el usuario puede cambiar la URL. Está bien para un tema, está bien para un idioma. Incluso es una característica en cierto sentido para un idioma. Puedes cambiar el idioma de la página simplemente cambiando la URL. Pero es un problema si comienzas a hacer personalización con contenido de pago. No quieres que los usuarios cambien la URL para convertirse repentinamente en usuarios de pago. Preferirías que paguen por algo. Luego, el usuario puede ver el parámetro. Nuevamente, no es un problema para un idioma, incluso es algo bueno para un idioma porque permite compartir la URL con otras personas que hablan el mismo idioma y así obtienen el contenido correcto. Pero para una prueba A-B, eso es un gran problema. Los usuarios no deberían poder saber en qué segmento se encuentran. De lo contrario, estarías sesgando drásticamente la prueba A-B. Esto conlleva muchos problemas y los datos simplemente ya no son válidos. Por lo tanto, no deberían ver el parámetro en este caso. Y finalmente, la URL puede volverse larga y fea. Si tienes muchos parámetros, terminarás con el idioma, el tema oscuro o claro, el inquilino, la empresa, la organización a la que pertenecen los usuarios. Si estás haciendo negocios a nivel empresarial, es muy común tener multiarrendamiento. Tener múltiples empresas que utilizan tu aplicación con muchos usuarios por empresa. Tendrás el segmento de prueba A-B, que no es bueno, contenido de pago, y así sucesivamente. Tendrás URLs muy largas y feas. Entonces, para resolver este problema, esta limitación, introduzcamos una nueva pieza en nuestra arquitectura. Introduzcamos un servidor proxy simple y ligero.

6. Servidor Proxy y Reescritura de URL

Short description:

El servidor proxy reescribe la URL en función del segmento, haciéndola invisible para el usuario y protegiéndola de ser modificada. La longitud y apariencia de la URL ya no son un problema, y existen patrones avanzados para comprimir parámetros si es necesario.

El papel de este servidor proxy será tomar la solicitud HTTP que llega al servidor y reescribir la URL, dependiendo del segmento. Insisto en la palabra reescribir la URL, y no redirigir la URL. Una reescritura de URL no es visible para el usuario final, y esa es la diferencia clave, porque resuelve todos nuestros problemas con la URL de una vez. El usuario ya no puede ver el parámetro. El usuario ya no puede cambiar el parámetro, porque está protegido por el servidor, se calcula en el lado del servidor. Por lo tanto, el usuario no puede manipularlo simplemente cambiando los valores del navegador. Y finalmente, el hecho de que la URL sea larga y fea ya no es un problema, porque los usuarios ya no la ven. Puedes alcanzar la limitación de 255 caracteres para la URL, pero en la práctica esto nunca sucederá realmente. Y aún así tenemos más, incluso más patrones avanzados para solucionar eso. Está vinculado en el recurso y se llama Megaparam patrones. Básicamente, puedes codificar los parámetros para comprimirlos. Así que hay una solución incluso para este ligero

7. Renderizado Segmentado y Reescritura de URL

Short description:

Para resolver nuestro problema, convertimos la cookie en un parámetro de URL compatible con los frameworks existentes. Esto se llama renderizado segmentado, donde cada variación tiene una URL única. Por ejemplo, para la internacionalización, se puede utilizar el encabezado de aceptación de idioma para reescribir la URL al idioma correcto, eliminando la necesidad de un parámetro de idioma explícito. Los usuarios pueden cambiar el idioma utilizando una cookie invisible en lugar de un parámetro de URL visible.

limitación. Entonces, para resolver nuestro problema, tenemos una solicitud HTTP con la cookie fire y convertimos eso en un parámetro de URL fire, que es compatible con la forma en que funcionan los frameworks existentes porque Gatsby, NEFGS podrán renderizar contenido estáticamente siempre que la URL para cada variación sea única. Esto es lo que llamamos renderizado segmentado. Esta es una receta con dos ingredientes teniendo una URL por segmento. Así es como funciona el renderizado estático. Si genera múltiples variaciones de su sitio web estáticamente, ya está haciendo esto, pero el truco es usar un pequeño servidor de reescritura de URL para redirigir a la URL correcta según otros parámetros de la solicitud como las cookies o los encabezados. Si tomo otro ejemplo con internacionalización, podría usar el encabezado de aceptación de idioma y reescribir la URL al idioma correcto. Esto eliminaría la necesidad de tener un parámetro de idioma explícito. Aún necesita una forma para que los usuarios cambien el idioma, pero podría hacerlo utilizando una cookie que sea invisible en lugar de usar un parámetro de URL que sea visible y en algunos escenarios podría ser feo.

8. Implementación con Next.js

Short description:

Veamos una implementación con Next.js. Nuestra aplicación utiliza el renderizado segmentado para permitir a los usuarios elegir un tema. El tema se almacena en una cookie, lo que proporciona personalización sin alterar la URL. La página se renderiza estáticamente con el tema elegido y la respuesta del servidor confirma el tema correcto. La implementación involucra la generación estática de semillas y la regeneración estática incremental para mayor flexibilidad. El middleware, un servidor proxy ligero, lee la cookie del tema y escribe la URL. Esto logra el renderizado segmentado sin necesidad de un parámetro raíz.

Ok, esto puede sonar un poco abstracto. Ahora veamos una implementación con Next.js que es muy interesante porque permite que Next.js incorpore el concepto de middlewares de borde que son exactamente eso. El servidor proxy que necesitamos para implementar el renderizado segmentado. Ellos lo proporcionan de forma nativa. Así que aquí está nuestra aplicación utilizando el renderizado segmentado. Es una aplicación de Next.js que me permite elegir un tema: fuego, agua o hierba. Ok, elijamos el tema de fuego. Verás que cambia el color como se esperaba. La parte interesante es que no altera la URL. Primero, si voy a la aplicación y reviso las cookies, veré que estoy utilizando la cookie de tema llamada 'fire' en lugar de usar un parámetro raíz. Estoy utilizando una cookie, que es la forma correcta de hacer personalización en muchos escenarios. El segundo hecho interesante es que si recargo la página, obtendré la versión temática de inmediato. Por supuesto, todo esto se renderiza estáticamente, así que por ejemplo, si voy a la red y reviso la respuesta del servidor para la solicitud html, veré mi contenido con el tema correcto. Aquí no he configurado el CSS para el renderizado en el servidor, pero puedo ver el tema de fuego en el html. Así que estoy utilizando el renderizado estático. Esto se calcula en el lado del servidor avanzado, no hay cálculos en el lado del cliente.

En cuanto a la implementación, la primera parte es simplemente una página con generación estática de semillas como encontrarías en cualquier aplicación de Next.js utilizando 'getStaticPaths' y 'getStaticProps' como de costumbre. Genero diferentes versiones de la página dependiendo del parámetro de tema. Observa que estoy utilizando la regeneración estática incremental, que es solo un patrón en Next para entender cómo manejar el caso en el que tengo muchos temas. Por ejemplo, aquí no estoy pre-renderizando el tema verde porque tal vez es menos solicitado por las personas y no quiero tener un tiempo de compilación muy largo, por lo que solo se calculará en la primera solicitud. Tenemos mucha flexibilidad con este enfoque. Y luego, por supuesto, renderizo mi página en función de este parámetro. Esto es muy común si usas Next.js o cualquier otro framework de renderizado estático, estarás acostumbrado a este enfoque. Pero la parte más importante es el middleware. Este es mi servidor proxy. Y cuando digo pequeño y ligero, no estoy bromeando. Son 25 líneas con muchos comandos. Lo que hace es leer las cookies. Si es un tema válido, escribirá la URL. Así de simple. Así es como obtengo el renderizado segmentado, renderizado estático con personalización sin

9. Renderizado en el servidor invisible y el futuro

Short description:

Esta parte discute la seguridad y los beneficios del renderizado en el servidor invisible para temas personalizados. También menciona el ejemplo de implementación y el uso del renderizado segmentado en el borde. La conclusión destaca la importancia del almacenamiento en caché en el renderizado en el servidor y sugiere una API unificada futura para el renderizado en el servidor.

El uso de un parámetro raíz. Esto es invisible para el usuario y es seguro porque ocurre en el lado del servidor. No puedo permitir que el usuario elija un tema que no existe, por ejemplo. Solo pueden seleccionar fuego, agua, hierba o ninguno. De lo contrario, lanzo un error. Esto es seguro. Es excelente para contenido de pago, por ejemplo, pruebas A-B. Finalmente, solo un detalle, pero eso es opcional, he agregado cierta lógica para cambiar el tema basado en una cookie utilizando una raíz de API. Entonces, estoy utilizando el encabezado HTTP de configuración de cookie, pero podrías hacer lo mismo en el lado del cliente, por supuesto. Volvamos a mis diapositivas. Ahora tienes un ejemplo de implementación, y en Vercel, es posible que haya una terminología diferente. No lo llamarán renderizado segmentado. Lo llamarán personalización en el borde. Y en realidad, es la traducción de Vercel de este patrón. Es lo mismo, excepto que Vercel te permite tener renderizado segmentado en el borde utilizando su red de borde. Pero es básicamente la misma idea. Breve conclusión. ¿Cuál es el futuro del renderizado en el servidor? Creo que el futuro del renderizado en el servidor es comprender que todo se trata del almacenamiento en caché. Lo estático es el renderizado en el servidor almacenado en caché en el momento de la compilación. El renderizado en el servidor por solicitud es simplemente una falta de caché en el mismo patrón. La clave de caché no es solo la URL, sino la solicitud completa. Esta es la idea detrás del renderizado segmentado, utilizar la solicitud y no solo la URL. Y el valor es, por supuesto, el HTML renderizado o los datos. Depende del patrón. El renderizado estático diferido de Gatsby, por ejemplo, desvincula ambos y Next.js siempre los considera como un todo. Están muy relacionados en Next, pero de cualquier manera, ese es el valor de caché. Entonces, mi opinión es que en el futuro, tendremos una API unificada para el renderizado en el servidor que abarque el renderizado estático, por solicitud y todo lo que haya en el medio. Y hasta entonces, tenemos el renderizado segmentado. Gracias por su atención y nos vemos más tarde.

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!
Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Top Content
Do you have a large product built by many teams? Are you struggling to release often? Did your frontend turn into a massive unmaintainable monolith? If, like me, you’ve answered yes to any of those questions, this talk is for you! I’ll show you exactly how you can build a micro frontend architecture with Remix to solve those challenges.
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.

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