Pensando en React Query

Spanish audio is available in the player settings
Rate this content
Bookmark
Slides

En esta charla, explicaré React Query desde una perspectiva diferente. Después de haber mantenido React Query durante más de dos años y haber respondido muchas preguntas (a menudo las mismas varias veces), siento que puede haber una comprensión fundamental que falta sobre la librería. Comenzaré con una breve introducción sobre mi trayectoria en el código abierto y cómo conocí React Query, seguido de mostrar qué cambio de mentalidad es beneficioso al trabajar con React Query - cómo "pensar en React Query".

Tendré 3 puntos principales:

1) React Query no es una librería de obtención de datos. Es un gestor de estado asíncrono, hablaremos rápidamente sobre qué hace un gestor de estado, por qué React Query es uno y qué significa "estado asíncrono".

2) staleTime es tu mejor amigo. He visto un poco de confusión sobre cómo usar React Query como gestor de estado, así que explicaré por qué establecer staleTime es casi todo lo que necesitas.

3) los parámetros son dependencias. Es importante entender esto para mostrar los límites entre el estado del cliente y el estado del servidor, y es esencial cuando se hace gestión de estado con React Query. Luego terminaré con una nota sobre la "separación de preocupaciones" y sobre los compromisos de simplemente llamar a `useQuery` donde lo necesites en tu árbol de componentes.

22 min
06 Jun, 2023

Video Summary and Transcription

React Query no es una librería de obtención de datos, sino un gestor de estado asincrónico. Ayuda a mantener los datos actualizados y a gestionar eficientemente los ciclos de vida de los agentes. React Query proporciona suscripciones detalladas y permite ajustar el tiempo de obsolescencia para controlar el comportamiento de obtención de datos. Definir el tiempo de obsolescencia y gestionar las dependencias son aspectos importantes al trabajar con React Query. Utilizar la URL como gestor de estado y Zustand para gestionar filtros en React Query puede ser poderoso.

Available in English

1. Introducción a React Query y Conceptos Erróneos

Short description:

La mayoría de las personas no saben que hay una forma correcta e incorrecta de atarse los zapatos. Al trabajar con React Query, muchas preguntas mostraron un concepto erróneo subyacente de lo que es o hace React Query. React Query no es una biblioteca de obtención de datos. No realiza ninguna obtención de datos por ti. La función de consulta solo se preocupa si estás devolviendo una promesa cumplida o rechazada.

Hola a todos. Gracias por estar aquí hoy, donde quiero hablar sobre cómo atarse los zapatos correctamente. La mayoría de las personas no saben que hay una forma correcta e incorrecta de atarse los zapatos. Ambas formas se ven muy similares a primera vista, pero un nudo es estable y el otro se afloja a medida que caminas. Es una pequeña diferencia que podría cambiar tu vida. Sigue atento hasta el final mientras te muestro ese truco.

Al trabajar con React Query, podríamos enfrentar situaciones similares, donde un pequeño ajuste puede marcar una gran diferencia. Descubrí esto cuando comencé mi viaje de código abierto en 2020, donde principalmente ayudaba interactuando con la comunidad. Respondí muchas preguntas en diferentes plataformas, lo cual fue una excelente manera de comenzar en el código abierto. Resulta que las personas están realmente felices y agradecidas si les ayudas a resolver su problema. También aprendí mucho al tener que analizar situaciones que no había encontrado antes. Con eso, llegué a conocer muy bien React Query y fue entonces cuando me di cuenta de un patrón común entre esas preguntas. Muchas de ellas mostraban un concepto erróneo subyacente de lo que es o hace React Query y probablemente se responderían con un pequeño cambio de pensamiento.

Me llamo Dominik y soy un ingeniero de software de Viena. En línea, me conocen como TK-Dodo en casi todas partes. Trabajo como líder técnico de frontend en Edverity y también he tenido el privilegio de mantener la biblioteca de código abierto React Query durante los últimos dos años. Así que hoy, lo que realmente quiero hablar es mostrarte tres formas simples de cómo abordar React Query con una mejor mentalidad. Al igual que atarse los zapatos correctamente, una vez que lo sabes, espero que tenga mucho sentido y sea bastante simple de seguir. Así que echemos un vistazo a lo que se necesita para pensar en React Query.

