React Query: It’s Time to Break up with your "Global State”!

Rate this content

An increasing amount of data in our React applications is coming from remote and asynchronous sources and, even worse, continues to masquerade as "global state". In this talk, you'll get the lowdown on why most of your "global state" isn't really state at all and how React Query can help you fetch, cache and manage your asynchronous data with a fraction of the effort and code that you're used to.

30 min
02 Aug, 2021

AI Generated Video Summary

Global state management and the challenges of placing server state in global state are discussed. React Query is introduced as a solution for handling asynchronous server state. The Talk demonstrates the process of extracting logic into custom hooks and fixing issues with state and fetching logic. Optimistic updates with mutation are showcased, along with the benefits of using React Query for data fetching and mutations. The future of global state management is discussed, along with user feedback on React Query. The Talk concludes with an invitation to explore React Query for server state management.

1. Introduction to Global State Management

Short description:

Hi, I'm Tanner Linsley, co-founder and VP of UI and UX at Today, I want to talk about global state management and the mistake of placing server state in global state. Server state is different from client state in terms of storage, access speed, and ownership. Let's explore why and how we can handle server state more effectively.

Hi everyone. My name is Tanner Linsley, and I'm a co-founder and VP of UI and UX at, where we build SEO rank tracking software for enterprise. I absolutely love React and JavaScript, and I have a bit of an obsession for building open source software as well.

So since learning React, I've been super obsessed with topics like static site generation, data visualization, and animation. But today I'd like to talk to you about what is possibly my favorite one of all, global state management.

Today, a ton of code in our applications is dedicated to consuming and manipulating asynchronous data. Whether that data comes from our users or servers or third party APIs, it's absolutely critical for our apps to provide value to our users. In fact, for a lot of us, our applications are just opinionated user interfaces for consuming and managing this data.

Over the years, I've noticed that patterns around accessing and manipulating our data in our applications have quickly taken up residence with what we all know as global state. Global state is super convenient. It helps us avoid prop drilling, and it lets us access data across our application without copying or duplicating it. And it even helps us communicate between isolated components and hooks that otherwise wouldn't be able to. In the end, it just helps us do more with less code. It's extremely accessible and powerful, so it's only natural that we would want all of our important server side data to be just as accessible as our global state. And with that expectation, it's no surprise that we as React developers have chosen to co-locate our server side data with the rest of our global state.

It's relatively easy to do this by using something like local component state with React context, or even by using any number of libraries from the ever-growing list of global state management tools out there. But in the end, the expectation is usually the same. We expect our global state not only to be able to handle trivial things like menu state, themes, things like toasts and alerts, but we also expect it to be responsible for complex life cycles around fetching and providing our server side and asynchronous data to our users.

So today, I'm here to tell you that despite the fleeting convenience global state gives us when working with server side data, I think we've made a really big mistake by placing it there. We've tricked ourselves and our code into thinking that all state is created equal, when I think our asynchronous data and global state could not be more different, especially when it comes to where they're stored, the speed at which we access them, and how we access and update them, and ultimately who can make changes to them.

To make all this easier to understand, I want to stop using the term global state and instead call these two different types of state client state and server state. Client state is relatively simple and should be familiar to most developers. It's temporary and local, and it's generally not persisted between sessions. It's accessed with synchronous APIs that don't have any latency, and most of it is owned by our client's application instance. So for all those reasons, we can pretty much rely on our client state always being up to date at any given time in our application.

Server state, however, is pretty different. Server state is persisted remotely, so the location source of truth for our server state is potentially unknown, or at least outside of our control. It's asynchronous, so we have to access it with asynchronous APIs, and it also has implied shared ownership, which means that it's not just owned by our client. It can be read and manipulated by both the server and any other potential clients that interact with it. Because of all these things, very few guarantees can actually be made around our server state always being up to date in our apps, and instead we usually end up relying on just snapshots of our async data.

2. Server State and Client State

Short description:

When server state and client state are stored in the same system, tradeoffs are made. Server state has unique challenges that require dedicated tools. React Query is an NPM library that solves asynchronous server state with a small, simple API. To demonstrate its capabilities, I built a blog application with React and Next.js. The app allows viewing, editing, and adding posts. Initially, the app had four main components, each using useEffect and React State for data fetching and loading states. However, I wanted to make the code more portable.

