看到一个老哥吐槽 [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 配置反而更加直观一些。
另外生产环境中,配套的可视化表单配置、发布流程、版本管理等功能确实也是不可或缺的。