El primer punto puede sorprenderte, pero es cierto. Aunque a menudo se describe como la pieza que falta para la obtención de datos en React, React Query no es una biblioteca de obtención de datos. No realiza ninguna obtención de datos por ti, porque si echamos un vistazo rápido a un ejemplo estándar de React Query, podemos ver que necesitamos proporcionar dos cosas al gancho UseQuery. Una clave de consulta única, donde React Query almacenará los datos para nosotros, y una función de consulta que se ejecutará cada vez que se deban recuperar los datos. Luego, por supuesto, podemos usar ese gancho en un componente para renderizar los datos y los diversos estados en los que puede estar la consulta. Pero si echamos un vistazo rápido a la función de consulta nuevamente, podemos ver que en este ejemplo, está implementada con Axios, porque ¿por qué no? Pero el punto es que esa es tu biblioteca de obtención de datos. A esa consulta no le importa cómo lo hagas. Lo único que le importa es si estás devolviendo una promesa cumplida o rechazada. De hecho, y esto probablemente sea yo hablando como mantenedor de la biblioteca, si presentas un problema diciéndome que no puedes mostrar una reproducción porque tu API es privada, probablemente te diré que esta es la forma más sencilla de implementar la función de consulta. No hay obtención de datos en absoluto. Lo único que estamos haciendo es devolver una promesa resuelta.

2. React Query: Obtención de datos y Gestión de estado

Short description:

React Query no obtiene datos, es un gestor de estado asiático. El estado se divide por tipo, no por dónde se utiliza. React Query ayuda a mantener los datos actualizados y gestionar los ciclos de vida de los agentes. Es una herramienta especializada para el trabajo. React Query hace que el estado esté disponible de manera eficiente.

Por supuesto, React Query funciona muy bien con bibliotecas de obtención de datos como Axios, Fetch o GraphQL Request porque todas ellas producen promesas. Una vez que entendemos que React Query no obtiene datos, esperamos que quede claro que toda una clase de preguntas sobre la obtención de datos desaparecen. Preguntas como ¿cómo puedo definir una URL base con React Query? ¿Cómo puedo acceder a los encabezados de respuesta con él? ¿O cómo puedo hacer solicitudes GraphQL con React Query? Todas las preguntas sobre la obtención de datos suelen tener la misma respuesta. A React Query no le importa. Solo devuelve una promesa de alguna manera, por favor.

Bien, una vez que entendemos que React Query no es una biblioteca de obtención de datos, es justo preguntar, ¿entonces qué es? Mi respuesta a esta pregunta siempre ha sido un gestor de estado asiático. Ahora es importante entender lo que queremos decir con estado asiático. Tanner Lindsley, el creador de React Query, dio una gran charla en mayo de 2020 llamada `Es hora de romper con tu estado global`. La charla sigue siendo muy relevante hoy en día, así que por favor mírala si aún no lo has hecho. La esencia de la charla es que durante mucho tiempo hemos dividido nuestro estado en función de dónde lo necesitamos que viva. ¿Solo lo necesitamos en un componente? Probablemente comencemos usando estado local. ¿Lo necesitamos disponible más arriba en el árbol? Entonces lo movemos hacia arriba y potencialmente pasamos los datos de nuevo como props. ¿Lo necesitamos aún más arriba o en todas partes de nuestra aplicación? Probablemente lo movamos a un gestor de estado global, como Redux o Zustand, que vive fuera de React y luego lo distribuye globalmente en nuestra aplicación. Y hemos estado haciendo esto para todo tipo de estado, sin importar si es el botón de alternancia que estamos haciendo clic en nuestra aplicación, o la lista de problemas que tenemos que obtener a través de la red. Los hemos tratado a todos exactamente de la misma manera. El cambio de pensamiento se produce cuando dividimos el estado de manera diferente. No por dónde se utiliza, sino por qué tipo de estado es. Porque el estado que poseemos por completo, que está disponible de forma síncrona y siempre está actualizado, como cuando hago clic en ese botón de alternancia de modo oscuro, tiene necesidades totalmente diferentes al estado que se persiste de forma remota y está disponible de forma asíncrona, como una lista de problemas. Con el estado envejecido o el estado del servidor, solo vemos una instantánea en el momento en que lo obtuvimos. Puede estar desactualizado porque no somos los únicos propietarios de ese estado. El backend, probablemente nuestra base de datos, es el propietario. Solo lo hemos tomado prestado para mostrar esa instantánea. Puedes darte cuenta de esto cuando dejas una pestaña del navegador abierta durante algún tiempo y luego vuelves a ella. ¿No sería agradable ver automáticamente datos frescos y precisos? Eso significa que tenemos que mantenerlo actualizado de alguna manera porque otros usuarios también pueden realizar cambios en el ínterin. Y debido a que el estado no está disponible de forma síncrona, también es necesario gestionar la información meta alrededor de ese estado, como los estados de carga y error. Por lo tanto, mantener tus datos actualizados automáticamente y gestionar los ciclos de vida de los agentes no es algo que obtendrías o necesitarías de un gestor de estado general tradicional. Pero como tenemos una herramienta orientada al estado del agente, podemos hacer que todo eso suceda y más. Solo necesitamos usar la herramienta adecuada para el trabajo adecuado.

