持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第8天，点击查看活动详情
一、场景介绍
1. 业务场景
如何定义「巨型」表单，这个因人而异。但如果只是一些：收货人信息、登陆、注册的这种比较简单的表单，那肯定算不上巨型，直接常规开发写模版就好了，没有必要为了配置化而配置化～
从笔者的理解出发，表单项非常多，比如笔者曾经负责的「投放系统」，随随便便提交时都会涉及几十甚至上百个字段，这样整个表单会有几十、上百个表单项组成，这就算得上是巨型表单了。
先给大家看看成品的其中的一小块截图～
别看到截图好像表单项也就那样，根据右栏数起来共40+个，但是这个只是初期版的，还有很多字段是没接进来的；而且很多表单项之间有联动、可增删，还有很多表单项是隐藏的
相信你很难想象，其实你只要进行简单的配置，就能实现上图的界面。比如下图的 js对象 就是上图的其中几个表单项的配置：
大家已经不难看出，配置化思路其实就是对表单项进行了抽象，制定了一份协议去描述每个表单项。具体对象中的每个属性有什么用，这个笔者稍后讲自己的设计思路时再详细介绍～
这时候你一定会有疑问，为什么要抽象、为什么配置化的方案更好，我们接着往下看～
2. 配置化想法萌生
高复用、好维护。是的，笔者用配置化方式开发表单，完完全全就是为了高复用、可维护性，然后提升开发效率，解放生产力。
- 高复用：相似的业务逻辑进行统一处理，复用在相似领域的业务场景。如果说投放系统只需要接入一个渠道，那真的写
template一把梭就完了。但事实上却不是这样的，当你接入了第一个facebook，你发现后面还有tiktok、巨量引擎、广点通等各种媒体渠道... - 可维护：实现配置代替开发。即使把配置抽离，交到非技术人员处，其根据协议一样能实现表单项的增删，完成业务。并不是把东西做出来就完事了。首先，渠道方会有新配置功能推出，这个是不可控的。其次，系统开发时并不是全字段接入，而是先接入业务方所需要的核心配置，所以后期会有很多接入新的字段需求。
