这两天一直在写一个基于业务逻辑的表单抽象架构。听上去多么简单的一件事，不就是个表单么。然而，拥有这样想法的我果然还是太年轻。表单，可以说是web开发中最复杂的交互领域之一。单纯把表单理解为用户可以填写和提交的交互元素，那就太无知了，殊不知，一个表单除了填写和提交两个动作之外，还有一大堆可能需要的动作，例如数据验证、联动、按条件填写项、复原和暂存、创建和编辑表单公用等等。这些东西还完全没有考虑具体业务中的特殊逻辑，单纯从抽象层面去归纳而已。

而且，在现代SPA应用开发中，表单跟jquery时代也有巨大区别。SPA是数据驱动型开发模式，即界面如何展示，完全由数据（状态）驱动。这就会遇到很多问题，数据驱动的开发模式，不可避免的需要模板，模板中使用变量，并映射到实际提供的数据中。在模板中使用变量并不能方便的对应的数据层去，比如你在模板使用一个for in的循环，那么就有item和list。list好理解，但是，如果将item又传回给数据层呢？

除了数据层和模板映射的问题，表单的数据更改其实也是麻烦事。它依赖于框架内的事件系统，也就是说，现代前端框架，无一例外的要求你通过绑定数据，依靠自己内部的事件系统，当用户输入数据时，将数据的变化绑定到数据层去。这也就产生了一系列问题，几乎没有一个表单架构能够具备通用性。开发者无法在数据结构的便捷性、数据响应的便捷性、数据校验的便捷性之间得到平衡，它们一定是互斥的。我这两个星期都栽在这个问题上，无法自拔。

而且，当一些业务的特殊逻辑加入的时候，这个事情就更复杂。例如，表单中的某个（些）项目，仅在某个选项为true的时候才展示出来。这个听上去简单，但是，你要知道，当用户在true和false之前切换的时候，那些被显示/隐藏的被填写的数据要不要保留？另一个复杂的问题，就是数据源。一个下拉列表，它的选项列表可能是根据当前选中的某个项来决定，当未选中时，或重新选择时，要进行切换。这个问题听起来尚好解决，然而，当要求，其中某个选项为某值时，要求表单中其他某个项必须与它互斥……这样的特殊逻辑，不是不可能存在，我就遇到了，并且敲破了自己的脑袋。

真希望有人能够将表单这回事进行深度抽象，大老，靠你了……