如何在Redux Toolkit的asyncThunk中调度另一个asyncThunk及解决执行异常

第一种直接在bar内调用foo()的写法问题 #

• createAsyncThunk执行后返回的不是内部的异步请求函数本身，而是一个Redux风格的action creator。直接调用foo()只会生成一个形如{type: 'slice/foo/pending', ...}的普通action对象，既不会经过store的dispatch流程触发内部的fetch逻辑，也没有请求返回的数据结构。
• 你代码里写的const res = await foo()，await拿到的是刚才生成的action对象，访问res.data自然得到undefined，最终bar的逻辑因为拿不到预期值无法正常执行。你感知到的“foo被正常调度”，实际是在Redux DevTools里看到了foo生成的action记录——这个action只是被创建了，并没有经过store的执行流程，所以foo内部的fetch逻辑根本没有真正运行。

第二种使用thunkAPI的写法问题 #

• createAsyncThunk的payload creator函数有固定的参数签名：async (传入的action参数, thunkAPI工具集) => {}。第一个形参接收的是你调用bar()时传入的自定义载荷值，第二个形参才是包含dispatch、getState等方法的thunkAPI对象。
• 你把第一个形参命名为thunkApi，实际接收到的是调用bar()时传入的undefined（因为你写的是dispatch(bar())没有传任何参数），自然访问thunkApi.dispatch时会抛出Cannot read property 'dispatch' of undefined的错误。

• 严格按照payload creator的参数顺序接收值，从第二个形参里解构拿到dispatch方法
• 调度foo时需要等待执行完成，通过.unwrap()方法拿到foo内部返回的实际业务数据，再执行bar的后续逻辑。如果不调用.unwrap()，await拿到的会是Redux封装后的action元信息，且不会在foo执行失败时抛出可捕获的错误。
• 你在useEffect里写的await dispatch(bar())的逻辑本身没有问题，当bar的内部逻辑修正后，这个等待会正常捕获bar的执行完成时机。

示例代码：

export const bar = createAsyncThunk(
    'slice/bar',
    async (barArg, thunkAPI) => {
        const { dispatch } = thunkAPI;
        // 等待foo执行完成，拿到请求返回的业务数据
        const fooResponseData = await dispatch(foo()).unwrap();
        // 后续基于foo的结果执行bar的自定义逻辑
        const res = await fetch('/bar', { data: fooResponseData });
        return res.data;
    }
);

补充提示：这种嵌套dispatch的写法是Redux Toolkit完全支持的合法用法。如果要降低两个thunk的状态耦合，更通用的优化方案是把公共的请求逻辑抽成独立的纯函数工具，在两个thunk内部直接复用该工具函数，而非通过dispatch触发另一个thunk。

内容的提问来源于stack exchange，提问作者LorDex