Convert react/redux webapp from saga/axios to RTK query and RTK listener

Redux saga is a core component of my react/redux applications. Unfortuately Redux Saga has been deprecated and haven’t seen an upgrade in the last year.

This blog posts covers the replacement of redux saga and axios with RTK query and RTK listener in a react redux webapp.

Introduction

The structure of this blog post, is:

1. First a walk through of how to use RTK query and RTK listener in a React application
2. Then I’ll sum up the changes made, what was good and what didn’t feel like an improvement to me

That means if searching on the web for how to use RTK query landed you here, you’ll find the good stuff first and can skip the rest.

As for why you should use RTK query…?

If you, like me, is still using redux with axios and saga, then switching to RTK query is a no-brainer, since redux Saga hasn’t seen an update since February 1 2024, and is now deprecated.

If you’re not using redux because you have heard that it is hard to understand, bloated and require a lot of boilerplate, then you should reconsider. You should reconsider for the same reason I keep using redux: the existence of redux devtools.

I find what I miss most when dealing with local state and context object is an easy way to examine the application’s current and entire state and trace when the state changes a particular value.

Writing console.log() to output the data to find what’s in there, is so… I don’t know… 1985…?

So without further ado, here’s how to use redux with RTK query in a react application (requires knowledge of JavaScript, it is helpful to know React, and knowledge of redux would help even more).

Using RTK query

Adding the dependencies

Go to the directory containing package.json and run the following commands (first scrub existing dependencies and then add new ones):

npm uninstall react react-dom react-redux "@reduxjs/toolkit"rm package-lock.jsonnpm install react react-dom react-redux "@reduxjs/toolkit"

After this you should have all of the newest versions of the required dependencies.

If converting from saga/axios, then remember to scrub unneccessary dependencies after completing the conversion, with:

npm uninstall redux-saga axiosrm package-lock.jsonnpm install

Queries and mutations

With redux-saga and axios, data from a REST API backend is loaded by something like this

import { takeLatest, call, put } from 'redux-saga/effects';import axios from 'axios';import { ACCOUNTS_REQUEST, ACCOUNTS_RECEIVE, ACCOUNTS_FAILURE } from '../reduxactions';export default function* accountsSaga() {    yield takeLatest(ACCOUNTS_REQUEST, receiveAccountsResult);}function* receiveAccountsResult() {    try {        const response = yield call(getAccounts);        const accountsresult = (response.headers['content-type'] === 'application/json') ? response.data : {};        yield put(ACCOUNTS_RECEIVE(accountsresult));    } catch (error) {        yield put(ACCOUNTS_FAILURE(error));    }}function getAccounts() {    return axios.get('/api/accounts');}

In addition to the above code a redux reducer to store the data in the frontend is needed, and the redux actions must be defined (not shown here, this blog post is about RTK query and not about redux-saga and axios).

In RTK query, the above example would be replaced with a one liner (this is what is called “a query” in RTK query terminology):

getAccounts: builder.query({ query: () => '/accounts' }),

In addtion to creating the code fetching the data, this one liner also results in redux storage of the fetched data, and redux actions for starting, successful completion and failure.

To use the results of data fetched by an RTK query in a React component, a hook created from the above one liner is used

export default function Home() {    const { data: accounts = [] } = useGetAccountsQuery();    return (<p>Number of accounts: ${accounts.length}</p>);}

When the component is rendered an HTTP request is started to fetch the data, and when the data arrives the component will be re-rendered. There is also considerable logic behind caching data and refetching that decides whether to reload the data or not when navigating in and out of the component.

My brief experience with RTK query is enough to tell me that RTK query’s reload logic works a lot better than my own home brewed reload logic.

One difference from the replaced saga/axios code, was that the reducer where the fetched data is stored, has no default value. So without the “= []” in the example above, accounts would be undefined on the first render.

Since the returned data is in the redux state, it is possible to use the useSelector() hook to access the data, but using a regular selector won’t trigger the fetch and reload logic. So as a rule of thumb: always start with the generated hook.

It is possible to add arguments to a query

getAccount: builder.query({ query: (username) => '/account/' + username }),

The query argument would then added to the hook used in the react component:

const { data: account = {} } = useGetAccountQuery('steban');

