关于使用 Schema 进行表单/Table 封装的思考

1. 为什么谈到 Schema 封装

在中后台开发中，表单和表格（CRUD）是非常常见的场景。许多团队会做“Schema 化”的封装：

• 通过一份 JSON（或类似数据结构）描述页面上的字段、交互逻辑、校验规则等
• 让组件（或框架）根据 Schema 自动生成对应的 UI 和业务逻辑，从而避免重复编写相似的增删改查代码

常见的示例包括：表单的动态渲染、表格的列配置、搜索条件等。

2. ProComponents 的优势

ProComponents （主要指 ProTable、ProForm、ProLayout 等）是由 Ant Design 官方团队基于 antd 生态做的二次封装，目标是为中后台“做最常见的场景优化”，让开发者能快速完成以下工作：

1. 高效增删改查：封装了大量后台管理系统场景的通用能力，如分页、搜索、排序、批量操作等。
2. 内置最佳实践：基于 antd 的组件体系和设计规范，拥有完善的交互、样式和国际化支持。
3. 配置化开发：使用 columns、search、request 等配置，就能快速渲染出可用的表格或表单，大幅减少样板代码。

这些特性让 ProComponents 成为非常好用的“Schema 化中后台开发”方案。 如果你希望在项目中尽量少造轮子，且对其默认样式风格不排斥，那么 ProComponents 通常能满足绝大多数 CRUD 场景。

3. 为什么并不总是使用它

尽管 ProComponents 在一定范围内优点突出，但也有以下可能的“局限”：

1. 封装较重，灵活性有限
   • 组件本身约定了特定的交互和 DOM 结构，若需要高度定制化的交互或 UI 风格，可能会不够灵活，改造成本较高。
2. 包体积较大
   • 和直接用 antd 相比，ProComponents 引入的代码与功能更多。如果是小型项目或仅需要非常轻量的功能，可能有些“杀鸡用牛刀”。
3. 学习成本
   • ProComponents 在配置和使用上有一套自己的思路，第一次接触时需要花时间熟悉它的“约定大于配置”体系。
4. 对样式/细节的强制或限制
   • 基于 antd 的设计体系，若 UI 设计要求非常个性化，则需要做额外的封装或 Hack。

综上，这种配置化封装更适合：对样式和布局要求不高的“B 端场景”“大量重复 CRUD”或者“希望快速交付的中后台项目”。

4. 我个人的选择

「只有大量的不在意样式的重复性 CRUD 场景时，才会使用这种封装。否则，我更偏向自己直接基于 antd/React 做轻量化封装。」

• 不在意样式：指的不是没有设计，而是说项目整体风格统一、对视觉和交互的自定义需求不多，这时候引入 ProComponents 可以极大提高效率。
• 灵活度需求较低：如果对页面结构、交互流程有较多创意或非标准用法，则内置的配置化未必能覆盖，甚至还要“反向定制”，可能得不偿失。

正因如此，对于我所在的公司项目，在 UI 样式完全确定后，我会做一些符合本项目需求的二次封装。但这个封装通常是内部项目使用，对外开源时不会直接暴露；因为每个公司的业务和 UI 要求往往差异巨大，这种二次封装在他人项目中并不一定具备通用性。

因此，如果你：

• 项目需求简单、风格跟 antd 差异不大
• 希望快速上手，缩短开发周期
• 没时间/没必要自己重新封装

那么 ProComponents 会是不错的选择。“轮子”已经造好，开箱就能用。

如果你倾向于自行封装

• 你可以根据团队需求或项目特性来写一套更轻量的 Schema 配置；只保留自己最常用或最关心的字段和交互，避免无用功能带来的冗余。
• 这样既能保证项目内部风格统一，又能在关键节点灵活扩展，不被第三方库的抽象层“束缚”。

5. 总结

1. ProComponents 提供了强大的“Schema 化”表单 / 表格封装，如果你的 B 端场景注重快速开发、统一风格，这是一个非常成熟的解决方案。
2. 但若需求场景相对灵活，对前端交互或样式有较高要求，或项目体量较小、对包大小很敏感，则可以考虑：自己基于 antd 封装更轻量、更灵活的方案。
3. 对于开源项目而言，由于 UI、交互需求差异性很大，诸如 ProComponents 这类“重量级封装”并非在所有业务中都适用。每个团队都可根据自己的需求评估是否要二次封装，或干脆直接使用官方轮子。

本着“少造轮子、适用就好”的原则，灵活选择才是最适宜的做法。希望这些思考能给你在项目技术栈和组件封装上带来帮助。