在部分业务场景中，构建业务流程需经历立项、开发、验收等环节，即便简单场景也耗时耗力，且部分场景缺乏统一管理归档方式。

因此，基于开源项目 VueFormMaking(https://github.com/GavinZhuLei/vue-form-making) 我们开发了低代码表单生成平台，实现表单模板化与可配置化，提高业务效率，便于管理与追溯。而平台核心在于通过拖拽及简单配置生成表单模板并一键复用。

以下是其核心表单模版页面：

一个低代码表单生成工具至少包含表单项组件开发、表单模版配置页面、表单模版渲染页面三个部分。以 VueFormMaking 代码结构为例进行阐述。

element-ui 中 input 组件支持的 props API 如下：

基于以上推理，我们可以完善 栅格组件 的数据结构：

分别对应下方的红蓝绿三部分：

其实现的核心部分，在于其 Col 对应的组件内增加 Vue.Draggable 支持并统一 group 的 props 值，实现布局组件内基础组件的拖拽。其他类似的组件也是需要在其子组件对应的容器配置 Vue.Draggable 为统一 group 即可。

单独看蓝色与绿色的组成部分，其一个简化的模型如下：

这一部分在代码实现上与步骤2的蓝色部分的差异不大，其本质就是将组件options的配置项通过v-bind的方式绑定到组件对应的props上，并且给每个表单项赋值，通过v-model绑定这个值实现数据的双向绑定修改。

并且在最后提交表单的时候，遍历所有的表单项，取其对应的双向绑定的数据即可。

在这一步还需要考虑的其他重要功能：

在功能的迭代过程中，必定会出现修改旧组件模版的数据结构（新增、修改字段）的情况。

假如，我们需要给 input 添加一个 prefix 配置项，用于配置组件的前缀图标。那么其迭代的过程如下：

  2. 将新的属性赋值给已有的组件实例

那么在此过程中，只要通过 Object.assign 重新赋值即可，原因在于这里的 options 里面的属性都是扁平化的一层。

但是假如有个属性是嵌套的：

例如，现在需要新增一个属性 keyInsideNew 到 keyToModify 中，其新增后的结构如下。

在这个时候，如果使用 Object.assign 处理旧实例的话，keyToModify.keyInside 已经修改过的值就会被进行覆盖式的更新。那么之前的所有模版都需要重新进行配置了。

而如果不用 Object.assign ，要一个个对新的字段单独处理的话，也会另外造成代码臃肿的问题。因此，我们需要尽量避免出现多层次的配置的出现，尽量使用扁平化的配置字段。

      注：这里仅描述了新增字段的情况，实际上可能会有修改字段名、删除字段的情况，但是这样的需求应该是需要避免的，会导致系统整体的杂糅与代码结构的混乱。

过去在开发后台的时候，我们可能会更多的注意功能上的实现，而忽略了一些基本的样式问题。特别是配置表单的时候，有些表单项可能不需要标签，而有的需要，这样会使得整体的对齐变得奇奇怪怪的。

我们可以从以下几个方面去进行优化：

在开发新组件与新功能时，务必精准界定并最大程度缩减当次改动的范畴。

具体而言，每次改动应严格限定于表单项组件开发的迭代更新、表单模版配置页面渲染的迭代优化或者表单信息填写页面渲染的迭代改进这三者中的某一项。

如此一来，便能有效规避因改动范围过度宽泛，致使难以预估是否会对原有模版及页面产生不良影响，进而保障平台或服务的稳定可靠运行。

在代码侧，我们也需要注意一些与组件相关的坑点，它们可能是使用的仓库或者组件本身带来的副作用，我们需要通过自己的代码实现来修复这些问题。

比如，在用的的 Vue.Draggable 组件中，他支持的 dragEnd 等事件内对应的数据都是浅拷贝的数据，这意味着只复制对象的最外层结构。如果对象内部包含引用类型（如数组、对象），那么浅拷贝后的对象和原对象会共享这些内部引用类型的值。这可能会导致意想不到的问题，比如在数据更新过程中，原数据和拷贝后的数据相互影响。

当我们拖动组件商店的组件模版进行编辑后，我们再使用相同的一个组件，修改其中一个组件的options，另一个对应的组件的options也会同步发生更改（浅拷贝的副作用），这就导致了表单模版编辑过程中容易出现巨大的影响。而修复的逻辑比较简单，通过 loadash 的 cloneDeep 函数进行深拷贝后再赋值即可避免类似问题的发生，但是同时也需要留意 布局组件嵌套独立组件 的问题，需要进行递归的深度遍历与拷贝。

总的来说，要完成一个低代码的平台的开发，我们必须做好以下工作：