Default for a query is to use HTTP GET, but using e.g. POST is simple and still an one-liner

postAccountAdminstatus: builder.query({ query: body => ({ url: '/account/adminstatus', method: 'POST', body }) }),

The “body” argument needs to be possible to translate into JSON, to be sent as the POST body (and in my experience it is best to make the POSTed JSON a JSON object).

const { data: adminStatus } = usePostAccountAdminstatusQuery({ username: 'steban' });

Queries are for fetching data only. Even if a POST is used a query shouldn’t be used on an endpoint that modifies data on the backend.

To modify data you use a mutation, and a mutation can also be a one-liner

postAccountModify: builder.mutation({ query: body => ({ url: '/account/modify', method: 'POST', body }) }),

The usage if the mutation hook is a little bit more complex than the query hook:

const { data: account = {} } = useGetAccountQuery('steban');const [ postAccountModify ] = usePostAccountModifyMutation();const onSaveButtonClicked = async () => await postAccountModify(account);

I.e.:

1. The mutation function is picked out of the hook return value
2. Then an async lambda is created using that function to post the return value
3. The account value is used in the form elements

4. The onSaveButtonClicked is used in

   <button onClick={onSaveButtonClicked}>Save account</button>

After updating data in the server, you would like the redux data updated with the new values.

The simplest way to get updated redux data, is to trigger a reload of the query that fetched the data in the first place.

To trigger a reload, put a tag on the query that should be reloaded:

getAccounts: builder.query({ query: () => '/accounts', providesTags: ['Accounts'] }),

and then invalidate that tag after POSTing a mutation:

postAccountModify: builder.mutation({    query: body => ({ url: '/account/modify', method: 'POST', body }),    invalidatesTags: ['Accounts'],}),

The getAccounts query will be re-run and components with the useGetAccountsQuery() hook will be re-rendered.

That if the accounts had already been loaded by a hook in a react component, it isn’t neccessarily reloaded the next time the component is loaded, so without the invalidation, navigating to the component might show the old data.

But using invalidation of tags makes everything works smoothly and makes the data be updated on visit.

If the return from the mutation contains the the updated data, there is no need to make an invalidation. Then the redux storage of the query can be updated with the mutation return:

postAccountModify: builder.mutation({    query: body => ({ url: '/account/modify', method: 'POST', body }),    async onQueryStarted(body, { dispatch, queryFulfilled }) {        try {            const { data: accountsAfterAccountModify } = await queryFulfilled;            dispatch(api.util.updateQueryData('getAccounts',  undefined, () => accountsAfterAccountModify));        } catch {}    },}),

The await queryFulfilled in onQueryStarted() waits for a successful mutation return and then then dispatches a redux action that replaces the results of a query

The tricky bit, when replacing query values in this way, is argument 2 of the updateQueryData() redux action creator, which is undefined in the above example.

If the query had an argument (e.g. the username), the replacement needs to have the same value. If not, there is no replacement and no error message. In this case the query has no argument, and then undefined is used.

The queries and mutations in my converted projects all live in a single file api.js on the top and all look a bit like this:

import { createApi, fetchBaseQuery } from '@reduxjs/toolkit/query/react';export const api = createApi({    reducerPath: 'api',    baseQuery: (...args) => {        const api = args[1];        const basename = api.getState().basename;        return fetchBaseQuery({ baseUrl: basename + '/api' })(...args);    },    endpoints: (builder) => ({        getAccounts: builder.query({ query: () => '/accounts' }),        getAccount: builder.query({ query: (username) => '/account/' + username }),        postAccountAdminstatus: builder.query({ query: body => ({ url: '/account/adminstatus', method: 'POST', body }) }),        postAccountModify: builder.mutation({            query: body => ({ url: '/account/modify', method: 'POST', body }),            async onQueryStarted(body, { dispatch, queryFulfilled }) {                try {                    const { data: accountsAfterAccountModify } = await queryFulfilled;                    dispatch(api.util.updateQueryData('getAccounts',  undefined, () => accountsAfterAccountModify));                } catch {}            },        }),    }),});export const {    useGetAccountsQuery,    useCetAccountQuery,    usePostAccountAdminstatusQuery,    usePostAccountModifyMutation,} = api;

I.e.