So when we take these two very different types of state, server state and client state, and try and store them in the same system, we'll eventually make tradeoffs that favor one or the other. A good example of this is that server state has its own unique challenges that we never face with client state. For example, a few of these might be things like caching, deduping requests, updating data in the background, dealing with outdated requests, dealing with mutations, pagination and incremental fetching, or even garbage collection, error memory management, and everything else that comes with caching in general. Many global state patterns don't offer solutions for these kinds of challenges, or at the very least attempt to solve them with complicated APIs or overengineered plugin systems, and sometimes even overpowered APIs that are basically foot guns for the average React developer.

Server state and client state clearly both need plenty of love, but they each need it in their own way. And while I think they have a few things in common when it comes to how we access them in our apps, I think it's time for server state and client state to break up. There is way more to server state than just being globally accessible, and I think it deserves new dedicated tools that not only solve these challenges, but automatically handle them in an elegant way. This is exactly why I decided to build React Query. React Query is an NPM library comprised of a couple hooks and utilities that aim to solve asynchronous server state. It's a small API, it's simple, and it's designed to help both novice and advanced React developers be successful while requiring little to zero configuration.

To really know how React Query can drastically transform the way you handle server state, I decided to build a small interactive blog application using React and a little API powered by Next.js. So the purpose of this application is pretty simple. It's to show a list of posts, it lets us look at a detailed view of an individual post, and then it allows us to edit existing posts or add new ones as well. I'm going to navigate through a few stages or commits that I made to this project of how this application's state management evolved in the wild and how, in the end, I finally got to use React Query to save the day.

So first, let's just get familiar with the app. We have a trusty sidebar with a single link into our post page. We have a post page that fetches all of our posts from our API and displays them in a list. We can click on a post and load the detailed view with the full content. We can use the edit form at the bottom to edit the post. And then back on our post list, we can use that same form to add a new post to the list. So to do all of this, our app started out with four main components. An app component, which handles all of our routing and routing state. A post component, which fetches our posts from the API and then displays them with the add new post form underneath them. An individual post component that fetches the full content for a post and renders it and then gives us the edit form at the bottom. And then finally, we have a reusable post form component that just is for editing the post fields. So in each of these post components, right now we're just using a use effect strategy to call an asynchronous function and fetch our data. And then we use React State to keep track of the loading states for those requests. This way, when we mount each of those components, the data gets requested and eventually gets rendered in our UI. And all of this is fine and it works, but I personally don't like having a lot of business logic in my components. So I want to see if we can make this a bit more portable.

3. Extracting Logic into Custom Hooks

Short description:

In the next commit, I've extracted the logic for fetching data into custom hooks. This allows us to reuse the hooks throughout our app. However, we're experiencing a problem where the post endpoint is being called twice. This is because every time we use the hook, a new instance of state and effects is created, resulting in duplicate requests for data.

In this next commit, I've extracted all of the logic for fetching our data and put them into their own custom hooks. So the use posts and use post files now contain all of the same logic and state for fetching our post lists and post detail, but just combined into a custom hook. And then I've also moved all the logic for our mutations into some new files called use create post and use save post that work in a similar way. So this frees up our components from needing to define all the logic themselves and just focus on rendering the UI, which in my opinion is a great pattern regardless of how you manage your state.

So now that we have our fetching logic inside of these reusable hooks, we can use them again anywhere else in our app that we want. Also in this commit, I added a handy little total posts count in our sidebar that calls the same use posts hook again to show a total count of posts. So with all of this abstraction, it might seem like a big win for code reuse. But if we look at our network tab, we're going to see something weird is happening. Our post endpoint is being called twice, once for the post list and again for the total post counter. Even though we haven't extracted the state into, even though we have extracted the state into reusable hooks, it doesn't really mean that the data inside them is itself reusable. The real reason this is happening actually is because every time we use our use posts hook, we're creating a new instance of state and effects for every time that we render it. So if we keep this up, we're going to be double requesting a ton of data for our app over and over again every time that we use that hook.

4. Fixing State and Fetching Logic

Short description:

In the next commit, I'll show you how to fix the issue by turning state and fetching logic in our hooks into global components that are rendered once for the entire app. By creating a root component for the post list and moving the fetching logic there, we can have a single location for fetching the post list. We'll use a context object to pass the state and logic down the component tree, allowing our use posts hook to access the global post list. Let's see if this solves our problem.

