Suggestion: Update mapBuilders to make it easy to add thunks to a slice

[edishu]

I've reviewed issues: #629 and #1045 and looks like due to TS complexity support for defining thunks in createSlice has not been possible.

However, a simpler solution can be adopted which can simplify many common use cases of using thunk in createSlice.
Adding a function like addAsyncThunk to builder object will help in setting loading conditions automatically for thunk related actions.

So presently when a user is adding thunk (myThunk) to a slice code looks like:

createSlice({
    name: "mySlice",
    initialState,
    reducers: {},
    extraReducers: (builder) => {
        builder
          .addCase(myThunk.pending, (state) => {state[loadingKey] = true})
          .addCase(myThunk.rejected, (state) => {state[loadingKey] = false})
          .addCase(myThunk.fulfilled, (state, action) => {state[loadingKey] = false; ...other updates})
    }
})

For a slice which has many thunks this becomes very long chain, hard to read and debug.
addAsyncThunk will simplify most common use cases in which pending/rejected actions only change the loading state.

So the above code will look like:

createSlice({
    name: "mySlice",
    initialState,
    reducers: {},
    extraReducers: (builder) => {
        builder
          .addAsyncThunk(myThunk, loadingKey: string, fulfilledCallback)
    }
})

[phryneas]

For what it's worth, this is possible to implement in userspace - if you know the trick:

import {ActionReducerMapBuilder, CaseReducer, AsyncThunk} from '@reduxjs/toolkit'
import {AsyncThunkFulfilledActionCreator} from '@reduxjs/toolkit/dist/createAsyncThunk'

function addAsyncThunk<S, Returned>(builder: ActionReducerMapBuilder<S>, thunk: AsyncThunk<Returned, any, {}>, loadingKey: keyof S, fulfilledCallback: CaseReducer<S, AsyncThunkFulfilledActionCreator<Returned, any, {}>>){
  builder.addCase(thunk.fulfilled, (s,a) => {
    s[loadingKey] = true
    fulfilledCallback(s,a)
  })
  builder.addCase(thunk.rejected, (s,a)=> {
    s[loadingKey] = false
  })
  builder.addCase(thunk.pending, (s,a)=> {
    s[loadingKey] = true
  })
}

This will still need a little more massaging around the types (I'm in a hurry), but it should show how you can do that with given tools already.

[edishu]

@phryneas this definition creates a standalone function addAsyncThunk. Extending createSlice such that addAsyncThunk is available in extraReducers callback argument improves usability. Otherwise users will have to know/remember to import addAsyncThunk.

[markerikson]

@edishu I think the point is that A) loading state handling is going to be unique to a given project, and B) given that it's relatively simple to write a function like this on your own, it's not something we would immediately want to build in to createSlice for now.

[phryneas]

Exactly what Mark says. Loading logic is something that can be implemented in 20 different ways - and every of those ways makes more sense than anything else in some application. Someone could have an array of loading request ids. Or a counter of currently loading requests. Both of these could be centralized for all thunks, or just part of the same thunk that also receives the data. Or like you have it here, one loading indicator per thunk - which might totally not make sense if a thunk could run multiple times concurrently. We don't know what you need, and given that we already ship one solution that takes care of all of that with RTK query, createAsyncThunk is more a building block for all of those other solutions, so shipping only one more solution while leaving all others behind feels wrong. We could add a few different approaches as recipes to the docs though - if you feel like polishing the example i made here (or coming up with your own). 🙂 12.05.2022 18:42:42 Mark Erikson ***@***.***>:

…

@edishu[https://github.com/edishu] I think the point is that A) loading state handling is going to be unique to a given project, and B) given that it's relatively simple to write a function like this on your own, it's not something we would immediately want to build in to *createSlice* for now. — Reply to this email directly, view it on GitHub[#2316 (comment)], or unsubscribe[https://github.com/notifications/unsubscribe-auth/ABAVQR2TWXJEYK3LMXCXL7TVJUYHZANCNFSM5VWOAW3Q]. You are receiving this because you were mentioned.[Verfolgungsbild][https://github.com/notifications/beacon/ABAVQR3KBU3UZ6RNEOWY2NDVJUYHZA5CNFSM5VWOAW32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOIMIVFDQ.gif]

[edishu]

@markerikson @phryneas Thanks for clarification! I can use a function like you have suggested.