La segunda parte que debemos entender es qué es un gestor de estado y por qué React Query es uno. Lo que suelen hacer los gestores de estado es hacer que tu estado esté disponible en tu aplicación de manera eficiente.

3. Eficiencia y Suscripciones Detalladas

Short description:

La eficiencia es crucial cuando se trata de actualizaciones en React Query. Redux y Zustand ofrecen APIs basadas en selectores para asegurar que los componentes solo se suscriban a cambios relevantes en el estado. React Query proporciona suscripciones detalladas a través de claves de consulta y selectores. Al utilizar los hooks adecuados, podemos acceder a los datos sin necesidad de soluciones adicionales de gestión de estado.

La parte importante aquí es la eficiencia. Dicho de otra manera, podríamos decir que queremos actualizaciones, por favor, pero no demasiadas. Si demasiadas actualizaciones no fueran un problema, simplemente colocaríamos nuestro estado en el contexto de React. Pero es un problema real y muchas bibliotecas intentan resolverlo de diversas formas, algunas más mágicas que otras.

Redux y Zustand, dos soluciones populares de gestión de estado, ofrecen APIs basadas en selectores. Estas se aseguran de que nuestros componentes solo se suscriban a las partes del estado en las que están interesados. Si otras partes del almacenamiento se actualizan, a esos componentes no les importa. El principio es que podemos llamar a esos hooks en cualquier lugar de nuestra aplicación para acceder a ese estado, porque las bibliotecas lo hacen globalmente disponible.

Ahora con React Query, realmente no es tan diferente. Excepto que la parte a la que te suscribes está definida por la clave de consulta. Ahora, dondequiera que llamemos a nuestro hook personalizado de problemas, obtendremos actualizaciones si algo cambió en la sección de problemas de la caché de consultas. Y si eso no es suficiente, podemos llevar esto un paso más allá porque React Query también tiene selectores. Ahora estamos hablando de suscripciones detalladas, donde los componentes solo están interesados en los resultados calculados o derivados de lo que está almacenado. Si cambiamos el estado de un problema de abierto a cerrado, el componente que utiliza el hook useIssueCount no se volverá a renderizar porque la longitud no ha cambiado. Y al igual que con otros gestores de estado, podemos y muy probablemente deberíamos llamar a useQuery donde sea necesario para acceder a esos datos. Esto hace que todas las soluciones que intentan ciertas cosas, como llamar a useEffect para sincronizar los datos de React Query en otro lugar o establecer los datos en el estado local en la devolución de llamada de éxito, sean antipatrones. Todas estas son formas de sincronización de estado que eliminan la única fuente de verdad y son innecesarias porque React Query ya es un gestor de estado. Por lo tanto, no necesitamos poner ese estado en otro estado.

4. ReactQuery: Fetching and Stale Time

Short description:

Cuando se utiliza ReactQuery, pueden producirse múltiples solicitudes al mismo punto final, especialmente si los componentes se representan de forma condicional o tienen consultas dependientes. ReactQuery volverá a solicitar automáticamente las consultas en función de ciertos desencadenantes, como el enfoque de la ventana, el montaje del componente, la recuperación de la conexión de red y el cambio de clave de consulta. Sin embargo, solo lo hará para las consultas que se consideren obsoletas. El tiempo de obsolescencia, que define el tiempo hasta que los datos se vuelvan obsoletos, se puede ajustar para controlar este comportamiento. De forma predeterminada, el tiempo de obsolescencia se establece en cero milisegundos, lo que marca todo como obsoleto instantáneamente. La definición del tiempo de obsolescencia depende de sus recursos y necesidades.

