Possibility of customising function that generates requestId in the action's meta of createAsyncThunk

[dwiyatci]

Hi! :) First of all, let me express my gratitude that this library (toolkit) had already existed back in February/March when I first re-architected some project at my current company – it's been making my life so much easier since then, and fun to use – so a big THANK YOU! 🙏😇🙇🏻‍♂️🙇🏻‍♂️

Recently though, there is one aspect/requirement that I have to fulfil in my app, which is all the network requests have to be able to be tracked by uuidv4 (to conform with the existing logging/analysis infrastructure).

As I want to make use of the RTK built-in feature as much as possible, would it be possible to add a possibility to pass a custom function other than nanoid (in my case, it'd be uuidv4) to generate the action.meta.requestId used by createAsyncThunk?

This is a rather simplistic construct of how my slice would look like:

extraReducers: {
  [fetchSomething.pending]: (state, action) => {
    state.loading = true;
    state.pendingRequestIds.push(action.meta.requestId);
  },
},

I mean, currently, to satisfy this requirement, I'm making use of action.meta.arg.requestId and doing the wiring when dispatching: dispatch(fetchSomething({ requestId: uuidv4() })). So I thought it would be nice and cleaner if this feature could be implemented per se.

Thank you.

[markerikson]

Hmm. Yeah, I think it would be fairly straightforward to let createAsyncThunk take some kind of an idGenerator field in in the options object, like:

createAsyncThunk(
  'some/type',
  payloadCallback,
  {idGenerator: uuid4}
);

If you'd like to file a PR that adds that, we can see how it looks.

[codetestmg]

I have passed idGenerator as mentioned above but still it take default nanoid value

{
        idGenerator: () => "Test"+nanoid(5)
}

but it returned requestId: "mVTRmxQpvzeNplGd-N0pr"

.is there any issue with my implementation ?

Thanks

[markerikson]

@codetestmg The PR that adds that option was merged, but we haven't shipped a new release yet containing that change. It's slated to go out in 1.6.0, which may take a bit because we need to finalize the RTK Query implementation and merge it back over here.

[codetestmg]

@markerikson .Thank you so much for the quick reply. thanks for the library