主要效果图

效果1 效果2

实现有和不同之处

前置

本质的一个问题就是关于父子、插槽传递属性时,父公共属性与子差异化属性的区分集合导致属性 传统的封装为了保证结构化配置、常常弱化标签化操作、保证配置优享的同时、基本放弃或者弱化标签配置 1.支持结构化配置、但对标签化支持较小或不支持、封装性体量太大，或者结构为跨级别属性定义，个性化的属性和公共属性跨级传输,再有就是组件共存性基本没有考虑【比如当前封装配置组件不满足要求时，要自定义花销太大】

解决了个性化组件跨级传输、轻度封装

公共属性和个性化属性在同一个层级,父组件接受标准参数，个性化传输维持原态传输

就地取材

一套UI框架本身就具备很多的基础组件、日常的开发基本能够满足,表单工厂的目的在于对布局、样式、一致性调用、结构化调用提供便利、但看过Vue相关的封装，理解不了为什么会带有按钮配置这项操作，而且封装的复杂性和消耗、有点儿得不偿失的感觉 公共控制、个性化组件调用时控制,无需根据文档再重新熟悉属性配置、最主要的是，组件体量和复杂性最小化 将Form,Description，基础组件组合达成目标

放弃臃肿不合理部分

• 如Form的非空等验证，可以有简化写法,自动绑定，值获取排空，表单值[]、结构化数据的一致性转换等，
• 如Description 如有些内容不需要描述时，相应的处理，另外常规的表单+Form实现方式太臃肿
• 如基础组件的值绑定常常需要初始化转换以及获取后转换如多选的[]->"",再比如[{value:'',lable:''}]都需要存储的情况

一致性

很多封装要么过度，要么牺牲了原本的组件差异化传递,基础组件某些功能得不到有效的调整 下图的封装不是一个良好示范。。

结构化配置及后续

• 结构化配置相对较为简单，随后会继续完善
• 后续会继续完善request相关，内容赋值，值一致性转换 数据加载等处理
• 完善好表单后，会基础针对查询、页面、内容编辑控制、打开方式等进行处理