1. The reducerPath is the top level path of the api’s reducer slice in the redux state
2. The baseQuery sets the base path prefix for all API calls, in this case it is the value of ‘/api’ prefixed by redux state value basename
3. The endpoints contains the specification for the queries and mutations
4. All mutations are exported at the end for ease of use in the

For those who like looking at example code, here is the “api.js” of some React web applications converted from saga/axios to RTK query:

applicationdescriptionhandleregA groceries tracker and statistics appsampleappA template application for React web applications with jersey backend and PostgreSQL database set up with liquibaseoldalbumAn app wrapping 90-ies albums in 202x web technologyukelonnA weekly allowance appauthserviceA simple user, role and permission manager for Apache Shiro

Adding RTK query to the redux store

The api object needs to be added to the reducer:

import { combineReducers } from 'redux';import { createReducer } from '@reduxjs/toolkit';import { api } from '../api';export default (basename) => combineReducers({    [api.reducerPath]: api.reducer,    basename: createReducer(basename, (builder) => builder),});

The exported function is a reducer creator that can be used to create a redux store state with two values:

1. api which is a redux slice containing all state related to network communication and dowloaded results
2. basename which is a string value holding the react application’s basepath

The creator function can be used to create a redux store:

import rootReducer from './reducers';import { api } from './api';import listeners from './listeners';// Calculate the basename based on the URL of the vite assets directoryconst baseUrl = Array.from(document.scripts).map(s => s.src).filter(src => src.includes('assets/'))[0].replace(/\/assets\/.*/, '');const basename = new URL(baseUrl).pathname;const store = configureStore({    reducer: rootReducer(basename),    middleware: (getDefaultMiddleware) => getDefaultMiddleware().concat(api.middleware).prepend(listeners.middleware),});

First we calculate the application’s basepath from the vite artifact the code is loaded from, then a store is created with a reducer consisting of api and basename, and then two middlewares are added: api and listener

“What is listeners?” you ask at this point.

I am glad you asked! Check out the next section.

For those who like looking at example code, some example redux store setups for RTK query and RTK listener:

appreducersredux store setuphandleregreducers/index.jstop index.jssampleappreducers/index.jstop index.jsoldalbumreducers/index.jstop index.jsukelonnreducers/index.jstop index.jsauthservicereducers/index.jstop index.js

Using RTK listener to perform actions on REDUX actions

Listener fills the same role as another useful saga role: the ability to listen for redux actions and act on them:

