筛选器问题：如何将ID转换为可读名称？

问题背景 #

我正在构建多资源（客户、用户、合同等）的列表概览页，已实现搜索、排序、分页功能，但筛选环节遇到以下问题：

• 筛选表单放在侧边栏，仅在打开侧边栏时才通过react-query+axios拉取选项数据（比如用户页的角色、组织选项，是带id和name/label的对象数组），避免无筛选操作时的无效请求
• 提交筛选后，概览页的filters状态存储的是纯ID值（示例如下），现在需要在概览页展示活跃筛选的可读名称，但直接遍历filters只能显示ID

{
   status: 'active',
   organisation: 'Y6XS28Qj4SjPrZJ5w',
   role: 'cybNVunkMrCyzg1ig'
}

同时需要满足：

1. 筛选条件可通过URL共享，打开页面时可能已有活跃筛选参数
2. 不同页面的筛选器数量、类型不同，需动态匹配ID与可读名称
3. 部分筛选器并非ID类型（比如status直接是可读值）

可行解决方案 #

方案1：利用react-query缓存，按需拉取转换 #

依托react-query的缓存能力，不用提前拉取选项，仅在需要转换ID时触发请求，同时复用缓存：

• 给每个筛选选项的API请求设置固定缓存键（比如['organisation-options']、['role-options']）
• 在概览页封装一个通用的getFilterLabel函数，逻辑如下：
  • 先检查react-query缓存中是否存在对应选项数据
  • 有缓存则直接根据ID匹配name/label返回
  • 无缓存则调用fetchQuery触发请求，请求期间显示加载态（比如加载中...或原ID）
• 针对URL传参场景：页面加载时解析URL中的筛选参数，对每个ID类型的筛选项调用getFilterLabel，自动触发缓存请求并补全可读名称

方案2：提交筛选时同时存储ID与名称 #

修改侧边栏表单的提交逻辑，在传递ID的同时，把对应的可读名称也存入filters：

• 提交时拿到选中的完整选项对象（比如{ id: 'Y6XS28Qj4SjPrZJ5w', name: 'XX科技' }），将filters结构调整为包含值和标签的格式：

{
  status: { value: 'active', label: '活跃' },
  organisation: { value: 'Y6XS28Qj4SjPrZJ5w', label: 'XX科技' },
  role: { value: 'cybNVunkMrCyzg1ig', label: '系统管理员' }
}

• 概览页展示时直接取label字段，请求列表数据时用value字段作为参数
• URL共享处理：把value（ID）存入URL参数，页面加载时根据参数拉取对应选项，补全label后再更新filters状态

方案3：构建筛选元数据配置，统一动态处理 #

为不同页面的筛选器定义统一的元数据配置，明确每个筛选器的类型、选项来源、标签字段等：

• 示例用户页的筛选配置：

const userFilterConfig = [
  {
    key: 'status',
    type: 'static',
    options: [{ value: 'active', label: '活跃' }, { value: 'inactive', label: '已停用' }]
  },
  {
    key: 'organisation',
    type: 'api',
    queryKey: ['organisation-options'],
    fetchFn: () => axios.get('/api/organisations').then(res => res.data),
    labelField: 'name'
  },
  {
    key: 'role',
    type: 'api',
    queryKey: ['role-options'],
    fetchFn: () => axios.get('/api/roles').then(res => res.data),
    labelField: 'label'
  }
]

• 概览页根据当前页面的配置动态处理：
  • static类型：直接匹配value获取label
  • api类型：通过react-query的useQuery根据queryKey获取缓存数据，无缓存则触发请求，匹配ID拿到标签
• 该方案适配多页面的筛选器差异，统一处理URL传参场景，扩展性和维护性更强

方案对比 #

• 方案1：轻量化改动，无需修改现有filters结构，适合不想大幅调整代码的场景
• 方案2：逻辑直观，展示时无需额外请求，但需要调整filters结构，URL传参时需额外拉取补全标签
• 方案3：扩展性最强，适配多页面场景，代码复用率高，适合长期维护需求

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