does redux toolkit include any function to automatically generate reducers for thunks?

[danielo515]

Hello, thanks for the toolkit. The type safety is the best thing so far.
I noticed that I have a lot of similar reducers for async thunks to handle pending, error and fulfilled states.
Before I add my own abstraction I wanted to ask if this toolkit has anything similar.

Regards

[markerikson]

Nothing specific, no. The closest would be the CRUD reducers from createEntityAdapter, but those don't track any kind of status values.

However, that is the whole purpose of RTK Query - to automatically manage all the data fetching for you, including all the loading state:

https://redux-toolkit.js.org/rtk-query/overview

[msutkowski]

There was also a thread somewhere a long while ago that had a concept of a cAT factory for this exact purpose... and I found this in my codesandbox drafts in case its any help: https://codesandbox.io/s/create-asyncthunk-ex-forked-28k1d?file=/src/crud-factory.ts.

[markerikson]

Probably thinking of #603 , which did have several useful code examples in there.

[msutkowski]

Probably thinking of #603 , which did have several useful code examples in there.

Exactly! My search-foo is poor sometimes :(

[markerikson]

heh, in this case I knew the title of that thread had "CRUD" in it and it was a closed issue, so was able to pull it up pretty fast :)

[danielo515]

Awesome! Thanks for the links!

[phryneas]

@danielo515

I already have a library to track local cache and so, firebase.

I am a bit confused here. If firebase would already be tracking your cache for you in a manner that you could use it, you would not need Redux at all here, or am I wrong?
RTK Query is exactly what you describe here: an automatically generated reducer for your api. For usage with Firebase & co, you would use queryFn instead of making direct http requests.
What exactly is RTK Query doing that you do not want it to do in this instance?

[danielo515]

I am a bit confused here. If firebase would already be tracking your cache for you in a manner that you could use it, you would not need Redux at all here, or am I wrong?

Redux is just an abstraction layer over my API layer. My app was previously built to consume a rest API that I built myself. Then I wanted to add proper authorization and data syncing between instances and I decided that picking an already existing solution like firebase. Thanks to the fact that I had an API layer that was just being used to populate the Redux store all I had to do was to write a different API layer to use firebase and the rest of the app remain untouched. That is where Redux adds value for me.

I read the docs about RTK Query and it seems to be specifically targeting REST APIs. Unless I missed something on my scan of the docs doesn't provide enough flexibility for my use-case while adding certain level of complexity, required knowledge and also bundle size. I am happy with my current setup, the only tedious part is converting all the old thunks I have (with manual dispatching of request states) to RTK ones. Sure it is way les code but now that I am migrating them all I noticed the pattern and I wanted to know if there were some simple solution to it.

Regards

[phryneas]

seems to be specifically targeting REST APIs.

That's a misconception. fetchBaseQuery targets REST apis and is included because it is the most common use case.
But RTK Query can be used with any transport mechanism - people even use it to interact with local databases or calls to platform-native async methods in mobile apps (Expo etc).

There is also a graphql base query in @rtk-query/graphql-request-base-query and you can also use fakeBaseQuery and use queryFn to just call your firebase javascript functions instead of using any functional base query.

[danielo515]

This is what I have so far. I'm happy that I was able to use string literal types to type the expected initial state values:

import { createAsyncThunk, createReducer, Draft, PayloadAction } from '@reduxjs/toolkit';

type LoadingState<State,Prefix extends string> = State &
    { [key in `${Prefix}Error`]: string | null; }
    &
    { [key in `${Prefix}Pending`]: boolean; }

type Arguments<State, Args, Returned, Prefix extends string> = {
    actionName: string;
    prefix: Prefix;
    payloadCreator: (args: Args) => Promise<Returned>;
    initialState: LoadingState<State,Prefix>;
    onFulfilled: (
        state: Draft<LoadingState<State,Prefix>>,
        action: PayloadAction<
            Returned,
            string,
            { arg: Args; requestId: string; requestStatus: 'fulfilled' }
        >,
    ) => LoadingState<State,Prefix>;
};

export function createAsyncReducer<State extends object, Args, Returned, Prefix extends string>({
    prefix,
    payloadCreator,
    initialState,
    onFulfilled,
    actionName,
}: Arguments<State, Args, Returned, Prefix>) {

    const errorKey = `${prefix}Error` as const;
    const pendingKey = `${prefix}Pending` as const;
    const action = createAsyncThunk(actionName, payloadCreator);

    const reducer = createReducer(initialState, builder => {
        builder.addCase(action.pending, state => {
            return {
                ...state,
            [pendingKey]: true,
            [errorKey]: null,
            }
        });
        builder.addCase(action.rejected, (state, { error }) => {
            return {
                ...state,
                [pendingKey]: false,
                [errorKey]: error.message || 'Unknown error',
            };
        });
        builder.addCase(action.fulfilled, onFulfilled);
    });

    return {
        action,
        reducer,
    };
}

It has the advantage that, if I don't provide the correct initial state shape, then it complains:

The only thing I don't like is using separate statuses for loading and error props. I will probably refactor it to use a sum type.