redux-toolkit: Accessing the original error in createAsyncThunk

Ok, just for future Googler’s who can’t seem to figure out how to access the original response body. I’ve created a helper api class (as follows)

const handleRequest = (request, thunkApi) =>
    request
            .then(response => response.data)
            .catch(error => thunkApi.rejectWithValue(error?.response?.data || error))

const buildUrl = (url, params) => {
    // Support URLs with named identifiers, such as '/posts/get/:id'.
    // This code replaces the ':id' part with the value of params.id
    Object.keys(params).forEach(k => {
        if (url.indexOf(':' + k) > -1) {
            url = url.replace(':' + k, params[k])
            delete params[k]
        }
    })

    // all the parameters that were not bound to a named identifier are appended to the URL
    const encoded = Object.entries(params).map(kv => kv.map(encodeURIComponent).join("=")).join("&")
    return url + (encoded.length > 0 ? '?' + encoded : '')
}

export default class api {
    static post = (url, axiosConfig = {}) => (obj = {}, thunkApi) =>
        handleRequest(axios.post(url, obj, axiosConfig), thunkApi)

    static get = (url, axiosConfig = {}) => (obj = {}, thunkApi) =>
        handleRequest(axios.get(buildUrl(url, obj), axiosConfig), thunkApi)

    static delete = (url, axiosConfig = {}) => (obj = {}, thunkApi) =>
        handleRequest(axios.delete(buildUrl(url, obj), axiosConfig), thunkApi)
}

just so that I can easily create async thunks like this

import {createAsyncThunk} from '@reduxjs/toolkit'
import api from "service/api"
export const requestPasswordReset = createAsyncThunk('login/requestReset', api.post('/password/email'))

and refer to the originally returned JSON in my extraReducers as follows

        [requestPasswordReset.rejected]: (state, action, more) => {
            state.loading = 'error'
            state.error = action?.payload
        },

Now, state.error will contain the JSON that was returned by my API. Hope this helps someone.

Hi, I updated the code in my comment so that you can now also properly use parameters in GET and DELETE requests. There’s even support for named parameters, so your URL can be something like “/post/get/:id” and it will replace the :id with the appropriate value.

You can pass these values when dispatching the action, for example

