前言
表单功能一直是前端项目中比不可少的一块功能，如果有个项目需要在两个月内开发200个左右表单，那我们应该怎么办？加班加点也是能搞出来的，那质量有保证么，这是我们就需要开发一个可以通过可视化交互设计表单的功能。下面和大家分享下我在开发这款表单设计器时使用的技术能力以及整个的设计思路。
技术能力分析
- 前端能力：基础框架搭建 组件拖拽能力
- 后台能力：基础接口服务 数据库设计
基础设计
交互设计
在交互设计上参考FormMaking，有兴趣的同学可以点进去看看，左侧区域是控件，中间是拖拽区域，右侧是属性设置区域。
控件区域
- 基础控件：表单中常用一些控件如：输入框 下拉框 开关 时间选择器 ...
- 高级控件：封装些常用的组合控件
- 布局控件：栅格布局可分多行的
拖拽区域
- 基础控件顺序调整
- 字表单内部组件顺序调整
属性区域
控件属性
- 基础属性配置：标题 初期值 字段值 placeholder等一些控件的通用属性
- 数据属性配置：数据的来源配置，静态的/动态的 静态的手动输入数据的来源值（下拉表里的值） 动态的填入请求的url请求的方法请求的参数，请求header
- 校验属性配置：表单项的正则校验和一些非法字符的限制
- 其他属性配置：一些显示的处理 提交的处理等等
表单属性
- 基础属性配置：整个表单的名称 表单的校验地址
- 其他属性配置：
数据处理设计
通用规则设计
- 接口个交互规则
# GET接口 /api/v1/test # 请求参数 params{param1:"",param2:""} # 请求头部 headers:[{key:"",value:""}] # 返回值 { code:200, data:{} || [] }
# PUT接口 /api/v1/test # 请求参数 params:[{filed:"",value:""}] # 请求头部 headers:[{key:"",value:""}] # 返回值 { code:200, data:{} || [] }
- 数据请求规则1（ur参数多个条件）：？多个以&符号分隔
/path/test?key=_field1&key2=_field2
- 数据请求规则2（url参数获取）：key=self（self表示当前表单项的值）key=_fieldname（_fieldname表示其他表单项或者user对象里的值）key=external_888(external_value表示取静态值value)
/path/test?search=self&status=_field2&name=external_test
注：将这块的规则处理封装成个公共方法处理请求url可以命名为parseRequestParams
输入：/path/test?search=self&status=_field2&name=external_test 输出：/path/test?search=自己的值&status=表单中status的值&name=test
- 数据请求规则3（body参数）：field表示表单的field value表示值（如果没有定义则取表单定义的值，如果定义了则不用取）
[ { field:"", value:"" }]
注：将这块的规则处理封装成个公共方法处理body可以命名为parseRequestBodyData
输入：[ { field:"id", value:"001" }, { field:"demo", value:"" }, ] 输出：[ { field:"id", value:"001"(设置则取默认值) }, { field:"demo", value:"从表单中取demo值" }, ]
- 自动填充规则1：填充多个以||分隔
fieldname1||fieldname2
注：将这块的填充规则的处理封装成个公共方法
- 条件判断规则1:判断符，==表示等于 !=表示不等于
key==value key!=value
- 条件判断规则2:多个条件时，||符号表示或者 &&表示并且
key1==2&&key2==3||key3!=4
注：将这块的规则处理封装成个公共方法
- 文本显示规则1: item.key表达式来自定义显示条件（为了解决复杂的显示逻辑）
item.lable+'-'+item.value+'/n'
数据获取设计
/demo/list?id=self&name=_name&_external
- 下拉列表数据（静态）：可以配置静态数据
- 下拉列表数据（动态）：可配置接口地址 参数字段
- 动态查询数据（内部）：可配置接口地址 参数字段
- 动态查询数据（第三方）：可配置接口地址 参数字段
是否显示/只读/必须规则处理
- 规则1（多个条件）：||符号表示或者 &&表示并且
- 规则2（判断符）：==表示等于 !=表示不等于
校验规则处理
- 正则校验
- 非法字符
- 错误描述
自动填充规则
key1||key2||key3
- 查询自动填充:通过输入的值查询后填充（onblur事件处理）
- 下拉选择后自动填充：通过选择后的值填充（onblur后查询onselect后填入）
- 静态下拉列表下拉选择后通过选择地值查询后自动填充（onselect后查询）
架构设计
前端组件设计
前端组件分为以下三个模块，表单设计模块（设计表单），表单展示模块（提交表单），表单详情模块（查看提交后的表单）
表单设计模块
- 控件展示组件
- 拖拽编排组件
- 属性编辑组件
表单展示模块
- 表单整体渲染组件
- 单个表单项渲染组件（最为复杂的部分）
- 规则解析方法封装
- 动态数据获取封装
- 数据获取后统一处理封装
表单详情模块
- 表单头部信息组件
- 基础信息组件
- 其他信息组件：
后台schema设计
表单schema
表单的schema设计必须考虑到表单的通用性，根据一个正常的表单需求我们可以把表单划分为两部分：
- 表单的整体属性：表单名 表单提交（地址/header） 表单的附带属性（自定义的）
- 单个表单项的属性：控件类型（输入框/下拉框...），控件数据来源，控件label，控件字段key,其他属性（预留）
- 多个表单项的属性：单个表单项的组合
{ field_name:"", label:"", type:"", property:{}
总结
一个前端团队随着逐渐的发展一些提高工作效率的能力必须慢慢的具备，可视化搭建就是这些能力之一。 没有接触这块时你也许会觉得很复杂，当你了解部分时你又会觉得不过如此，但是你真正在实际项目中深入的去使用你就会发现他的复杂之处。可视化搭建中的技术能力，我个人认为是没有难点，无论前端的拖拽，还是nodejs的数据存储，这些都不会成为我们难点。真正难的是结合我们自身的页面去设计我们搭建的交互以及存储的数据结构。所以说如果你是一个前端要想做好这块那么你必须要深入了解你们应用的领域，也就是你们项目的业务需求。