Vale, puede que estés pensando, ahora estoy haciendo esto y llamando a useQuery donde sea necesario. Tengo tres componentes, llamo a useIssues tres veces. Pero si algunos de nuestros componentes se representan de forma condicional, como al abrir un diálogo, o porque tenemos consultas dependientes, es posible que comencemos a ver muchas solicitudes al mismo punto final.

Puede que estés pensando, ah, acabo de solicitar esto hace dos segundos. ¿Por qué ya se está solicitando de nuevo? Así que recurres a la documentación y comienzas a desactivar todo en todas partes y de una vez, solo para no saturar tanto tu backend. Tal vez deberíamos haber puesto nuestros datos en Redux después de todo. Aguanta un segundo porque hay cierta lógica en esta locura.

¿Por qué ReactQuery está haciendo todas esas solicitudes? Nos lleva de vuelta a las necesidades del estado asíncrono. Puede estar desactualizado. Así que queremos actualizarlo en algún momento. Y ReactQuery lo hace mediante ciertos desencadenantes. Enfoque de la ventana, montaje del componente, recuperación de la conexión de red y cambio de clave de consulta. Cada vez que ocurre uno de estos eventos, ReactQuery volverá a solicitar automáticamente esa consulta. Pero eso no es toda la historia. ReactQuery no lo hará por todas las consultas. Solo por aquellas que se consideren obsoletas.

Y esto nos lleva al segundo punto importante del día. El tiempo de obsolescencia es tu mejor amigo. Porque ReactQuery también es una herramienta de sincronización de datos. Pero eso no significa que volverá a solicitar todas las consultas en segundo plano sin más. Este comportamiento se puede ajustar mediante el tiempo de obsolescencia, que define el tiempo hasta que los datos se vuelvan obsoletos. Lo opuesto a obsoleto es fresco. Dicho de otra manera, mientras los datos se consideren frescos, se nos proporcionarán desde la caché sin una nueva solicitud. De lo contrario, obtendremos los datos de la caché y una nueva solicitud. Por lo tanto, solo las consultas obsoletas se actualizarán automáticamente. Pero el tiempo de obsolescencia se establece en cero de forma predeterminada. Sí, cero como en cero milisegundos, por lo que ReactQuery marca todo como obsoleto instantáneamente. Eso ciertamente es agresivo y puede provocar un exceso de solicitudes. Pero en lugar de optar por minimizar las solicitudes de red, ReactQuery se inclina por mantener las cosas actualizadas. Ahora, la definición del tiempo de obsolescencia depende de ti. Depende en gran medida de tus recursos y necesidades.

5. Defining Stale Time and Managing Dependencies

Short description:

No hay un valor correcto para el tiempo de obsolescencia en React Query. Depende del caso de uso específico. Definir el tiempo de obsolescencia es una parte importante de trabajar con React Query. Los parámetros deben tratarse como dependencias y agregarse a la clave de consulta. Esto garantiza un almacenamiento en caché separado, permite la actualización automática y evita problemas con cierres obsoletos. React Query se encarga de gestionar las dependencias de las consultas que existen en partes específicas de la pantalla.

No hay un valor correcto para el tiempo de obsolescencia. Si estás consultando la configuración que solo cambiará cuando se reinicie el servidor, un tiempo de obsolescencia infinito puede ser una buena opción. Por otro lado, si tienes una herramienta altamente colaborativa donde varios usuarios actualizan cosas al mismo tiempo, es posible que estés satisfecho con un tiempo de obsolescencia cero. Por lo tanto, una parte muy importante de trabajar con React Query se basa en definir el tiempo de obsolescencia. Una vez más, no hay un valor correcto. Lo que me gusta hacer es establecer un valor predeterminado a nivel global y luego anularlo si es necesario.

