099. 前端通用表格功能全部完成

学习目标

这一节把通用表格阶段收口，并展示父子表格、子表查询和关联字段配置。

学完后，你应该能理解：

• 为什么父子表是后台系统里很常见的页面形态；
• 子表为什么要依赖父表当前行；
• parentTable、parentField 这类配置解决什么问题；
• 父子表如何复用通用表格能力；
• 新增子表数据时为什么要自动带上父表关联字段；
• 通用表格完成后能覆盖哪些业务后台场景。

父子表页面

很多后台页面不是只有一张表。

例如项目管理页面里，上方是项目列表，下方可能是：

• 项目成员；
• 项目费用；
• 项目合同；
• 项目任务；
• 项目审批记录。

这些下方表格都依赖上方当前项目。

所以页面要处理一个关系：

父表当前行 -> 子表查询条件

如果选择了项目 A，子表只能显示项目 A 的成员或费用。

如果切换到项目 B，子表也要跟着刷新。

关联字段配置

画面里能看到 parentTable、parentField、parentTitle、parentType 等配置。

它们用来描述子表和父表的关系。

可以把它理解成一份声明：

• 子表属于哪张父表；
• 子表里哪个字段保存父表 ID；
• 页面上显示哪个父级标题；
• 新增子表数据时要自动填哪个关联值。

这样子表组件不需要知道“项目成员”这个业务的细节。

它只需要按照配置，从父表当前行里取值，再合并到查询或新增参数里。

子表查询

子表查询不是普通全量查询。

它至少要带上父表当前行 ID。

例如：

{
  project_id: currentProject.id
}

再叠加子表自己的筛选条件。

例如成员名称、职位、创建时间等。

最终请求参数来自两部分：

• 父表关联条件；
• 子表自己的查询表单条件。

这和前面 097、098 的查询表单能力能接起来。

新增子表数据

新增项目成员时，用户不应该手动填写项目 ID。

项目 ID 应该来自父表当前行。

这就是父子表配置的价值。

新增按钮打开表单时，通用表格可以自动把父级字段作为默认值带进去。

保存时，后端收到的数据已经带上关联关系。

对用户来说，他只是在某个项目下面添加成员。

对系统来说，它保存的是一条带有 project_id 的子表记录。

复用通用表格能力

父表和子表都可以继续复用前面做好的能力：

• 分页；
• 查询；
• 排序；
• 新建；
• 编辑；
• 删除；
• 复制；
• 行选择；
• AI 填充或 AI 新建；
• Vibe 查询。

区别只在于子表多了父级上下文。

这说明通用表格的设计方向是对的：先把基础能力模块化，再用配置组合出复杂页面。

阶段收口

到这里，前端通用表格已经覆盖了后台系统里最常见的一批场景。

它不只是一个表格组件，而是一套页面生产方式：

• 页面由配置生成；
• 表单由字段生成；
• 查询由字段类型生成；
• 父子关系由关联字段生成；
• AI 能力通过 Vibe 入口接入。

这为后面的系统演示和新业务模块打基础。