摘要

此次主要接受借用（elment-ui、其他的UI组件思路相同）UI框架下的Form及Descriptions组件,保留结合各自原本的特性,提取属性进行组合封装,最小化封装成本的同时,转化为最大的使用便捷性。

传统表单问题

1. 表单的应用类型,过滤条件、弹窗、抽屉式的、预览、编辑、步进器（分组式）等应用形式。 以上是ProComponents antd封装的增强型表单组件,因为最先用应用antd系列还能追溯到antd,v2版本。在此之前ProComponents先后经历了noform、nopage、noList等独立项目,相信关注react系列的老哥应该有了解,总体来说表单其实是实现前端功能的一个基础,可以其很简单,但具体到实现的时候又很麻烦,不知道是开源UI的通病还是什么原因（Form）的封装在使用上一直都存在诟病,最先保证的是UI风格和验证的一致性。
2. 对于一个项目来说,通常是2栏平铺,3,4栏布局出现的情况下通常会结合Layout/Gird 布局器来组合使用,如果再加上枚举等处理，一个传统表单的写法和嵌套被无线扩大,这本身也是bootsrap的一项应用诟病（传统的布局通过增加页面元素进行嵌套解决）
3. 封装之后基础组件的特性被隐藏,结构变为新提取组件的特性,常常在扩展新增,标准重定。组件的灵活性和便捷性的平衡一直是个人封装的一个很难兼容的点。 a. 自己封装的目的很明确就是便捷易用及方便修改,满足扩展。 b. 企业级封装更强调的是低耦合、易读的结构、协作的便捷性，以提供(基座)能力为主。 总结起来，易用性的封装本来就是留给项目组的。
4. 针对日期、下拉框、tree等的选择处理，只能保存时手动处理，没法遵循相关约定,特别是select的数字值和字符串值的问题，一直会造成困扰。

开发过程

formcreate的应用困扰

最先以formcreate组件为例子,比较典型的重结构轻标签封装（当然,该组件主打的通用，无可厚非）

满足了我的易用及横栏调整诉求,但对自定义及扩展属性等应用，在应用一段时间后,对可编辑、不可编辑及纯文字兼容等问题不够友好，总结来讲重结构轻标签的封装形式有点儿不合时宜。 如以下问题及分组（带有表单子标题）

封装尝试

随后我尝试自己去封装，发现有点儿吃力不讨好,保准及全盘的考虑完整性不提,单单是一个稳定性问题都很难在短时间内去验证,（通常组件封装和项目进度并行）,于是我换了种思路，我想要的是Frm 和Descriptions组件的特性集合,且这两个组件其实层级结构是类似的,于是关键点在于解决form 的type属性处理及布局的结合 以下为效果： 调用示例：

封装代码

Descriptions及form属性的合并,注意此处处理了表单验证为空时如果不设置验证rule,会提示英文的问题 Descriptions 因为是表格结构,所以会有row这类组件的处理，并会更改其渲染子组件为指定的组件 FormItem组件作为Descriptions 对应的 DescriptionItem合并属性 FormField 组件用以抽提公共的组件类型，便于使用，同时将扩展类型抽离到此处,统一处理返回的结果处理，同时，采用jsx这种渲染的目的是完整的保留原本的select、input等组件的调用属性,使用时不会因为封装不完整导致组件特性无法使用。

扩展

因为篇幅问题,完整的代码无法贴出,当前提供的是封装思路,后续的ProTable,ProQuery,ProDrawer等简易化页面也基本是基于此扩展，该组件经过两轮项目的验证基本能够满足复杂的扩展及应用场景,当前关于预览模式及编辑模式的区分等扩展需求也能轻松搞定， 最为重要的是布局LayOut的设置灵活性能够得到保障，如果涉及到自定义组件或者其他引用组件，可以同FormItem这种方式去扩展。 如果非要找一个参照反倒是手机端UIVant的封装相对友好一些，可以变相作为封装的参考

总结

之前虽然也写过，整过很多尝试,但感觉不同前端框架的特点不同，从应用性上来说，不能说同一种的封装结构就适应于其他的，抛砖引玉来一波,更多的是做个引导。

本文正在参加「金石计划 . 瓜分6万现金大奖」