这是一个创建于 1630 天前的主题，其中的信息可能已经有所发展或是发生改变。
看到一个老哥吐槽 [vue-form-builder]( https://github.com/openfext/vue-form-builder) 是在 UI 组件库之上做了一层 JSON 循环的封装。
这里想说的是本身的实现方式确实不复杂，适配器只是为了解决简单字段的配置，绝大部分情况下字段对应的组件都需要自己进行封装。它的目标也不是为了不写代码而采用 JSON 配置的。反而，由于能够被配置的组件更加需要高度的抽象和设计，可能还会增加额外的开发成本。那为什么还需要配置呢？
我觉得配置的本质是用来解决一类问题的差异性的。
相似的 50 个复杂表单，每个表单 80% 的字段都一样但是校验规则、可选项、提示语等都有可能不一样。写成 50 个个性化的 template 肯定也是可以达成目标的。但是如果采用 JSON 配置的方式，可以把每个字段大家相同的地方都写成组件的默认值，只有不一样的地方才需要在 JSON 配置中体现，很多情况下一个字段可能只需要配置一个组件名即可。这样即便是 50 个 JSON 配置，复杂度也相对可控。
根据 JSON 生成 template 也是一种思路。但是 如果生成的 template 无法手动修改，每次都需要改 JSON 然后重新生成，那我觉得跟其他方式差不多。如果生成的 template 如果可以手动修改，但是改过之后就无法反向同步到 JSON 配置上，那其实就是一个一次性的模板生成器，不具备持续维护性。如果生成的 template 可以手动修改还能反向同步到 JSON 配置上（复杂度较高，也需要很多约束），那我觉得统一维护 JSON 配置反而更加直观一些。
另外生产环境中，配套的可视化表单配置、发布流程、版本管理等功能确实也是不可或缺的。
这里想说的是本身的实现方式确实不复杂，适配器只是为了解决简单字段的配置，绝大部分情况下字段对应的组件都需要自己进行封装。它的目标也不是为了不写代码而采用 JSON 配置的。反而，由于能够被配置的组件更加需要高度的抽象和设计，可能还会增加额外的开发成本。那为什么还需要配置呢？
我觉得配置的本质是用来解决一类问题的差异性的。
相似的 50 个复杂表单，每个表单 80% 的字段都一样但是校验规则、可选项、提示语等都有可能不一样。写成 50 个个性化的 template 肯定也是可以达成目标的。但是如果采用 JSON 配置的方式，可以把每个字段大家相同的地方都写成组件的默认值，只有不一样的地方才需要在 JSON 配置中体现，很多情况下一个字段可能只需要配置一个组件名即可。这样即便是 50 个 JSON 配置，复杂度也相对可控。
根据 JSON 生成 template 也是一种思路。但是 如果生成的 template 无法手动修改，每次都需要改 JSON 然后重新生成，那我觉得跟其他方式差不多。如果生成的 template 如果可以手动修改，但是改过之后就无法反向同步到 JSON 配置上，那其实就是一个一次性的模板生成器，不具备持续维护性。如果生成的 template 可以手动修改还能反向同步到 JSON 配置上（复杂度较高，也需要很多约束），那我觉得统一维护 JSON 配置反而更加直观一些。
另外生产环境中，配套的可视化表单配置、发布流程、版本管理等功能确实也是不可或缺的。
 |
1
wly19960911 2020-06-09 09:33:01 +08:00
"应对复杂的场景，你必须用 hack 的方式设立并传个 slot 进去这个组件把损失掉的 template 拓展性给补回来。然后你这种 hack 又要加字段说明。像这样，每个人往上面补一刀，之后这个模块基本上就废了"
可能那个楼主不太懂什么是业务特化的组件吧，开发通用组件肯定需要，问题通用组件解决不了一切啊，只能根据业务来做相应功能的东西。而且我怀疑他没有维护过几十个复杂表单，那种 template 不是给人看的，没有任何维护性可言。 |
 |
2
wenerme 2020-06-09 11:59:03 +08:00
打个广告，基于 rjsf 做的 antd 的表单生成器 https://github.com/wenerme/apis/tree/master/packages/rjsf-antd-theme
|
Select Language