Vale, volvamos rápidamente a las necesidades del estado asíncrono una vez más. Sabemos que React Query mantiene nuestra caché actualizada si los datos se consideran obsoletos y ocurre uno de estos eventos. El evento que probablemente sea el más importante de todos y en el que quiero centrarme es el cambio de clave de consulta. ¿Cuándo ocurriría principalmente ese evento? Bueno, eso nos lleva al último punto. Debemos tratar los parámetros como dependencias. Realmente quiero enfatizar esto, aunque ya esté explicado en la documentación y también tenga una publicación de blog al respecto. Si tienes parámetros, como los filtros en este ejemplo, que deseas usar dentro de tu función de consulta para hacer una solicitud, debes agregarlos a la clave de consulta. Esto garantiza muchas cosas que hacen que sea excelente trabajar con React Query. En primer lugar, asegura que las entradas se almacenen en caché por separado, según su entrada. Entonces, si tenemos diferentes filtros, los almacenamos en diferentes claves de caché, lo que evita condiciones de carrera. También permite actualizaciones automáticas cuando esos filtros cambian, porque pasamos de observar una entrada de caché a la otra. También evita problemas con cierres obsoletos, que suelen ser difíciles de depurar. Esto es tan importante que hemos lanzado nuestro propio complemento de ESLint. Puede verificar si estás usando algo dentro de la función de consulta y te indica que lo agregues a la clave. También se puede corregir automáticamente, así que te recomiendo que lo uses. Si quieres, puedes pensar en la clave de consulta como el array de dependencias para useEffect, pero sin las desventajas, porque no tenemos que preocuparnos por la estabilidad referencial en absoluto. No es necesario usar useMemo o useCallback aquí. Ni para la función de consulta ni para la clave de consulta, porque React Query se encargará de esto automáticamente.

Por último, esto puede presentar un nuevo problema. Ahora estamos usando useQuery donde sea necesario en nuestra aplicación, pero ahora tenemos dependencias en nuestra consulta que solo existen en una parte específica de la pantalla. ¿Qué pasa si no tengo acceso a los filtros donde quiero llamar a useIssues? ¿De dónde viene? La respuesta nuevamente es que a React Query no le importa. Es un problema de gestión de estado del cliente puro, porque esos filtros aplicados son estado del cliente y cómo los gestionas depende de ti. Aún puedes usar el estado local o un administrador de estado global según consideres adecuado.

6. Using URL and Zustand for State Management

Short description:

Usar la URL como un administrador de estado es una buena idea. Zustand se puede utilizar para gestionar los filtros en React Query. Se pueden componer hooks personalizados para separar el estado del servicio y el estado del cliente. Actualizar el filtro en el almacenamiento desencadena ejecuciones automáticas de consultas o lecturas de caché, lo que convierte a React Query en un potente administrador de estado de agente.

Tal vez escribirlo en la URL y usar eso como un administrador de estado también sea una buena idea. Como ejemplo, veamos cómo podría verse esto si hemos puesto los filtros en un administrador de estado como Zustand. Lo único que hemos cambiado es en lugar de pasar los filtros como entradas a nuestro hook personalizado, lo obtenemos directamente del almacenamiento. Esto muestra el poder de la composición al escribir hooks personalizados. Y podemos ver la clara separación entre el estado del servicio gestionado por useQuery y el estado del cliente, en este caso gestionado por useStore. Cada vez que actualizamos el filtro en el almacenamiento, sin importar dónde, la consulta se ejecutará automáticamente o leerá los últimos datos de la caché, si están disponibles. Este patrón nos permitirá usar React Query como un verdadero administrador de estado de agente. Ahora, para resumir, React Query no es una biblioteca de obtención de datos. Es un administrador de estado de agente. El tiempo de obsolescencia es tu mejor amigo, pero debes configurarlo según tus necesidades. Y debemos tratar los parámetros como dependencias y usar nuestra regla de lint para hacer cumplir esto. Si cambiamos nuestra forma de pensar siguiendo estos tres puntos, tendremos un tiempo aún mejor trabajando con React Query. Al igual que un pequeño ajuste en cómo nos atamos los zapatos puede ser una gran mejora en la calidad de vida. Ahora, todavía te debo la solución para atar tus zapatos correctamente. Es realmente muy simple. Al crear el lazo, asegúrate de tirar del cordón hacia ti primero, luego pásalo por el hueco. Esta pequeña diferencia dará como resultado un nudo que se mantendrá horizontal y no se aflojará tan fácilmente. También hay un video en YouTube si quieres ver eso. Así que eso es todo lo que tengo. Gracias por escuchar. Asegúrate de seguirme en Twitter y suscribirte a mi blog. La versión 5 de React Query está a la vuelta de la esquina, y esta es una buena manera de mantenerse actualizado. Gracias.

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!
Vue.js London Live 2021Vue.js London Live 2021
34 min
Everything Beyond State Management in Stores with Pinia
Top Content
When we think about Vuex, Pinia, or stores in general we often think about state management and the Flux patterns but not only do stores not always follow the Flux pattern, there is so much more about stores that make them worth using! Plugins, Devtools, server-side rendering, TypeScript integrations... Let's dive into everything beyond state management with Pinia with practical examples about plugins and Devtools to get the most out of your stores.
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