store配置中应用thunk中间件与createAsyncThunk的区别及优劣势

实现逻辑差异 #

1. applyMiddleware(thunk) 挂载thunk中间件方案 #

thunk是Redux官方最早推出的异步中间件，核心逻辑非常简单：改造Redux的dispatch方法的入参校验规则，原生Redux的dispatch只支持传入普通JS对象类型的action，接入thunk中间件后，如果dispatch接收到的入参是函数类型，就会直接执行这个函数，同时把dispatch、getState两个方法作为参数传入该函数。
你可以在这个函数内自由编写异步逻辑（比如发起接口请求、定时器操作等），异步执行的不同阶段（请求发起、成功、失败）手动调用dispatch触发对应普通action更新状态即可。thunk的源码只有十几行，没有任何额外封装。

2. createAsyncThunk() 方案 #

createAsyncThunk是Redux Toolkit（简称RTK）内置的异步工具API，底层本质还是基于thunk中间件实现，属于官方在thunk基础上做的上层封装。
你只需要传入业务侧的异步执行函数，它会自动为你生成对应异步流程的pending/fulfilled/rejected三个状态的action creator，不需要你手动定义这三类action，也不需要你在异步逻辑里手动分发不同状态的action，它会自动监听异步函数的执行状态，自动触发对应action。你只需要在createSlice的extraReducers配置里监听这三个自动生成的action，就能完成状态更新。它还内置了请求去重、异常捕获、异步任务标识管理等能力。

优劣势对比 #

thunk中间件方案 #

• 优势：
  • 灵活性极强，没有任何封装约束，你可以完全自定义异步流程的所有逻辑
  • 体积极小，只有十几行源码，无额外依赖
  • 学习成本极低，只要掌握Redux基础和JS函数用法就能上手
• 劣势：
  • 样板代码量极大，每个异步流程都需要手动定义三类action、手动编写状态判断逻辑、手动分发对应action
  • 无统一规范，不同开发者编写的异步逻辑风格差异极大，项目后期维护成本高
  • 没有内置任何通用能力，异常捕获、请求去重、loading状态管理等都需要自己手动实现

createAsyncThunk方案 #

• 优势：
  • 大幅减少样板代码，不需要手动定义action、不需要手动处理异步状态分发
  • 官方统一了异步逻辑的书写规范，团队项目内代码风格一致，维护成本低
  • 内置异常捕获、重复请求拦截、异步状态自动管理等通用能力，不需要自己重复造轮子
  • 和RTK的createSlice、configureStore等能力深度适配，开发效率更高
• 劣势：
  • 有额外的学习成本，需要掌握RTK的相关概念和API规则
  • 灵活性低于原生thunk，非常定制化的复杂异步流程会受封装限制
  • 依赖RTK环境，无法单独在原生Redux项目中使用

适用场景差异 #

• 适合选thunk中间件的场景：
  • 项目使用原生Redux，没有引入RTK
  • 异步逻辑定制化程度极高，需要精细控制异步流程的每个环节，createAsyncThunk的封装无法满足需求
  • 项目对产物体积要求极高，不能引入RTK这类额外依赖
• 适合选createAsyncThunk的场景：
  • 项目已经接入RTK作为状态管理方案
  • 异步逻辑以常规的接口请求为主，不需要太复杂的自定义控制
  • 团队需要统一异步代码的书写规范，降低后期维护成本
  • 需要用到请求去重、异常自动处理等内置能力，减少重复开发工作量

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