In this next commit, I'm going to show you how I try and fix that by turning some of the state and fetching logic in our hooks into global components that only get rendered once for the entire app. So I've created a root component for our post list and moved all the fetching logic into that component. This way we have a single location where our post list fetching can happen for our entire app as long as we render it at the root and only render it once. Since we can only render it once, we have to take all that state and logic and send it down our React component tree through a context object. This way in our use posts hook, we can subscribe to that context and get access to our global post list for our app. So let's go see if that solved our problem.

5. Fixing Double Requests

Short description:

Our posts endpoint is still being double requested due to the use posts hook fetching data for every instance. To fix this, we use a React ref to track promises and reuse the promise from the original request for subsequent requests. This ensures a single request is made, and the components load simultaneously.

No, it did not. It looks like our posts endpoint are still being double requested. This might seem weird, but it's actually because any time we load our use posts hook, we need to make sure that it's fetching the data so that it's up to date for the component that's going to use it. But this also means that every instance is going to be calling the fetch function every time that it mounts, even if they mount at the same time. So luckily I know of a way to fix this, and we needed the global state anyway, so at least we didn't waste our time with that.

In the next commit, I'm going to show you the easiest way I know how to dedupe asynchronous requests that are happening at the same time. So we start by using a React ref to track the promise from any outgoing requests. Then if any other requests that happen while the promise is still pending, we can simply reuse the promise from the original request so that we don't fire off any extra ones, and each async function can still resolve when the original request comes back. And if we go back to our network panel now, you can see that there's only a single request for our post endpoint, and both our post list and total post counter finish loading at the same time, which is super awesome.

6. Adding Post Search and Individual Post State

Short description:

In this next commit, I've added a search box to the sidebar for looking up posts by ID. The post detail state now stores separate states for each detail, including status, data, error, and promise reference. This allows both the detail view and the sidebar to update simultaneously and share the same request.

So up to this point, we've been giving our post list a lot of attention. Let's switch gears and check on our individual post view. It's great that we can click on a post to see its content, but I knew eventually that I was going to need a way to look up a post by its ID as well, which I can't do with this UI yet. So in this next commit, I've added a little search box to my sidebar that lets me enter in a post ID and query my API for it. We'll just go grab an ID from one of these posts, put it in here in the search box. If the post is found, it shows the title and lets me click it to open the post, which is super cool. But soon after I added this feature, I noticed another weird thing was happening when I would edit a post that I also had loaded in the sidebar.

So if we edit this post, the post detail gets reloaded with the right title, but the sidebar stays stuck with the old one. And the way our app is structured right now, there isn't really a good way to force that sidebar to reload without introducing some more global state. It was pretty easy to convert our post list into global state, so I thought it shouldn't be that much harder to do with the individual post state as well. And then in this next commit, I'll show you a few difficult things that I ran into when, you know, that I didn't have to worry about in the post list state, but how I got around them. So what happened here is that our post detail state actually needed to store a separate state for every single different detail that we were requesting from the server, including status, data, error, and even its own little promise reference so that we could track and dedupe promises on a per post detail level. It was a bit more work, but it came together okay. And it works just as well as our post list global state does. And you can see now if we grab a post ID, go search for it in our sidebar, try and update the title, both the detail view and the one in the sidebar will each get updated and even share the same request. So this is definitely more consistent than what we had before.

7. Improving Data Fetching and Mutations

Short description:

Even though we've made progress with global state, there are still issues with loading states. React Query solves these problems by handling caching and background refetching. It simplifies data fetching and reduces code. Mutations, such as adding and editing posts, no longer trigger unnecessary loading states.

And even though I felt like we, I guess up to this point, we have accomplished quite a bit with like adding global state and all this stuff, there's still a couple of issues at this point that are still bugging me. First off, I think there are way too many loading states getting shown. And honestly, after all the hard work we just did with global state, it was kind of a disappointment that all of the loading states were still happening.

Another thing is that when we trigger a fetch for one of our posts, like with the sidebar search, while also looking at the same post in the detail view, the detail view gets put into a loading state too when it doesn't really need to. And honestly, it feels like a bad user experience. And then the other things that we haven't even looked at yet are things like caching, pagination, and I don't even really want to think about how we could synchronously access our global state right now to do optimistic updates on our mutations. So we could just keep going on this insane rabbit hole of trying to bend global state to our will and handle all these edge cases. But you can take my word for it that it gets pretty complicated very quickly. Even for the most advanced global state managers out there, it gets pretty crazy.