this.props.dispatch(requestPasswordReset({username:"someone@example.com"})

Thank you very much for fixing it in a better way. But I took the following method to make the url change for the axios method and the choice for params, queryString more convenient.

users.js

import {createAsyncThunk} from '@reduxjs/toolkit'
import {http, thunkHandler} from '../utils/api';

export const signInUser = createAsyncThunk(
    'users/signInUser',
    (user, thunkAPI) => thunkHandler(http.post('/users/signIn', user), thunkAPI);
)

api.js

export const http = axios.create({
    baseURL: apiUrl,
    headers: {
        Accept: 'application/json',
        'Content-Type': 'application/json'
    },
});

export const thunkHandler = async (asyncFn, thunkAPI) => {
    try {
        const response = await asyncFn;
        return response.data.result;
    } catch (error) {
        return thunkAPI.rejectWithValue(error.response.data);
    }
};

@phryneas Thanks for the insight!

Do you need Redux at all here? In this instance, let’s pretend we’re doing PUT /users on form submit that either returns a new user instance { user: { id: 1, name: test, ... } or an error with some validation issues that come back in a 400 with a detailed message as shown. Typically, this would be a thunk as you’re going to have a reducer handle inserting the returned user upon success.

Do you need redux at this point?

No, not really - we could dispatch an addUser() action after the success, or a setErrorMessage on the failure in the event we - but IMO this is more tedious and eliminates the point of a createAsyncThunk abstraction.

Is this an error from the programmer’s view?

I might not be understanding correctly, but if you returned the error in the payloadCreator after catching it, you’d then be doing things like this, which seems like a more confusing approach?

[updateUserThunk.fulfilled]: (state, { payload }) => {
 // we would need to force a check here, always, as we could be returning "an error"
if (payload.user) {
  state.users = upsert(payload.user)
}

My other thought matches up with yours and I’d be happy to open a PR with that as well:

We could even think about bailing from miniSerializeError from conditions like err.constructor === Object or !(/(error|exception)/i.test(err.constructor.name)) - as this will probably be developer-provided data. If that isn’t serializable, the serializability check will warn the developer in dev mode about it.

I think this is probably the best approach. My only additional feedback there is we might want to consider forcing a standardized error format when throwing a custom error object - the current format looks good, but we’d want to add a key such as data. In my example, that would look like this:

export const axiosUpdateThunk = createAsyncThunk(
  "users/update",
  async ({ data }) => {
    try {
      const result = await axios.put(`api/users`, data);
      return result.data;
    } catch (err) {
      const customError = {
        name: "Custom axios error",
        message: err.response.statusText,
        data: err.response.data // serializable
      };
      throw customError;
    }
  }
);

The benefit of this being an established pattern that offers predictable handling inside of all reducers - [whatever.rejected]: (state, action) => { state.error = action.payload.error } would always have the given shape. I could also see the counterpoint where this library shouldn’t care about if a developer wants to dump an error with no context into the error message and we just serialize it away - but I think allowing that to happen in the data field is a good compromise.

Based on the example from @infostreams this is what I came up with … just incase it helps someone else.

UPDATED per the suggestions from @markerikson. Thank you!

import {createAsyncThunk, createSlice} from '@reduxjs/toolkit'
import axios from "axios";

export const signInUser = createAsyncThunk(
  'users/signInUser',
  async (user, thunkApi) => {
    return axios.post('/users/signIn', user)
      .then(response => response.data.results)
      .catch(error => thunkApi.rejectWithValue(error?.response?.data || error))
  }
)

export const usersSlice = createSlice({
  name: 'users',
  initialState:  { user: {}, errors: [] },
  reducers: {},
  extraReducers: builder => {
    builder
      .addCase(signInUser.pending, state => {
        state.errors = []
      })
      .addCase(signInUser.fulfilled, (state, action) => {
        state.errors = [];
        state.user = action.payload;
      })
      .addCase(signInUser.rejected, (state, {payload}) => {
        switch (payload?.response?.status) {
            case 401:
                state.errors.push({ error: "Access denied." }); break;
            case 403:
                state.errors.push({ error: "Forbidden." }); break;
            default:
                state.errors.push(payload); break;
        }
      })
  }
});


export const { } = usersSlice.actions;
export default usersSlice.reducer;

Hi, I updated the code in my comment so that you can now also properly use parameters in GET and DELETE requests. There’s even support for named parameters, so your URL can be something like “/post/get/:id” and it will replace the :id with the appropriate value.

You can pass these values when dispatching the action, for example

this.props.dispatch(requestPasswordReset({username:"someone@example.com"})

@jmuela1015 two quick suggestions syntactically:

• We strongly recommend using the “builder callback” syntax for extraReducers: https://redux-toolkit.js.org/api/createSlice#the-extrareducers-builder-callback-notation
• Because createSlice uses Immer, you can “mutate” the array with state.errors.push() instead of state.errors = [...state.errors]

how pass parameters ??

export const requestPasswordReset = createAsyncThunk('login/requestReset', api.post('/password/email'))

Hmm…

This makes me question two things:

• Do you need Redux at all here?

If you go to the lengths to even do exception handling from your component - are you even using the global store here? Does Redux make your life more easy here, or is it just a burden? Do you maybe even throw away the submission result (beyond the errors), so nothing of meaning would ever be stored in your redux store?

• Is this an error from the programmer’s view?

Sure, for the user it’s an error. But for you as a programmer, that seems more like a result that you are maybe even expecting on more than 50% the responses. Is this still an error? Or wouldn’t it make more sense to reserve the error/rejected way for things like connection timeouts etc. and handling this as a part of the “fulfilled” route? I mean, the fetch was a success, it’s just not the result the user wants to see, but for your app it’s a pretty normal state, not really an “exception”. So you could just return this from the payloadCreator.

@markerikson

Can we do an instanceof Error check here?

I’d rather not go down this road. In TypeScript, just extending Error will give you a class that does not really extend error. You’ve got to do extra magic to get a class that extends Error from the engine viewpoint. So this is a very unreliable check for anything.

We could allow the payloadCreator to return/throw own fulfilled/rejected actions (check isFSA and actionCreator.fulfilled.match/reject on the return value/error) and let those override our finalAction. For those, we could just assume that they are serializable.

We could even think about bailing from miniSerializeError from conditions like err.constructor === Object or !(/(error|exception)/i.test(err.constructor.name)) - as this will probably be developer-provided data. If that isn’t serializable, the serializability check will warn the developer in dev mode about it.

Per DMs, my inclination at this point is that if you need to reformat anything from the server, it’s your job to do it in the payload creator.

Axios requests where you need to grab something out of response.data, normalization of entity data, extracting important values from a server error… we don’t know anything about that ourselves. Do it yourself in the payload creator, and whatever you return or throw will end up in the corresponding action.