Redux Toolkit and RTK Query: Simplify React State and Data Fetching

js

Redux Toolkit and RTK Query: Simplify React State and Data Fetching

Learn how Redux Toolkit and RTK Query unify React client and server state, reduce boilerplate, and simplify data fetching. Read now.

Apr 27, 2026

Redux Toolkit and RTK Query: Simplify React State and Data Fetching

I remember the moment clearly. I was building a React dashboard that needed to fetch user profiles, product lists, and real-time notifications—all from different endpoints. My code quickly became a mess of useEffect hooks, custom fetch wrappers, and scattered loading spinners. I kept asking myself: Why is managing server data so different from managing local state? Then I discovered that Redux Toolkit, which I already used for my app’s client state, came with a built-in data fetching tool called RTK Query. That was the day I stopped fighting two separate systems and started treating every piece of data—whether it lives on a server or in the user’s browser—as part of one unified store.

This article is my attempt to show you how you can do the same. I will walk through the core ideas, add code snippets you can copy, and share personal notes from my own projects. By the end, you will see why combining Redux Toolkit with RTK Query is like having a single powerful lens that brings both local and server data into sharp focus.

Let me start with a simple truth: React applications exist in two worlds. The first world is client state—the value of a checkbox, the text inside an input field, the count of items in a cart. The second world is server state—data that comes from an API and changes without the user’s direct action. Traditional Redux handles the first world beautifully. But for the second world, developers often reach for separate libraries like Axios, React Query, or SWR. That works, but it creates a divide. Why should your app’s architecture force you to think in two different ways?

Redux Toolkit’s solution is RTK Query. It is not an external plugin. It is baked into the @reduxjs/toolkit package. When you add RTK Query to your store, every API call automatically becomes part of your Redux store. Loading states, error states, and cached data all live inside the same DevTools you already use for your reducers. This means you can inspect server state and client state side by side, debug them together, and write components that pull from a single source of truth.

Here is a concrete example. First, you need to create a Redux store with RTK Query’s API slice. I like to keep this in a file called apiSlice.js:

import { createApi, fetchBaseQuery } from '@reduxjs/toolkit/query/react';

export const apiSlice = createApi({
  reducerPath: 'api',
  baseQuery: fetchBaseQuery({ baseUrl: 'https://jsonplaceholder.typicode.com' }),
  endpoints: (builder) => ({
    getPosts: builder.query({
      query: () => '/posts',
    }),
    addPost: builder.mutation({
      query: (newPost) => ({
        url: '/posts',
        method: 'POST',
        body: newPost,
      }),
    }),
  }),
});

export const { useGetPostsQuery, useAddPostMutation } = apiSlice;

Notice how I defined two endpoints: one for fetching posts (a query) and one for creating a post (a mutation). There is no manual fetch, no try/catch inside a component, and no separate loading state variable. RTK Query generates hooks for you. Next, you configure the store to include this API slice:

import { configureStore } from '@reduxjs/toolkit';
import { apiSlice } from './apiSlice';

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

After that, wrap your React app with the standard Redux Provider. Then inside any component, you can call the generated hook:

import { useGetPostsQuery } from './apiSlice';

function PostList() {
  const { data, error, isLoading } = useGetPostsQuery();

  if (isLoading) return <p>Loading posts...</p>;
  if (error) return <p>Something went wrong.</p>;

  return (
    <ul>
      {data.map((post) => (
        <li key={post.id}>{post.title}</li>
      ))}
    </ul>
  );
}

That is it. Three lines of code gave me a loading state, an error state, and automatic caching. If I navigate away and come back, RTK Query reuses the cached data instead of making a new request. It also deduplicates requests—if two components both call useGetPostsQuery at the same time, only one request goes to the server.

Now, what about updating server data? Suppose you want to add a new post and immediately see it in the list. This is where cache invalidation becomes crucial. RTK Query allows you to invalidate a tag after a mutation succeeds. Modify the endpoint definition like this:

getPosts: builder.query({
  query: () => '/posts',
  providesTags: ['Post'],
}),
addPost: builder.mutation({
  query: (newPost) => ({
    url: '/posts',
    method: 'POST',
    body: newPost,
  }),
  invalidatesTags: ['Post'],
}),

Now when you call addPost, RTK Query automatically refetches the getPosts query. The list updates without any manual refetch logic. I remember a project where I spent hours writing custom cache-busting code. After switching to RTK Query, that entire module vanished. How many hours have you spent on cache management that could have been automated?

But here is the best part: this unified approach does not force you to abandon client-side state. You can still create regular Redux Toolkit slices for things like a modal visibility flag or a draft form. For example:

import { createSlice } from '@reduxjs/toolkit';

const uiSlice = createSlice({
  name: 'ui',
  initialState: { isSidebarOpen: true },
  reducers: {
    toggleSidebar(state) {
      state.isSidebarOpen = !state.isSidebarOpen;
    },
  },
});

export const { toggleSidebar } = uiSlice.actions;
export default uiSlice.reducer;

You add this slice to the same store as your API slice. Inside a component, you can dispatch toggleSidebar while also using useGetPostsQuery. The Redux DevTools show both types of state in a single timeline. This consistency reduces mental overhead and makes onboarding new developers faster.

Naturally, you might wonder: Does this approach scale? Yes. RTK Query supports optimistic updates, polling, lazy queries, and even code splitting for larger apps. For instance, if you need a query to run only when a user clicks a button, use the useLazyQuery hook:

const [trigger, { data }] = useLazyGetPostsQuery();

const handleLoad = () => {
  trigger();
};

You also get TypeScript support out of the box. The types for your data, error, and mutation arguments are inferred from your endpoint definitions. I once introduced a bug because I manually typed a response object incorrectly. RTK Query would have caught that at compile time.

A personal touch here: when I first integrated RTK Query, I was skeptical about adding another abstraction. But after a week, I realized I had removed around 60% of my previous data-fetching code. My components became shorter, my tests became simpler, and I stopped worrying about stale data. The biggest win was that new features—like adding a search box that refetches results—took minutes instead of hours.

Let me address one more concern: performance. Some developers worry that adding all server data into the Redux store will bloat memory. In practice, RTK Query stores only the data you explicitly request, and it uses a configuration option called keepUnusedDataFor to automatically clear old data after a timeout. You can also use the serializeQueryArgs option to fine-tune caching per query.

Here is a quick example of a component that uses both a mutation and a refresh:

function CreatePost() {
  const [addPost] = useAddPostMutation();

  const handleSubmit = async (title, body) => {
    try {
      await addPost({ title, body, userId: 1 }).unwrap();
      alert('Post created!');
    } catch (err) {
      console.error('Failed to save post', err);
    }
  };

  return (
    <button onClick={() => handleSubmit('My Post', 'Content')}>
      Save
    </button>
  );
}

The .unwrap() method lets you use standard try/catch for error handling, which keeps your code familiar and readable.

Now, I want to challenge you to think about your own codebase. How many separate libraries are you using to fetch data, manage loading states, and update the UI? If the answer is more than one, you might be overcomplicating your architecture. Redux Toolkit with RTK Query offers a single, predictable container for all your state—whether it originates from a local click or a remote database.

I have seen teams move from a patchwork of solutions to this unified approach and immediately notice a drop in bugs related to stale data and inconsistent loading indicators. The mental model is simple: your app has one store, one set of DevTools, and one pattern for handling any kind of data. The learning curve is shallow because RTK Query’s API mirrors the familiar Redux Toolkit patterns like createSlice and createAsyncThunk, but with less boilerplate.

Let me leave you with a final thought. The next time you start a React project, or even refactor an existing one, consider this question: What if I never had to write another manual useEffect for fetching data again? That is exactly what RTK Query delivers. It is not a magic bullet—you still need to design your API endpoints and handle edge cases—but it removes the repetitive, error-prone plumbing that takes up so much of a developer’s day.

If this approach resonates with you, try it on a small feature first. Add a single query, see how it feels, and then expand. You might find, as I did, that managing state and server data under one roof makes your application not only easier to build, but also easier to understand.

I hope this article gave you a clear, practical view of integrating Redux Toolkit with RTK Query. If you found it useful, please like this post, share it with a teammate who still uses raw fetch calls in their components, and leave a comment telling me about your own state management struggles. I read every reply and I love learning from your experiences. Let’s build better apps together—one unified store at a time.

As a best-selling author, I invite you to explore my books on Amazon. Don’t forget to follow me on Medium and show your support. Thank you! Your support means the world!

101 Books

101 Books is an AI-driven publishing company co-founded by author Aarav Joshi. By leveraging advanced AI technology, we keep our publishing costs incredibly low—some books are priced as low as $4—making quality knowledge accessible to everyone.

Check out our book Golang Clean Code available on Amazon.

Stay tuned for updates and exciting news. When shopping for books, search for Aarav Joshi to find more of our titles. Use the provided link to enjoy special discounts!

📘 Checkout my latest ebook for free on my channel!
Be sure to like, share, comment, and subscribe to the channel!