And with that said, I finally think it's time for React query to swoop in and save the day. So in this next commit, I've moved all of our data fetching hooks to use React query instead of our global state and use effect logic. And as you can see, we were able to blow away about 150 lines of code from our post hooks and our post hooks as well and replace them with a few lines of React queries use mutation hook, or no, use query hook. All we had to do was get a unique key for our data and the asynchronous function to go fetch it. So let's check out how that works.

All right. So it's definitely working. And honestly, it feels a lot faster as we move around the app, especially for views and posts that we've already visited. And this is mainly because React query automatically handles caching and background refetching right out of the box. And when things are cached, they can be rendered immediately next time that they're viewed. And honestly, it can feel a bit unreal at times, like when we search for a post in our sidebar and click the link. Since the post is already cached from the sidebar lookup, the detail view loads instantly. And you'll even notice a little updating status at the top telling us that it was being fetched and reloaded in the background, even though it was reloaded immediately.

So this is all super great. Data fetching is working way better, and we got to delete a ton of code. I want to check out now how our mutations are working and how they feel. So adding a post is way better now because it doesn't go into the loading state to fetch the new post. And it doesn't even, well, and it just gets background refetched and added to the end of the list. So we don't get that jarring loading state that we had before. And same with editing a post. We won't see that loading state anymore either.

8. Optimistic Updates with Mutation

Short description:

In this next commit, I'm going to show you how to use mutation to do something called optimistic updates. They're a great way to make your UI feel fast, even when working with asynchronous data. By using the on mutation and on error callbacks, along with React Query's query cache, we can optimistically update our UI and roll back to a previous value if the mutation fails. If it succeeds, we trigger a background refetch to ensure we're seeing the actual server state. Watch closely as I use the ad post form to see this in action. Our app is now awesome.

You'll just see a background update happen and a new title will appear. So even with this new button I added to delete a post, it even takes us back to the post page without showing us a loading state and just triggers a background update, which is great. I mean, honestly, all this is really awesome considering that right now our mutations are still really naive.

In fact, when we fire off our mutations in our UI components right now, we're still having to make sure that we call the refetch function for any queries that we need to update in the background. And while that does work, there is a much easier way to do that that I'm going to show you in this next commit. And in this next one, this next commit, I migrate all of our mutation hooks to React Query as well. And the way we do that is with the use mutation hook. And the use mutation hook helps us remove, again, helps us remove a ton of code that was dedicated to handling our mutation state and just replaces it with a single call to use mutation. And then we can pass in our asynchronous mutation function to that. And even if that's all we did was just get rid of a bunch of code, I would be happy with that. But use mutation has a couple more options that help us do way more.

The most obvious one you can see here is on success, which is just a function that I've passed that gets called any time that our mutation succeeds. So inside of that callback, we can use React Query's other import called the query cache to notify any related queries that they need to be refetched. And since we're doing that there, all of the refetching logic in our components is now gone. And we can just declaratively define our mutation dependencies one at a time inside of our mutation instead of having to manually call all the queries to refetch every single time that we run a mutation in our UI components. And so up to this point, these things haven't really done anything different for our UI other than just making the code more maintainable. And at the end of the day, we're still dealing with a server that takes a second or two to apply our changes and give back to us that we need to refetch. To me, and probably to all of you as well, those few seconds can feel like an eternity.

So I say, what if we can predict the future? What if we could set up our state so that it's going to show what we expect it to show after the server is done, but just do it immediately? In this next commit, I'm quickly going to show you how to use mutation to do something called optimistic updates. They're a really great way to make your UI feel really fast, like you're not even working with asynchronous data. And use mutation has a couple options we can pass to it, like the on mutation callback, which runs before our mutation function gets executed. The on error callback, which gets called when our mutation function fails. And if we combine all of those with React queries, query cache, and its ability to read and write data from our cache synchronously, we can optimistically update our UI. And then in the case that the mutation fails, we can just roll back to a previous value. And if it succeeds, we can trigger a background refetch to make sure that we're seeing the actual server state instead of just a best guess. So if you watch closely, as I use this ad post form here, you'll see it do exactly that. There's a 50-50 chance it will fail. So sometimes it succeeds and sometimes it fails. But you can see our UI magically rolls back or updates whenever each scenario happens. So our app is now awesome.

9. The Future of Global State Management

Short description:

React Query is the future for handling asynchronous data and solving challenges with server state. It helps us model and think about global state with a new perspective, and in some cases, removes it from our application.

