Redux异步中间件与通用API函数的代码组织方式咨询

这种将Redux异步Thunk与纯API调用混在同一个类中的组织方式不合理，核心问题是职责不清晰：类名为NftMiddleware，但其中包含了与Redux状态管理完全无关的纯API请求方法，会导致代码可读性和可维护性下降。

为什么要拆分？ #

• 单一职责原则：Redux的createAsyncThunk生成的是与状态绑定的Thunk Action Creator，它的核心作用是触发Redux状态更新；而纯API调用是独立的业务逻辑，不需要依赖Redux，二者职责完全不同。
• 复用性：纯API调用可能在非Redux场景下被复用（比如组件中直接调用提交元数据，不需要更新状态），拆分后可以直接复用API层代码，无需依赖Redux相关模块。
• 可读性：拆分后每个模块的作用一目了然，新接手的开发者能快速区分哪些是状态相关的异步逻辑，哪些是纯后端交互逻辑。

更合理的组织方案 #

推荐按功能模块+职责分层来组织代码，示例如下：

1. 独立的API服务层（纯后端交互逻辑）

创建src/features/nft/nftApi.js，专门存放NFT相关的所有API调用，与Redux完全解耦：

import axios from "axios";
import ApiUrls from "../../ApiUrls";

// 用对象封装纯API方法，无需类
export const nftApi = {
  // 获取NFT列表
  fetchAllNfts: async () => {
    const response = await axios.get(ApiUrls.getAllNftsUrl);
    return response.data;
  },
  // 提交元数据
  postMetaData: async (data) => {
    const response = await axios.post(ApiUrls.postMetaData, data);
    return response.data;
  }
};

2. 独立的Redux Thunk层（与状态绑定的异步逻辑）

创建src/features/nft/nftThunks.js，从API层复用逻辑，专注于Redux状态同步：

import { createAsyncThunk } from "@reduxjs/toolkit";
import { nftApi } from "./nftApi";

// 触发状态更新的Thunk Action Creator
export const fetchAllNfts = createAsyncThunk(
  'nft/fetchAllNfts', 
  async () => {
    // 复用API层的逻辑，避免重复代码
    return await nftApi.fetchAllNfts();
  }
);

3. 模块目录结构优化

按功能模块集中存放相关文件，结构更清晰：

src/
  features/
    nft/
      nftApi.js       # 纯API调用
      nftThunks.js    # Redux异步Thunk
      nftSlice.js     # Redux状态切片（reducer、初始状态等）
  ApiUrls.js           # 全局API地址配置

额外优化建议 #

• 在API层统一处理错误：可以通过axios拦截器添加全局错误捕获、请求头统一设置等逻辑，避免在每个API方法中重复编写。
• 避免过度使用类：纯函数集合用对象封装即可，不需要类的实例化逻辑，代码更简洁。

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