RTK Query is a powerful new way to model data fetching and caching in Redux applications. It’s built on top of Redux Toolkit, but hides almost any interaction with reducers, selectors or thunks behind custom hooks generated specifically for your API.

If your redux application relies heavily on data coming in from over the network, there’s a good chance RTK Query is worth adopting. It will allow you to remove significant chunks of code while also giving you new tools for error handling and cache invalidation that will make your users smile. Apply what I teach in this course and you won’t have to think about thunks ever again.

Sample code can be found here:
https://github.com/xjamundx/egghead-rtkq


In [redux](https://redux.js.org/) we typically model network fetching and caching like this.
- You have a component, which subscribes to data from the redux store via selectors
- In a useEffect hook you check if the data doesn’t exist and then dispatch a thunk
- Your thunk will use a tool like [fetch](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API) or [axios](https://axios-http.com/docs/intro) to grab data from over the network
- As it fetches data your thunk will dispatch actions into the redux store such as pending, fulfilled and rejected (error).
- This is complicated to setup and maintain

[RTK Query](https://redux-toolkit.js.org/rtk-query/overview) provides a better way.

![](https://paper-attachments.dropboxusercontent.com/s_118F96EA7D62F679A47C2AD439C93DC9203009C47C6538B354532E5ADE3FA23F_1676627146090_redux-graphs.png)


RTK Query generates hooks for you at runtime that allow you to query and cache data or run mutations. Loading and error states are available automatically in your component via the hook and cache invalidation is easily manageable.

In this course we’re going a take simple website for a dog grooming company written in react and redux and bring in RTK query over a number of lessons. The network data will all be powered through a REST API using [mock service worker](https://mswjs.io/).

So go ahead checkout the git repo, [download the code](https://github.com/xjamundx/egghead-rtkq) and get ready to learn how to move your app from redux to RTK query.


**Note**:

In the video I say "without having previously used similar interfaces like RTK query or Apollo Client" and what I meant to say was "React Query or Apollo Client".

Understand the RTK Query Mental Model Compared to Redux Thunks

The sample app we're using for this site can be found here:
https://github.com/xjamundx/egghead-rtkq

It's a website for dog grooming that has a few important features:
- Seeing a list of services loaded from an API
- Filtering that list based on your list of dogs
- Adding and removing dogs from your list
- Sending a message via the contact form

The app itself is powered by https://vitest.dev/ and https://mswjs.io/.

 Review a Redux App that will be Converted to RTK Query

In order to benefit from RTK Query you need to centrally define an "API slice", where you declare all of the API endpoints your application will need to use. Your redux store also has to be told about this API slice, luckily it's all only a few lines of code.

```js
export const api = createApi({
  baseQuery: fetchBaseQuery({ baseUrl: '/api' }),
  endpoints: (builder) => ({})
})
```

And then later in your store file:

```js
export const store = configureStore({
  reducer: {
    [api.reducerPath]: api.reducer,
  },
  middleware: (getDefaultMiddleware) =>
    getDefaultMiddleware().concat(api.middleware),
});
```

One of the concepts we mention only briefly in the lesson is the base query. There are several options for base queries including some examples for axios and graphQL base queries you can look into. They are extremely customizable, but I've found using the simple `fetchBaseQuery` is usually enough to get started.
https://redux-toolkit.js.org/rtk-query/usage/customizing-queries


Define an RTK Query API with createApi


In this lesson we use the `builder.query()` to define an extremely simple endpoint. 

It's worth noting that `query()` takes an object with a property confusingly called `query` which can return a URL, which is all we do here. It can also return an object, which we'll see in later lessons.

For more information about queries, see:
https://redux-toolkit.js.org/rtk-query/usage/queries




Migrating a fetch() Call from Redux to RTK Query with builder.query()

Passing data into selectors is a really easy way to handle the migration from plain redux to RTK Query. Even though the data does exist in redux, it's not exactly obvious how to bring it out in a selector. 

If you do want to avoid passing in the data to your selector, you can also do this to get that value.
`api.endpoints.getServices.select()(state)`

In a later lesson I'll show you how to use this approach with a memoized selector, which will usually be slightly more performant.

There are some advanced docs about selectors here:
https://redux.js.org/tutorials/essentials/part-8-rtk-query-advanced#selecting-values-from-results

Pass RTK Query Data into Redux Selectors

If you have a hook for a query such `useGetDogQuery()` what you pass in that hook will be accessible in your builder.query's `query` option.

So if I said `const {data} = useGetDogQuery(id)` I could access that value here `builder.query({ query: (id) => "dog/" + id })`. But it doesn't just have to be a string, this would also be valid. `useGetDogQuery({ id })` and `builder.query({ query: (options) => "dog/" + options.id })`, for example.

You can read more about defining queries here:
https://redux-toolkit.js.org/rtk-query/usage/queries

Migrate a GET Request with a Dynamic URL to RTK Query with builder.query()

Both queries and mutations in RTK Query return `isLoading` and `error` values from the hook you call in your component. There are also about [8 other values](https://redux-toolkit.js.org/rtk-query/usage/queries#frequently-used-query-hook-return-values) you have access to in your component.

While `isLoading` is pretty obvious it's important to understand how the `error` value is put together. They contain the `status` and `data` properties, where `data` is whatever is returned from the server. Also unlike `fetch`, RTK Query will respond with an error on non-200 responses. However, RTK Query won't ever throw unless you call `.unwrap()` on a failed request.

See https://redux-toolkit.js.org/rtk-query/usage/error-handling#overview for more info.

Handle Loading and Error States in RTK Query with isLoading and Error Values

Here we use `builder.mutation()` to define a mutation in our API. What is a mutation? Well it's basically a POST request or anything that would modify something on the server. You'll notice `builder.mutation()` and `builder.query()` look very similar except here we are passing the URL in an options object and that's only because we want to pass `method` and `body` as well. The query here could potentially also be a string just like in `builder.query`.

The most interesting thing about mutations is optimistic updates which we'll cover in a later lesson about `onQueryStarted`.

More information about the options you can pass into `builder.mutation` can be found here:
https://redux-toolkit.js.org/rtk-query/usage/mutations

Migrate a POST Request in a Redux App to an RTK Query Mutation

In this lesson we learn about the `isSuccess` state that accompanies a successful mutation. We also use the `isLoading` state from a mutation hook to prevent a user from filling out a form multiple times.

Initially, we display a sent message powered with `useState` and a `setTimeout` that gets removed after 2s. In this lesson we display the message after our query's `isSuccess` value returns `true`. We also rely on the combination of `isLoading || isSuccess` to prevent additional form submissions.

- Our form submission relies on the [FormData](https://developer.mozilla.org/en-US/docs/Web/API/FormData) web API
- Read [Frequently Used Mutation Hook Return Values](https://redux-toolkit.js.org/rtk-query/usage/mutations#frequently-used-mutation-hook-return-values)


Handle Form Submission States with RTK Query's isLoading and isSuccess Values

This our longest lesson. It covers territory that we've already covered, but in a more advanced way. Here are some of the main points.

1. When you migrate redux state into RTK Query, by mindful that you may have had initial state, which should usually be replaced with an `isLoading` check
2. Like everywhere else we rely on [destructuring asignment](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment#object_destructuring) to give meaningful names to the generic `data` property returned from our query hook.
3. We're also using [optional chaining](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Optional_chaining) to deal with  `data` before we receive a server response
4. We're continuing to update our `getServicesForLuckyDog` selector here and pass in additional data, this time for our dogs


Migrate a Redux Thunk to RTK Query


In this lesson we rely on `useMemo` to to give additional properties to data returned from our query hook. This is **not the recommended approach** to modifying a server response. That would be the `transformResponse` property shown in the next lesson, but I wanted to demonstrate how easy it was to combine typical react features like `useMemo` with RTK Query results. This approach can work well if you need to modify data in a single component and no where else. It can also be combined with a custom hook that encapsulates both the query and the `useMemo` call to be made more reusable. In the sample code I've provided an example of what that hook might look like.

Transform Cached RTK Query Data before Rendering with useMemo

We're currently modifying the data we get from RTK Query at the component level with `useMemo`. This works great when you have a single component that needs to have access to the data in a unique way. However, when you need to access that modified data in multiple components, it's better to use `transformResponse`.

Using [transformResponse](https://redux-toolkit.js.org/rtk-query/usage/customizing-queries#customizing-query-responses-with-transformresponse) moves the data transformation into your cache, so any component subscribed to a given query will receive data in the updated format.


Transforming RTK Query Data before Caching with transformResponse


This lesson covers two important principles. The first is memoized selectors with [createSelector](https://redux-toolkit.js.org/api/createSelector) and RTK Query's built-in [endpoint selectors](https://redux-toolkit.js.org/rtk-query/api/created-api/endpoints#select).

RTK Query doesn't give you an easy way to access its cache manually but it does give you these enpoint selector helpers that allow you to reach into the cache when you need it.

Using these memoized endpoint selectors are recommended because they only calculate a new value any time the data arguments change while the previous selectors we had would be re-run on every re-render.

While not mentioned in the lesson you don't need to use endpoint selectors with createSelector. This would work perfectly fine:

```js
export const getServicesForLuckyDog = (state) => {
  const { data: dogs } = api.endpoints.getDogs.select()(state);
  const { data: services } = api.endpoints.getServices.select()(state);

  // if you don't have a lucky dog, show all of the services
  const dog = dogs?.[state.dogs.luckyDog];
  if (!dog) {
    return services;
  }
  // ...
};
```


Access the RTK Query Cache in a Memoized Selector Using an Endpoint's select() Method


Here we use `builder.mutation()` to define a mutation in our API. What is a mutation? Well it's basically a POST request or anything that would modify something on the server. You'll notice `builder.mutation()` and `builder.query()` look very similar except here we are passing the URL in an options object and that's only because we want to pass `method` and `body` as well. The query here could potentially also be a string just like in `builder.query`.

You probably noticed that we removed the refetch that was happening with `dispatch(getDogs())`. That will be replaced in the next lesson with the `refetch` method.

More information about the options you can pass into `builder.mutation` can be found here:
https://redux-toolkit.js.org/rtk-query/usage/mutations


Migrate a Thunk in a Redux Application to an RTK Query Mutation


This lesson is about a powerful combo, refetch and unwrap.

The first and simplest concept is [refetch](https://redux-toolkit.js.org/rtk-query/usage/queries#frequently-used-query-hook-return-values), which forces whatever query you're subscribed to, to pull the latest data from the server. Refetch takes no arguments and doesn't let you change the query in any way. It just forces it to be called again. Another way to manually call refetch is to use `initiate` on your query's endpoint. For example, `api.endpoints.getDogs.initiate(undefined, { forceRefetch: true })` would do the same thing as our `refetch` call here, but `refetch` is a lot cleaner.

The second part is around [unwrap](https://redux-toolkit.js.org/api/createAsyncThunk#unwrapping-result-actions), which lets you access the original promise result from a mutation, which you can then use to immediately trigger some action, such as refresh. Or, you can use it to display an error message when the mutation fails.

Manually Refetch Data After an RTK Query Mutation with unwrap() and refetch()


This lesson demonstrates how to use the [keepUnusedDataFor](https://redux-toolkit.js.org/rtk-query/api/createApi#keepunuseddatafor) of APIs and queries to modify the default timeout of cached items when they're not being used. "Used" here refers to components subscribing to them via query hooks. If you're actively relying on the data on the page you're in, RTK Query won't just go and pull data fresh, but if you move away for long enough and then come back, it will make sure your data is up-to-date.

This is actually a brilliant feature, but the specific number for how long the timeout should be is going to depend on the usage patterns of your users and how frequently the data changes on the server. If your data changes infrequently there may not be any reason to have this enabled at all, you could set it to `3600s` (1 hr) for example.


Invalidate the RTK Query Cache using keepUnusedDataFor


The tags feature shown in this lesson is arguably RTK Query's best feature. It's conceptually simple, but incredibly powerful. If you can know ahead of time which operations will invalidate your data, then you should always refresh the data after you perform those operations.

The basic premise is that you specify which tags queries rely on with `providesTags` and then which tags a mutation will invalidate with `invalidatesTags`.

One of the advanced things you can do with tags, which we don't cover here is configuring mutations to invalidate tags with a specific ID. So imagine if you edit an entry, you don't want it to invalidate every other entry, just that one AND the list. This is covered in the [automated refreshing](https://redux-toolkit.js.org/rtk-query/usage/automated-refetching) section of the RTK Query Docs. There's also information in the docs about [how to handle pagination with tags](https://redux-toolkit.js.org/rtk-query/usage/pagination#automated-re-fetching-of-paginated-queries).


Invalidate RTK Query Cache Entries Automatically using providesTags and invalidateTags


This is a small lesson that covers a tiny feature of RTK Query that enables two additional refetch options: `refetchOnMount` and `refetchOnReconnect`.

In order to support them you need to include `setupListeners()` in your redux store. And then you'll have the ability to automatically refetch data when your page comes into focus or reconnects to the network. The main idea is if you're outside of the page on a different app and come back it will make sure your users are seeing the most up-to-date information.

More information about these options can be found here:

- https://redux-toolkit.js.org/rtk-query/overview#configure-the-store
- https://redux-toolkit.js.org/rtk-query/api/createApi#refetchonfocus
- https://redux-toolkit.js.org/rtk-query/api/createApi#refetchonreconnect


Refetch Data on Focus And Reconnect with RTK Query's setupListeners


Optimistic updates are great for user experience. In this lesson we purposefully setup the remove dogs handler to wait several seconds to return. That meant for an awkward experience for users while waiting for the dog deletion to go through. It's going to go through 99% of the time right? Why not just respond like it worked? That's what optimistic updates allow you to do.

In every query or mutation you define, you have the option of including an `onQueryStarted` listener, which will be executed just as the query is fired off. In there you receive the arguments passed into the query or mutation as the first, and then a number of utilities including `dispatch` passed as the second argument.

This will let you `dispatch(api.util.updateQueryData(<queryName>, <queryArgument>, <modificationFn>))` and modify the cached data stored for that particular query.

If you're using `invalidateTags` with your mutation as well as manually modifying the cache, your cache will be updated immediately and then refetched after the mutation was successful.

Two example of optimistic updates with RTK Query can be found here:

- https://redux-toolkit.js.org/rtk-query/usage/manual-cache-updates#optimistic-updates
- https://redux-toolkit.js.org/rtk-query/usage/examples#react-optimistic-updates


Perform Optimistic Updates in RTK Query by Dispatching the updateQueryData Action


The thing about optimistic updates is that sometimes the worst case happens: your server fails. RTK Query makes handling this case incredibly easy.

In your `onQueryStarted` handler you have access to the original promise (similar to the results of `unwrap()`) in a value called `queryFulfilled`. With this value you can add a `.catch()` which will be ready to handle any non-200 response and in there you can call `.undo()` on the results of dispatching `api.util.updateQueryData`.

Doing that will revert your redux and rtk query state to where it was before your made the change. It's honestly kind of magical.

The document for optimistic updates and undo can be found here: https://redux-toolkit.js.org/rtk-query/usage/manual-cache-updates#optimistic-updates


Undo an Optimistic Update in RTK Query with queryFulfilled

In this lesson we look at the options for modifying headers on your queries. We start with adding a `headers` object to an individual query. That requires moving our query from returning a url string, to returning an object with the URL and the new `headers` property. We also add `headers` to our `baseQuery`, but replace that with the more flexible [prepareHeaders](https://redux-toolkit.js.org/rtk-query/api/fetchBaseQuery#prepareheaders).

`prepareHeaders` relies on the [Headers object](https://developer.mozilla.org/en-US/docs/Web/API/Headers) that is part of the Fetch API. As a second argument you also can access the current redux state. Accessing the redux state is helpful if you want to access saved data such as an authentication token.

Here's an example of using `prepareHeaders` for setting an `authorization` header:
https://redux-toolkit.js.org/rtk-query/api/fetchBaseQuery#setting-default-headers-on-requests


Customize Query and Mutation Headers in RTK Query with prepareHeaders


RTK Query can start fetching data in your application before React is even available. This can be handy when your application relies heavily on data that you need to fetch. This data is cached so your users won't be refetching this data when they navigate through out the application.

Prefetching relies on the powerful `api.endpoints.<queryName>.initiate()` method that underlies much RTK Query's internals. For RTK Query to process and store initiate() calls properly they have to be sent into the redux store with `store.dispatch()`.

An advanced variation of this splits your main app file into the data pre-fetching (done first) and then your react application (lazy-loaded with `import()`). The idea being that you want to start your data calls before JS has to even start process what's likely to be a large bundle file.

For more information about prefetching with RTK Qyery see: https://redux-toolkit.js.org/rtk-query/usage/prefetching#prefetching-without-hooks.


Prefetch Data in RTK Query using an Endpoint's initiate() Method

The previous prefetching that we did with the `initiate` method is most useful for data that will existing on your initial page load. For other data throughout your application pre-loading can still come in handy, but you need to be thoughtful about what gets loaded, and when.

RTK Query gives you a `usePrefetch` hook that you can sprinkle throughout your application depending on what your user is doing. In this lesson, we prefetch dog data when the user hovers over the dog and services links, indicating their intent to load those page. With this approach to pre-fetching it's unlikely your users will ever see a loading spinner.

The documentation for RTK Query's `usePrefetch` hook can be found here:
https://redux-toolkit.js.org/rtk-query/usage/prefetching#prefetching-with-react-hooks


Prefetch Data in Response to User Interactivity with RTK Query's usePrefetch hook

RTK Query is built on top of Redux which has the huge benefit of utlizing the [Redux DevTools](https://chrome.google.com/webstore/detail/redux-devtools/lmhkpmbekcpmknklioeibfkpmmfibljd?hl=en). Every RTK Query operation is represented with the actions and state modifications that happen in the DevTools. 

There's also RTK Query tab in Redux DevTools so that you can take a detailed look at the various queries and mutations you have going at any given time.

In this lesson you'll get a basic overview of the Redux DevTools and how it works with RTK Query.

Debug RTK Query Applications with the Redux DevTools Chrome Extension


With our migration complete, you notice that there is A TON of Redux code we can simply delete. We no longer have to manually handle all the server interactions that our application requires to function. Redux can handle the client-side state that it was meant to handle and RTK Query can take care of fetching and caching our network data.

Not only is our code base cleaner and easier to understand but it also provides a significant boost in the user experience of our application by making features like prefetching, optimistic updates, loading and error states easier to include.

If you're running a redux application in production I suggest taking a serious look at RTK Query. After this course you should have all the tools you need to make that happen.


Adopting RTK Query into an Existing Redux Application

Instructor

Course content (25 lessons)

Instructor