It feels great. It's very fast. And it's really maintainable, too. But all of you saw that when we started this app, it was quick and familiar to jump between those common UI patterns that we lean on when we deal with global state. And even though we can put a lot of hard work into those global state patterns, a lot of things can get out of control pretty quick. So because of that, I believe that tools like React Query are the future for handling our asynchronous data. Not only do they solve the challenges with server state, but it also helps us model and global model our global state and think about our global state with a new perspective. And in some cases, it even removes all of it, or if not most of it, from our application.

10. User Feedback on React Query

Short description:

I've gotten great feedback about React Query from users. Kent C. Dodds said it's the missing piece for React app development. Marcelo Alves loves replacing Redux with React Query. Demetrius Clark finds it helps maintain a productive workflow and UI tuning. React Query is now his go-to server state manager.

I've gotten a lot of feedback from people who have used React Query, and people have great things to say about it. I'd like to share a few quick fun ones with you really quick. My friend Kent C. Dodds said that React Query is the missing piece to React application development that I've been looking for after years of building React apps. Finally, I have a tool that gives me exactly what I need to solve my application state management problems without giving me more problems. It's fantastic. Marcelo Alves said, I still really like Redux, but any time I remove a piece of the store and replace it with React Query, it's a huge win. And then Demetrius Clark said, finding React Query has helped me maintain an extremely productive workflow inside of React. With queries and mutations, my components express intention clearly, and I can finally tune the UI to a flow my users expect due to the powerful caching strategies. React Query is now my go-to server state manager.

11. Conclusion and Invitation

Short description:

Take a look at your global state and see how much is server state and how much is client state. By using React Query for server state, you'll have less client state and a better user experience. Follow me on social media and check out my other projects and startup, Thanks.

So coming full circle here, I'd like to leave everybody with an invitation to go and look at your global state for your applications and take note of just how much of it is server state and how much of it is client state. I think you're going to be surprised at how much of it is actually outside of your application's control and that by opting to handle your server state with a tool like React Query, you'll again be surprised at how little client state you're actually left with and how much better your app's user experience will be.

So thanks for listening and be sure to follow me on Twitter, YouTube, and GitHub. And don't forget to check out all my other open source projects and especially my startup, Thanks.


React Query and Server Communication

Short description:

I'm looking forward to trying React Query at my own project. React Query can support GraphQL with any simple GraphQL client. There's something more generic than Apollo for server communication. As long as it's transactional and uses promises, it'll work. For the remaining client state, I personally use Context and a useReducer for easy management.

I gotta say, Tanner, that was impressive. Thanks a lot for this great talk. I'm actually looking forward to trying React Query at my own project. I also don't think you charge by the hour, right? Sure, sure. You shouldn't do these things if you charge by the hour. Come on, you're killing us. You're killing us.

I want to go jump right into the audience questions. We have a few and I'm going to start with the first one. Is React Query also supporting GraphQL by using Apollo Client? So React Query can support GraphQL, but it doesn't do it through Apollo. If you want to use a simple GraphQL client to fetch data, really you can use whatever you want to fetch your data as long as it returns a promise and your data. So I actually have a lot of people who are using just a simple GraphQL client and React Query together and they say that they love it. So there's a lot of awesome stuff to happen there. Cool, sounds good.

The next question is kind of a play of that. Is there something like Apollo, but for more generic ways of communicating with the server than GraphQL? Yeah, that is a good way to put it. It's more generic. It's not built specifically for GraphQL or really any type of specific data layer or protocol. As long as it's transactional based and uses promise returns, it'll work. You just want promises. Yeah, I don't want empty promises. I need your promises. All right, cool. And then we have another question from Ali. He asks, for the little remaining client state, would you personally use Redux or Context or what is your go-to way of doing this? Yeah, actually, I had such little state left over after I moved everything to React Query that I ended up just moving it to some Context. I use a useReducer and one or two base level components that provide that state through Context to the rest of my app. And honestly, I haven't been happier. There's such little state left over that it's super easy to manage on your own. Mm-hmm. Okay.

React Query vs SWR

Short description:

React Query and SWR accomplish similar things but have different APIs. React Query offers more flexibility in caching queries by keys and provides the useMutation hook for handling side effects to mutations. SWR lacks this concept. These differences make me prefer React Query.

