React-select-async-paginate异步分页加载函数如何实现泛型可配置改造

核心改造思路 #

完全将和业务强绑定的字段映射、分页判断逻辑从通用加载函数中抽离，通过入参传入的配置完成规则适配，从根源上消除url.includes()这类和路由强耦合的硬编码分支，全程通过泛型约束替代any类型，保证类型安全。你之前考虑的「通过参数传入字段配置key」的方案可直接落地，且可扩展支持自定义转换逻辑，灵活度更高。

基础类型定义 #

首先定义所有复用的通用类型，避免重复的any标注：

// 组件要求的分页附加参数结构
type AdditionalProps = {
  page: number;
};

// 入参配置类型，承载所有业务相关的规则
type LoadOptionsConfig<ItemType, MetaType> = {
  // 带占位符的请求地址，占位符和原有替换逻辑完全一致
  requestUrl: string;
  // 选项字段映射配置
  fieldConfig: {
    // label取值支持两种形式：直接指定数据对象上的字段key（覆盖简单单字段映射场景）、传入自定义转换函数（适配多字段拼接、值格式化这类复杂需求）
    label: keyof ItemType | ((item: ItemType) => string);
    // value取值支持自定义，默认兜底取item的id字段，无需重复写配置
    value?: keyof ItemType | ((item: ItemType) => string | number);
  };
  // 分页判断配置
  paginationConfig: {
    // 从响应meta中获取总页数的规则，适配不同接口的meta结构差异
    getLastPage: (meta: MetaType) => number;
  };
};

泛型工厂函数实现 #

抽离通用的分页加载逻辑，返回适配react-select-async-paginate要求的loadOptions函数：

// 保留项目原有的网络请求工具
import { networkRequest, httpClient } from "你的项目工具路径";

export function createPaginatedLoadOptions<ItemType, MetaType>(
  config: LoadOptionsConfig<ItemType, MetaType>
) {
  const { requestUrl, fieldConfig, paginationConfig } = config;

  // 返回完全符合组件要求的loadOptions函数
  return async function loadOptions(
    search: string,
    loadedOptions: any[],
    additional: AdditionalProps
  ) {
    const { page } = additional;
    // 类型标注响应结构，避免any
    const response = await networkRequest(() =>
      httpClient.get(
        requestUrl
          .replace(":page", page.toString())
          .replace(":keyword", search)
      )
    ) as { data: ItemType[]; meta: MetaType };

    // 统一处理选项映射，无任何硬编码分支
    const options = response?.data?.map((item) => {
      // 处理label取值
      const label = typeof fieldConfig.label === "function"
        ? fieldConfig.label(item)
        : String(item[fieldConfig.label]);
      // 处理value取值
      const value = fieldConfig.value
        ? (typeof fieldConfig.value === "function"
            ? fieldConfig.value(item)
            : item[fieldConfig.value])
        : (item as any).id;

      return { label, value };
    }) ?? [];

    // 分页判断逻辑完全由传入的规则决定
    const lastPage = paginationConfig.getLastPage(response?.meta);
    return {
      options,
      hasMore: lastPage > page,
      additional: { page: page + 1 },
    };
  };
}

场景使用示例 #

对比原有硬编码的两个业务场景，直接传入对应配置即可，无需修改核心加载逻辑：

员工列表场景（原硬编码判断/employees路由的场景） #

// 先定义员工数据的TS类型
type EmployeeItem = {
  id: number;
  first_name: string;
  last_name: string;
};

// 直接生成对应的loadOptions
const employeeSelectLoadOptions = createPaginatedLoadOptions<EmployeeItem, { last_page: number }>({
  requestUrl: "/api/employees?page=:page&keyword=:keyword",
  fieldConfig: {
    // 传入拼接函数，替代原来的三元判断逻辑
    label: (item) => `${item.first_name} ${item.last_name}`,
    value: "id"
  },
  paginationConfig: {
    getLastPage: (meta) => meta.last_page
  }
});

普通实体列表场景（原硬编码判断取name字段的场景） #

type DepartmentItem = {
  id: number;
  name: string;
};

const departmentSelectLoadOptions = createPaginatedLoadOptions<DepartmentItem, { last_page: number }>({
  requestUrl: "/api/departments?page=:page&keyword=:keyword",
  fieldConfig: {
    // 直接指定name字段作为label即可
    label: "name",
    value: "id"
  },
  paginationConfig: {
    getLastPage: (meta) => meta.last_page
  }
});

改造收益 #

• 彻底消除和url路径强耦合的硬编码判断，所有业务规则和配置一一对应，无多余if分支
• 全链路泛型约束，写配置时TS会自动校验字段是否存在，避免运行时出现undefined的低级错误
• 核心逻辑可复用，后续新增任何分页下拉场景，只需传入对应配置即可，无需重复编写分页加载逻辑
• 完全兼容原有react-select-async-paginate的返回结构，无需修改组件侧的适配代码

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