用 Schema 配置后台页面的一些思考

发表于 | 分类于
记录后台表单、表格和搜索条件的配置化思路

最近整理项目的时候，又想起之前做后台页面的一些事。列表、搜索、新增、编辑，这几块经常一起出现。同一个字段，有时候表格里要展示，搜索里要筛选，表单里还要填写。页面多了之后，类似的代码就会写很多遍。

为什么会想到用 Schema

比如商品管理里的「商品名称」，可能有这些需求：

  • 表格里显示名称
  • 搜索区可以按名称查询
  • 新增、编辑表单里可以输入名称，而且必填

如果这几个地方分开写，后面改字段名或者标题时，就得分别找到对应位置。Schema 的思路就是先把字段信息放在配置里，表格、搜索和表单再根据各自需要读取。

下面是一个方便理解的简化例子，不是项目里的实际配置：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
const fields = {
  name: {
    title: '商品名称',
    type: 'string',
    required: true,
    table: true,
    form: true,
    search: true,
  },
  status: {
    title: '状态',
    type: 'string',
    options: ['上架', '下架'],
    table: true,
    form: true,
    search: true,
  },
}

这样表格组件可以根据 table 决定显示哪些列，表单和搜索也各自读取对应的配置。公共页面不用每次都从零开始写，调整字段时也更容易找到配置在哪里。

不过上面例子里的 table、form、search 都是自己约定的配置项，不是 JSON Schema 标准字段。JSON Schema 本身主要用来描述和校验数据结构，页面怎么渲染还得看项目自己的实现。

什么都配进去也不一定好

刚开始做配置化时，很容易想把所有场景都塞进去。但实际业务总有一些特别的地方：字段之间要联动，某个按钮要打开复杂弹窗，或者表格里某一列要自己写展示方式。

这些逻辑如果全写进一个大配置对象，时间一长，读起来可能比普通组件还费劲。常见输入框、选择器、表格列和基础校验可以交给通用组件；业务特别复杂的部分，还是要留自定义组件或者其他扩展方式。

Elpis 里的 Schema 页面就有表格、搜索、表单和详情等配置；服务端的请求参数则使用 JSON Schema 和 Ajv 校验。两边虽然都叫 Schema，但不是说它们自动共用同一份配置，具体还要看项目怎么实现。

我现在的理解是，配置化比较适合结构相似的页面。如果一个页面本身就很特殊，直接写组件也没什么问题。先找到真正重复的部分，再慢慢抽出来，用起来会舒服一些。