4

组织大表单应用中javascript代码的一种方法

问题,动机,目的

超过一屏,属性复杂到一定程度的录入界面/系统中,缺乏良好架构的javascript代码往往容易失控。尤其是当规模从小型表单开始逐渐变大时,javascript代码很容易演变成已DOM为核心的、缺乏结构、满是hack且难以维护的状态。

我认为良好可维护的JS代码应该具有以下的特性

  • 单个文件应该控制在一千行以内
  • 依赖管理和合并,开发应该单看一个JS文件就知道它依赖别的哪些代码,而不是在HTML中直接列举所有依赖,或者更糟,把所有超过2个页面要用的JS全写一起。
  • 良好的代码复用,清晰的模块划分
  • 改变字段的表现形式或逻辑时,不应该需要修改/考虑/知道其他字段的逻辑和展现形式。改变DOM树结构、更换表单控件等改变展现方式的需求不应当对JS产生毁灭性打击。

前三个问题基本可以归结为,超过一千行的或是需要复用的JS代码使用RequireJS / SeaJS 等方案进行分解和管理。由于这是复杂JS工程的共性,这里不多做展开讨论。本文主要关注最后一点,也就是如何解除字段逻辑和展示之间的耦合,如何解除字段和其他字段的耦合。

解耦,协议,模板化

解除耦合的做法不外乎将抽象出最小化的接口(协议)。字段可以有千奇百怪的各种逻辑,但抽象后发现其实针对单个字段来说,需要的最小接口非常小——简直太适合解耦、正交化了

  • val 方法,传值则写入,不传则读取(jQuery风格)
  • setReadonly 方法 设置只读
  • setWritable 方法 设为可写(当然设计成setReadonly(false)也不坏)
  • change 事件 值被改变时触发
  • error 事件 需要提示用户这个字段有问题时触发

订好接口以后,每个字段只需要自己都实现接口,除了每个字段自己的实现代码之外,外部一律通过接口来和字段交互。这样代码就整体可控可维护,扩展性和可读性都能令人满意。

有了这样的接口,我们的逻辑实现就可以非常语义化,比如折扣锁定为=现价/原价

good.discount.setReadonly();
var discountUpdate = function() {
    good.discount.val(good.price.val() / good.originalPrice.val());
};
good.price.addListener('change', discountUpdate); //注意:这不是DOM事件
good.originalPrice.addListener('change', discountUpdate);

这样一段代码完全不涉及dom交互,所以无论价格如何输入展示,折扣如何展示都没有问题。而实现dom交互的代码也完全不必关心这个字段的逻辑如何,只需要实现前述接口,将输入输出、只读、提示信息这些行为和DOM绑定即可。

最常用也是最多的绑定就是一个字段对应一个DOM控件,这种绑定只需要简单地将DOM事件转发成自定义事件,将读写转换成DOM控件读写即可;稍微复杂一些的交互涉及富文本编辑、日历控件等输入形式,由于我们的接口非常小,所以一般也无需太多的代码。

问题往往来源于更复杂的一些字段,他们在持久化时往往体现成JSON/XML格式字符串,或者是额外的扩展表。这些字段往往无法轻易地用一个标准DOM控件来表现,也往往是混乱的来源。

DOM操作难以维护的主要原因是插入、删除元素的同时还要维护事件,在同一个页面反复进行各种操作的时候,逻辑容易有问题,所以我的做法是

  • 事件用委托仅在初始化的时候绑在容器上一次
  • 不单独插入、删除dom元素,而是以模板和数据渲染出所有元素
  • 在内存里维护一个变量存储当前的数据,dom里面的数据并不具权威性

Templated field

  • render渲染例程:

    • 触发点:由change事件触发
    • 行为:从内存读取数据后(用模板)渲染出所有的DOM元素的HTML代码,一次性吐在容器中
  • normalize规范化例程:

    • 触发点:dom事件/val赋值 写入数据时
    • 行为:将输入数据进行规范化,然后写入内存并触发change事件

校验,提交

由于复杂表单往往涉及同样复杂的验证逻辑,建议尽可能将逻辑集中在后台CGI,JS少做逻辑(否则同时维护两套不同语言的等价的逻辑成本较大)

无论错误是从CGI拿到,还是JS自己验出来,显示错误提示都一样通过字段上的error事件来传递,校验代码负责触发事件,字段本身的实现代码监听事件来在界面上显示相应的提示。

提交数据时,只需要遍历所有字段的集合,将他们的字段名和val()结果拼装

DSL

总而言之,解决混乱代码的思路之一是将“需求/规则”和“表现/操作”分离,将前者抽象成某种形态的DSL,使之尽量贴近产品的需求,然后将后者作为这种DSL的解释器来写。代码写到像自然语言就赢了。如果做不到,不妨针对一个领域写解释器来解释为什么这些自然语言能工作。这是符合计算机科学发展大规律的,道法自然

--EOF--

原文链接 http://mcfog.github.io/2013/06/dsl-style-javascript/


mcfog
21.9k 声望966 粉丝

bWNmb2d3I2dtYWls