Dominik Dorfmeister

React Query is a popular library for maintaining asynchronous state - most often state returned from data fetching. It has grown so much in popularity over the last couple of years that it is now used in almost 20% of all React applications. To some extent, this is attributed to it's ease of use and great developer experience.
In this talk, React Query maintainer Dominik will walk us through some of the API design choices that were made in React Query to get to that DX. You'll hear stories about things that went well, but also about tradeoffs and mistakes that were made, and what lessons we can all learn from those.

React Query is a popular library for managing asynchronous state—most often state returned from data fetching. Its popularity has grown significantly over the past few years, with nearly 20% of all React applications now using it.
In this talk, maintainer Dominik will explore the other side—the less favorable aspects of React Query and situations where it may not be the best fit. No library is perfect; every choice involves trade-offs. By the end of this talk, you'll have a better understanding of React Query's limitations and why it remains a compelling choice despite them.

In this talk, I'll explain React Query from a different perspective. After having maintained React Query for over two years and having answered many questions (often the same ones multiple times), I feel like there might be a fundamental understanding missing about the lib. I'll start with a quick introduction about my journey into open source and how I got to know React Query, followed by showing which mindset change is beneficial when working with React Query - how to "think in React Query". I'll have 3 major takeaways: 1) React Query is not a data fetching library It's an async state manager, we'll quickly talk about what makes a state manager, why React Query is one and what "async state" means. 2) staleTime is your best friend I've seen a bit of confusion about how to use React Query as a state manager, so I'll explain why setting staleTime is mostly all you need 3) parameters are dependencies This is important to understand to show the boundaries between client state and server state, and is essential when doing state management with React Query I will then end with a note on "separation of concerns" and about the tradeoffs of just calling `useQuery` wherever you need it in your component tree.