Support optional `AbortSginal` argument when dispatch thunk action

[chigia001]

In our codebase, we have some thunk that trigger another thunk.

Example:

const getEmployer = createAsyncThunk('getEmployer', () => {
  // retrieve employer of from current user
})

const getEmployee = createAsyncThunk('getEmployee', ({id}) => {
  // retrieve employee of from employer's id
})

const getColleagues = createAsyncThunk('getColleagues', ({}, {dispatch, signal}) => {
  if (signal.aborted) {
   return;
  }
  const employerThunk = dispatch(getEmployer())

  signal.addEventListener('abort', () => {
    employerThunk.abort()
  })

  const employer = await employerThunk.unwrap()

  if (signal.aborted) {
   return;
  }
  
  const employeeThunk = dispatch(getEmployee({id: employer.id}))

  signal.addEventListener('abort', () => {
    employeeThunk.abort()
  })

  return employeeThunk.unwrap()
})

useEffect(() => {
  const colleagueThunk = dispatch(getColleagues())

  setTimeout(() => {
    cooleagueThunk.abort()
  }, 1000)
}, [])

to successfully abort those inner thunk we need to add a hand full of code

if possible, can we pass the AbortSignal somehow to the action creator itsel and then RTK handle can handle them?

const getEmployer = createAsyncThunk('getEmployer', () => {
  // retrieve employer of from current user
})

const getEmployee = createAsyncThunk('getEmployee', ({id}) => {
  // retrieve employee of from employer's id
})

const getColleagues = createAsyncThunk('getColleagues', ({}, {dispatch, signal}) => {
  if (signal.aborted) {
   return;
  }

  // passing signal from parent thunk
  // even better if rtk can detect that signal already aborted and omit the thunk 
  // like how condition behave.
  const employer = dispatch(getEmployer(undefined, {signal})).unwrap()

  if (signal.aborted) {
   return;
  }

  // passing signal from parent thunk  
  return dispatch(getEmployee({id: employer.id}, {signal})).unwrap()
})

useEffect(() => {
  const timeout = AbortSginal.timeout(1000);

  // passing signal from parent code.
  dispatch(getColleagues(undefined, {signal}));
}, [])

I think this change align with the ecosystem as most API that support AbortSginal/AbortController allow receive AbortSginal from invoke method.

My main concern with above suggestion is that the interface is a little bit wonky for action creator without argument.

Another interface we can explore is withMeta property, similar to the pending, rejected, fullfilled action type reference. But now the meta like signal will be alway be the first argument, the action creator argument will be the 2nd argument if they need. It also allow caller to pass meta information to reducer.

const getEmployer = createAsyncThunk('getEmployer', () => {
  // retrieve employer of from current user
})

const getEmployee = createAsyncThunk('getEmployee', ({id}) => {
  // retrieve employee of from employer's id
})

const getColleagues = createAsyncThunk('getColleagues', ({}, {dispatch, signal}) => {
  // asumpt rtk already handle Canceling Before Execution with signal
  const employer = dispatch(getEmployer.withMeta({signal})).unwrap()
  return dispatch(getEmployee.withMeta({signal}, {id: employer.id})).unwrap()
})

useEffect(() => {
  const timeout = AbortSginal.timeout(1000);

  // passing signal from parent code.
  dispatch(getColleagues.withMeta({signal}));
}, [])

[schontz]

Each thunk has access to a signal as part of the thunk API. It would be great if you could pass in an AbortSignal to dispatch to "bring your own abort."

dispatch(someThunk(), { signal });

[EskiMojo14]

hmm, the only thing is that the internal abort is expected only to have strings as its reason, so we couldn't safely pass the reason from the external signal to the internal one. We could have a set string, like "Passed signal was aborted" maybe 🤔

[schontz]

The internal one can still wrap it, for sure. Either way, a second argument to dispatch makes more sense than additional args to the action creator.

[EskiMojo14]

i disagree, passing it to the thunk creator makes perfect sense. It's never been a pattern to be able to pass more arguments to dispatch - the vast majority of middlewares will completely throw it away anyway:

const myMiddleware = (storeApi) => (next) => (action) => {
  return next(action); // and it's gone!
}

[schontz]

Ah, good point!

[markerikson]

Out in https://github.com/reduxjs/redux-toolkit/releases/tag/v2.6.1 !