[typescript + createAsyncThunk()] What's the suggested approach for 'dynamic' typing?

[mark-night]

This is not an issue but more of a question regarding understanding redux design philosophy (and so I did not ask on SF).

Say, I have a store slice for different animals:

interface AnimalState {
  dogs: Dog[];
  cats: Cat[];
  ...
}

const initialState: AnimalState = {
  dogs: [],
  cats: []
}

const animalsSlice = createSlice({
  name: 'animals',
  initialState,
  reducers: {/* ... */},
  extraReducers: builder => { /* ... */ }
})

A typical async thunk for creating new dog could be:

export const createDog = createAsyncThunk<
  Dog,
  Omit<Dog, 'id'>,
  { /* ... */ }
>('animals/createDog', async (dogData) => { /* thunk logic */ })

This works great. The thing is, the one for creating new cat (and all other animals) are exactly the same, so I want to make it a little bit more flexible to avoid repeat codes.

The first approach I tried, was to play with the type generic for createAsyncThunk(), where I tried to fit in an union to infer the animal to be created, something like this:

type Kind = 'dog' | 'cat';
type Animal<T extends Kind> = T extends 'dog' ? Dog : Cat;

export const createAnimal = createAsyncThunk<
  Animal<K>, // <-- is it possible to define `K` somewhere so the generic can pick it up?
  { kind: K; data: Omit<Animal<K>, 'id'> }, // <-- so animal kind could be inferred from thunkArg...
  { /* ... */ }
>('animals/create', async (animalData) => { /* ... */ })

This obviously won't work, because I can't define K anywhere for the generic... but you get the idea.

The second approach I tried, is to create an async thunk factory, something like:

function getAsyncThunk<K extends Kind>(kind: K) {
  return createAsyncThunk<
    Animal<K>,
    Omit<Animal<K>, 'id'>,
    { /* ... */ }
  >(`animals/create${kind}`, (animalData) => { /* ... */ })
}

export const createDog = getAsyncThunk('dog')
export const createCat = getAsyncThunk('cat')
...

The second approach works fine, but still, feels kinda repetitive, and will add more work on the reducer part. I would definitely prefer more on createAnimal('dog') rather than createDog(), createCat()......

Question:

• What is the suggested approach/pattern for this kind of usage?
• Is the idea behind the first approach (abstracting common action creators) an anti-pattern? I.e. one action creator touching multiple slice fields or even multiple state slices should be avoided?

[mark-night]

BTW, this is just an abstracted conceptual example, in my real case, Dog and Cat are very different objects, which are meant to be managed in store separately. It's just the async thunk for CRUD operations are very similar, and so is the reducers logic.

[phryneas]

As for your first approach: without an outer closure you won't be able to specify your K.

As for the second: it's probably not becoming a lot shorter than this.

Is the idea behind the first approach (abstracting common action creators) an anti-pattern? I.e. one action creator touching multiple slice fields or even multiple state slices should be avoided?

Not really, it's just a little less readable in the devtools. We essentially do the same in RTK Query.

Generally: if this is just fetching logic, you might also be interested to look into RTK Query? https://redux-toolkit.js.org/rtk-query/overview
But beware, that one is a document cache, not a normalized one.

[mark-night]

@phryneas Thanks for the hint.

Not sure if I explained and understood this correctly, but:
First approach intended to get an universal AsyncThunk, which when being called , can infer K from the thunkArg and give correct typing for other part of thunkArg and as well the fulfilled payload, i.e.,

export const createAnimal = /* some magic to get the universal AsyncThunk */

dispatch(createAnimal({
  kind: 'dog', 
  data: { /* typed for dog data */ }  /* <-- fulfilled payload would be Dog */
})); 
dispatch(createAnimal({
  kind: 'cat', 
  data: { /* typed for cat data */ }  /* <-- fulfilled payload would be Cat */
})); 

kinda like overloads for payloadCreator (the second argument for createAsyncThunk()). I might be confusing some of the terms (new to TS and RTK), but to my best understanding, K would need to be inferred in payloadCreator().
So, if use an outer closure to specify K, then K would have to be inferred from the 'outer closure' as well. In other words, approach 2 is indeed an implementation to make approach 1 work, and there is really no way to get such an 'universal' AsyncThunk?
I've actually tried to define overloads for my payloadCreator() with no luck, particularly if I need thunkAPI which can only be specified in generic for createAsyncThunk(), felt like a dead loop there.
(Per my best guessing, it's possible to override the type definition to add more parameters to the generic for createAsyncThunk(), but that's too far for now, let's ignore that and stick to the official type definitions. )

I haven't test, but I believe there shouldn't be any trouble to go with approach 1 with JavaScript, it's just kinda trade off with TS given current type definition for RTK?

As for the second: it's probably not becoming a lot shorter than this.

I don't quite understand this. Did you mean it's actually the correct way to go with, or, it's not worth doing it?

it's just a little less readable in the devtools. We essentially do the same in RTK Query.

How do you handle the K case (or similar) in RTK Query?

Approach 2 is already working, it's just that a full set of thunks/reducers would be needed for each animal (and I have many animals), provided matching utilities would save some for reducers for sure, but still, they look really repetitive, although very clear...
An universal AsyncThunk that tweaks itself internally by inferring requirements from thunkArg when being dispatched, would really be very helpful in such case, just kinda stuck with typing for now. Any ideas?

you might also be interested to look into RTK Query

Yes, that's on my list, looks interesting! I'm new to TS and RTK, rewriting a side-project (written in JS and traditional redux pattern) with TS and RTK, trying to learn TS and RTK. Leaving RTK Query alone for now just to keep things limited. :)