Redux Toolkit Query and React Query: Which should I use when?

First and foremost, let me state that this is not a one-on-one comparison, nor is it a “which one is better” debate. This is an article on two libraries that are highly powerful, comparing them in different circumstances and discussing the merits that both have.

Lets start 🙂

Redux Toolkit Query and React Query are two popular libraries for managing and fetching data in React applications. Both libraries aim to make it easy to handle data in a scalable and maintainable way, but they approach this problem in slightly different ways.

Redux Toolkit Query is built on top of Redux, the popular state management library. It provides a set of utilities for defining and managing data in the Redux store, as well as handling fetching and caching of data. The main advantage of using Redux Toolkit Query is that it fits seamlessly into the existing Redux architecture and allows you to use the powerful dev tools and middleware that are available for Redux. This can be especially useful if you are already using Redux in your application and want to keep all of your state in one place.

React Query, on the other hand, is a standalone library that is not tied to any specific state management library. It focuses on providing a simple API for fetching and caching data, and it can be used in any React application regardless of whether it uses Redux or another state management library. The main advantage of React Query is its simplicity and flexibility. It is easy to get started with and it provides a lot of built-in features such as automatic caching and stale-while-revalidate.

How do they work?

RTKQuery has a syntax that is quite similar to React Query, however there are a few differences in how everything is put up.

You must first define the endpoints you will need for querying and mutating data, which you can do using the utility function createApi. You can also define the baseQuery that you will use for your endpoints, which by default uses Fetch and will handle errors and resolving data, but you can edit this and provide your own fetchBaseQuery, which we will leave as default for now.

You can also define the query function for each endpoint, where you can provide the url, method, params, and much more.

As a result, you’ll have something like this.

Furthermore, createApi will use autogenerate hooks for the execution of your endpoints, which is where RTKQuery and React Query begin to resemble one other, because React Query employs hooks for handling Query and Mutation actions, but we’ll get to that later.

When you have your hooks, you can use them in this manner.

Or mutate data like this

Of course the createApi and it’s hooks has more params to use, like cache functionalities, re-fetch queries on every specific amount time, and other stuff that you can read more about here

The React Query on the other hand, the main advantage of React Query is its simplicity and flexibility. Unlike RTKQuery, which is limited to what we define in the createApi function, React Query allows you to define your own query/mutation on the fly. However, you must still define how you want each query to be executed (via fetch, axios, etc.) and how you will handle errors.

But, what is fetchPosts? It’s a Query Function, which can be literally any function that returns a promise. The promise that is returned should either resolve the data or throw an error

So you will have something like this:

And we can clean this up a little bit like this

Same logic applies to Mutation data, the hook useMutation will provide you with a trigger function, and in the Query Function, you can define what to do with that data.

Of course useQuery and useMutation hooks has more params to use, like cache functionalities, re-fetch queries on every specific amount time, and other stuff that you can read more about here

Caching

Caching data in React Query works by saving the data in memory and using it for subsequent requests instead of sending a new request to the server. This improves performance by lowering the number of network queries and the time required to obtain the data. React Query also has cache management functionality such as invalidating stale data and addressing network failures.

Caching data in Redux Toolkit Query works similarly to React Query, except it uses the Redux store to manage the cache. This means that the cached data is saved in the store and may be retrieved and updated by the application’s various components. The Redux store also enables simple cache management, such as invalidating stale data and resolving network problems. Furthermore, Redux Toolkit Query includes a collection of actions and selectors for dealing with the cache, allowing for more fine-grained control over how data is saved and retrieved.

Which should I use when?

Keeping in simple, you can use whatever the F**** you want, both are great, both perform great but, since the aim of this post is write about best scenarios to use them, lets dig a little bit about it

When picking between React Query and Redux Toolkit Query, keep the following aspects in mind:

• Application complexity: If your application is simple and does not require a lot of global state management, React Query might be a better choice because it is primarily focused on handling data requests and caching. If your application is more complicated and requires a centralized store for handling state, Redux Toolkit Query, which connects with the Redux store, may be a better option.
• Team familiarity: If your team is already familiar with React Query and are comfortable with its API, it may be easier to continue using it. Similarly, if your team is already familiar with Redux and are comfortable with the Redux ecosystem, Redux Toolkit Query may be a better fit.

The one I care about the most is complexity and scalability over time, and I’m not going to lie, I prefer to specify everything in one place and then export and utilize it.

CreateApi is stupid powerful, but if the endpoint has some logic that you can’t execute with createApi, you have to use createAsyncThunk, which is beyond the parameters of createApi, which complicates things a little.

As a result, when you think about it, React Query covers all “scenarios” for querying and altering data, regardless of whether the logic is sophisticated or not, and even if there is a third party in between, the way of doing things will remain consistent, which is also strong thought time.

Conclusion

Finally, Redux Toolkit Query and React Query are also popular tools for maintaining and retrieving data in React applications. They both want to make it simple to handle data in a scalable and maintainable manner, but they go about it in slightly different ways.

Both have advantages and disadvantages, and it is vital to consider them while deciding which to utilize.

It is critical that engineers do not utilize libraries solely because everyone else is doing so. Instead, explore first, compare them, and choose which one best meets your needs.

Thanks for reading me 🙂