import { createListenerMiddleware } from '@reduxjs/toolkit';import { isFailedRequest } from './matchers';const listeners = createListenerMiddleware();listeners.startListening({    matcher: isFailedRequest,    effect: ({ payload }) => {        const { originalStatus } = payload || {};        const statusCode = parseInt(originalStatus);        if (statusCode === 401 || statusCode === 403) {            location.reload(true); // Will return to current location after the login process        }    }})export default listeners;

This listener listens for failed RTK query HTTP calls to the API and checks the status codes for 401 “Needs Authentication” and 403 “Not Authorized” and reloads the app with the current URL to let apache shiro deal with it (refresh the auth and just open this page, pop up login or redirect to unauthorized page).

This is “matchers.js” where isFailedRequest is found:

import { isAnyOf } from '@reduxjs/toolkit';import { api } from './api';export const isFailedRequest = isAnyOf(    api.endpoints.getAccounts.matchRejected,    api.endpoints.getAccount.matchRejected,    api.endpoints.postAccountAdminstatus.matchRejected,    api.endpoints.postAccountModify.matchRejected,);

For those who prefer looking at example code, example listener.js and matcher.js files can be found here:

applisteners definitionmatchershandlereglisteners.js sampleapplisteners.js oldalbumlisteners.js ukelonnlisteners.jsmatchers.jsauthservicelisteners.jsmatchers.js

Using RTK queries’ successful loads in other reducers

It is possible to use the successful completion of a mutation to clear reducers backing forms:

import { createReducer } from '@reduxjs/toolkit';import { SELECT_STORE } from '../actiontypes';import { api } from '../api';const defaultState = {    storeId: -1,    storename: '',    gruppe: 2,};export default const storeReducer = createReducer(defaultState, builder => {    builder        .addCase(SELECT_STORE, (state, action) => action.payload)        .addMatcher(api.endpoints.postNewstore.matchFulfilled, () => ({ ...defaultState }))        .addMatcher(api.endpoints.postModifystore.matchFulfilled, () => ({ ...defaultState }));});

Here both the completion of a successful postNewstore mutation and a successful postModifystore mutation will set the reducer to its default state (and clear the forms backed by the redux state value).

Note the use of addMatcher() rather than addCase() to matche the actions.

All matchFulfilled actions have the same redux type, so traditional redux type matching won’t work. But the matchers provided by the api object can be used instead.

Dependent queries

A common requirement is that one REST call needs the value of another value before being called. For this “dependent queries” in RTK query can be used:

export default function Home() {    const { data: overview = {}, isSuccess: overviewIsSuccess } = useGetOverviewQuery();    const { data: purchases = [] } = useGetPurchasesQuery(overview.accountid, { skip: !overviewIsSuccess });    ...

The above example the getPurchases query needs an account id that can be found in the results of the getOverview query.

The “skip” property of the query option object to useGetPurchasesQuery() prevents useGetPurchasesQuery() from being executed until useGetOverviewQuery() has completed successfully.

Converting apps

For those preferring to look at code, here are the diffs from converting from redux/axios to RTK queries and RTK listeners:

appDescriptionhandleregA groceries tracker and statistics appsampleappA template application for React web applications with jersey backend and PostgreSQL database set up with liquibaseoldalbumAn app wrapping 90-ies albums in 202x web technologyukelonnA weekly allowance appauthserviceA simple user, role and permission manager for Apache Shiro

Reduction of JavaScript source code size for the various apps (source code line numbers from cloc run before and after the conversion):

appsize reduction in %size reduction in #lineshandlereg34%674sampleapp32%359oldalbum14%608ukelonn25%1211authservice31%841

Summing up the numbers from doing the conversion

1. A 14% to 35% reduction of JavaScript code of the apps (with lots of boilerplate gone). The package with lowest percentage has a number of lines reduction on par with the rest of the “real” applications
2. No noticable difference in dependencies size even though I was already using RTK and got rid of redux-saga and axios
3. No significant difference in vite build artifact size (even an increase in one case) (numbers can be provided on request)

As said at the start, the obsoletion of redux-saga made doing this change a non-brainer for me.

But losing all of the boiler plate around network requests made the applications easier to read and understand and maintain. And the logic around lazy loading, reloads and caching of data is a lot better than my home-brewed redux-router powered logic.

I’m not opposed to learning new stuff, but I can be quite reluctant to let go of stuff I like, and I was really happy about redux saga as outlined in Yep, I’m still using redux.

So did I lose anything in this conversion?

Downsides are:

1. Harder to examine data loaded by RTK query in the redux devtools (but still possible)
2. More complex react components:

   1. prior this change, redux served up data ready for consumption in the components and with defaults, i.e. this

      const butikker = useSelector(state => state.butikker);

      is simpler than this:

      import { useGetButikkerQuery } from '../services/butikker';...    const { data: butikker = [] } = useGetButikkerQuery();

   2. Prior to this change, gathering the data for a save to the back end took place in a saga, so there was no need to clutter up the component with data not used in the actual render
3. It’s kinda hard (but not impossible) to use the loaded data as backing storage for the edit form, and then save back from the data. The assumption is that one is to use something like useState() for this, but I don’t wish to do that

But putting stuff back in the react components makes fewer places to look for stuff and makes my react component look more similar to others’ react components, so maybe this isn’t so bad after all…?

Where to go next?

I startet using Redux ToolKit (RTK) back in 2019. I quickly figured that createReducer() and createAction() could make my existing reducers and redux action creation more robust.

I tried using redux slices at that point in time, but since I had to mix the autocreated redux action with manually created redux actions to trigger REST API operations and handle REST API errors, I figured that redux slices was more work than useful.

And I later also landed on the “flattened redux state approach” outlined in Yep, I’m still using redux (see that article for the reasoning) that didn’t fit well with slices, so I dropped it back then.

But with RTK query I no longer have to manually create actions to start API operations or handle errors, since these are created when creating queries or mutations, so maybe it is time to give redux slices a new try…?