最近浏览了几种可视化搭建边界方案 组件属性 -> form schema 的方式
第一种: 手动维护 form schema , 通用输入类型直接映射输入表单组件 , 代表: 自研产品
第二种: 手动维护，但仅在 props 声明上扩展适用输入表单组件的类型，代表: 鲁班h5
第三种: 手动维护，但通过工具分析生成 form schema，其原理一般是通过文档注释对props进行表单属性标注，类型直接取props声明类型，代表: 飞猪 x-render
第四种: 组件本身就是强制协议规范的实现，代表: 百度 amis.js
第五种: 通过后台任务直接抓取npm 库上已有的组件，分析其props，并通过人工干预进行二次加工，生成form schema，代表: 云凤蝶
需要指出的是，每一类组件属性编辑表单组件，都需要指定具体类型，这是无法避免的。
其实施方案即是输入+验证输入，这里推荐json-schema的验证方式。
要求转换得到的form-schema应该符合json-schema定义，做到开箱即用，降低代码书写量。
https://github.com/kriszyp/json-schema
最近浏览了几种可视化搭建边界方案 组件属性 -> form schema 的方式
第一种: 手动维护 form schema , 通用输入类型直接映射输入表单组件 , 代表: 自研产品
第二种: 手动维护，但仅在 props 声明上扩展适用输入表单组件的类型，代表: 鲁班h5
第三种: 手动维护，但通过工具分析生成 form schema，其原理一般是通过文档注释对props进行表单属性标注，类型直接取props声明类型，代表: 飞猪 x-render
第四种: 组件本身就是强制协议规范的实现，代表: 百度 amis.js
第五种: 通过后台任务直接抓取npm 库上已有的组件，分析其props，并通过人工干预进行二次加工，生成form schema，代表: 云凤蝶
需要指出的是，每一类组件属性编辑表单组件，都需要指定具体类型，这是无法避免的。
其实施方案即是输入+验证输入，这里推荐json-schema的验证方式。
要求转换得到的form-schema应该符合json-schema定义，做到开箱即用，降低代码书写量。
https://github.com/kriszyp/json-schema