Oh, and also, that was a good question to also answer about Redux. I have a lot of people who have switched over to using React Query for their data fetching and still use Redux to manage their true application state. So they do work well together. But they can't live side by side in harmony. Mm-hmm.

Okay. Question from, well, Mai, I don't know what the complete name is. Recently discovered site slash SWR and it looks great. First time seeing React Query in action and it looks really great too. They seem to accomplish similar things. If you know, could you provide some comparisons and opinion on use cases that may be suitable for one versus the other? Or are they pretty much comparing apples to apples? They are very similar in terms of what they're trying to accomplish. The APIs are different just because they weren't developed in tandem. We each have our own ideas about designing APIs. And I actually have a list of the very minor differences and some really important differences in the React Query read me. There's a little drop down there that says how is this different from Zyte? And you can go and look at some of the things there that are different.

One of the main differences I think is how queries are cached by keys. The key structure for React Query is a little different and in my opinion a little more flexible so that you can select which queries you want to refetch and whatnot. And also the entire concept behind use mutation I think is a really useful hook especially when you start doing things like optimistic updates and wanting to declaratively handle side effects to your mutations. And that's something where that concept doesn't really exist in SWR right now. So that's one of the biggest reasons why I like React Query. Well, you're prejudiced I would say. Yes, I am extremely biased. All right Tanner, that's all the time we have for questions right now. If you have any questions left for Tanner, you can go to the Zoom room.

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

Vue.js London Live 2021Vue.js London Live 2021
34 min
Everything Beyond State Management in Stores with Pinia
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 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
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 Day Berlin 2022React Day Berlin 2022
22 min
Jotai Atoms Are Just Functions
Jotai is a state management library. We have been developing it primarily for React, but it's conceptually not tied to React. It this talk, we will see how Jotai atoms work and learn about the mental model we should have. Atoms are framework-agnostic abstraction to represent states, and they are basically just functions. Understanding the atom abstraction will help designing and implementing states in your applications with Jotai
JSNation 2022JSNation 2022
27 min
Announcing Starbeam: Universal Reactivity
Starbeam is a library for building reactive data systems that integrate natively with UI frameworks such as React, Vue, Svelte or Ember. In this talk, Yehuda will announce Starbeam. He will cover the motivation for the library, and then get into the details of how Starbeam reactivity works, and most importantly, how you can use it to build reactive libraries today that will work natively in any UI framework. If you're really adventurous, he will also talk about how you could use Starbeam in an existing app using your framework of choice and talk about the benefits of using Starbeam as the state management system in your application.
React Advanced Conference 2023React Advanced Conference 2023
28 min
A Practical Guide for Migrating to Server Components
Server Components are the hot new thing, but so far much of the discourse around them has been abstract. Let's change that. This talk will focus on the practical side of things, providing a roadmap to navigate the migration journey. Starting from an app using the older Next.js pages router and React Query, we’ll break this journey down into a set of actionable, incremental steps, stopping only when we have something shippable that’s clearly superior to what we began with. We’ll also discuss next steps and strategies for gradually embracing more aspects of this transformative paradigm.

Workshops on related topic

React Summit 2020React Summit 2020
96 min
Rethinking Server State with React Query
Featured Workshop
The distinction between server state and client state in our applications might be a new concept for some, but it is very important to understand when delivering a top-notch user experience. Server state comes with unique problems that often sneak into our applications surprise like:
- Sharing Data across apps- Caching & Persistence- Deduping Requests- Background Updates- Managing “Stale” Data- Pagination & Incremental fetching- Memory & Garbage Collection- Optimistic Updates
Traditional “Global State” managers pretend these challenges don’t exist and this ultimately results in developers building their own on-the-fly attempts to mitigate them.
In this workshop, we will build an application that exposes these issues, allows us to understand them better, and finally turn them from challenges into features using a library designed for managing server-state called React Query.
By the end of the workshop, you will have a better understanding of server state, client state, syncing asynchronous data (mouthful, I know), and React Query.
React Summit Remote Edition 2021React Summit Remote Edition 2021
71 min
State Management in React with Context and Hooks
A lot has changed in the world of state management in React the last few years. Where Redux used to be the main library for this, the introduction of the React Context and Hook APIs has shaken things up. No longer do you need external libraries to handle both component and global state in your applications. In this workshop you'll learn the different approaches to state management in the post-Redux era of React, all based on Hooks! And as a bonus, we'll explore two upcoming state management libraries in the React ecosystem.