KitJs对话框组件源码解析：架构、继承与配置机制

KitJs设计理念与组件生态

Kit作为一套UI库，其设计初衷并非要求用户死记硬背Core核心或API接口，这种盲目跟风的学习方式缺乏实际意义。当前jQuery流行时大家学习jQuery，明日SeaJs兴起便去追逐SeaJs，趋势多变。因此，KitJs专门为jQuery用户提供了Suger.js语法糖，其接口完全模拟jQuery API，仅实现细节不同，便于用户直接改造Kit组件。当然，从纯技术角度深入理解技术实现远比简单拿来主义有趣。若出于KPI考核或项目奖金压力，直接复用Kit组件代码以完成任务，作者亦不介意，前提是使用者在宣传时提及KitJs即可。此外，KitJs尚处发展阶段，存在部分BUG及浏览器兼容性问题属正常现象，作者精力有限，期待更多开发者共同完善。

今日发布了KitJs的对话框组件，相关演示地址为http://xueduany.github.com/KitJs/KitJs/demo/Dialog/demo.html

KitJs目录结构与命名规范

(一)Kit目录格式

回到主题，在KitJs架构中，kit.js作为核心Core文件，包含最常用的Dom及Object继承操作。同级目录下按功能划分扩展了string.js、math.js等文件，旨在实现特定方向的功能。每个独立的js文件均包含一个Class构造器及一个全局对象实例。

以kit.js为例，其中包含$Kit类以及$Kit类的实例$kit（以$开头旨在避免与常用变量冲突）。

其他各类均以Link方式挂载在$Kit及$kit实例上，例如math.js包含$Kit.Math类及$kit.math实例，从而确保全局范围内仅污染$Kit和$kit两个对象。同时，在kit.js中定义了名为$kit.ui的命名空间，物理目录上对应同级的Widget目录，由多个首字母大写的目录组成。

widget目录下所有子目录均为KitJs的组件目录，每个独立js文件仅包含一个独立组件的Class构造器（非实例），同时兼容CommonJs的module模式（符合CommonJs Modules/1.1规范，以及AMD方式改造，具体改造方式后续详述）。

（二）Kit组件默认代码模板，注释符合jsdoc规范

以对话框组件为例，每个组件结构大致如下。

首先是jsdoc注释，@class声明该类是什么，@require xxx.js声明依赖哪些组件。

组件构造器与初始化机制

（三）构造器以及初始化方法

每个类均通过标准的function(config){}方式定义构造器。需注意，KitJs组件的构造器默认预留config参数，用于接收个性化配置。

同时在类的构造器中，存在一个静态成员defaultConfig对象，用于存放KitJs组件的默认配置。

使用KitJs组件时，首先需通过new Instance方式实例化$kit.ui.Dialog.YesOrNo，生成新的实例对象。这仅初始化了JS组件对象，尚未包含HTML，需执行init方法创建HTML并加入DOM，相当于为灵魂赋予血肉。

可能有读者疑问，为何不将init方法直接置于构造器内，而是单独分离？

原因一：在继承时需实例化父类。当子类继承父类时，会将子类的prototype对象设置为父类的new Instance新实例。若构造器内含init初始化方法，将导致父类HTML直接执行，生成垃圾代码。

原因二：考虑懒加载场景，HTML代码需在恰当时间执行，而非初始化时立即执行。

因此，使用KitJs组件的默认方式为：

实例化后，执行init方法（init方法会返回当前组件对象，含return代码7）。

上图显示，在dialog中所有API method均挂载于prototype上，通过原型扩展方式实现继承并传递给实例对象。

观察$kit.ui.Dialog.YesOrNo组件的构造器代码。

基于原型的继承实现

(四)KitJs的继承

其通过$kit.inherit方法声明与$kit.ui.Dialog对象的继承关系。此处有读者疑问，为何在构造器内继承而非直接写在外部？

原因如下：

1. KitJs是基于prototype维护继承关系的。

2. 使用KitJs组件必须实例化该组件对象，每个组件均通过new Instance方式经构造器创建。

因此，将继承关系的执行置于构造器中，这样在实例化新组件时，便会顺着当前组件构造器的继承方法，逐级继承父类成员及方法。

当子类需修改父类方法时，只需在子类的prototype中重新定义同名method即可覆盖父类继承方法。

命名上，KitJs遵循子类延续父类类名作为Namespace，一直链下去，如上图中$kit.ui.Dialog、$kit.ui.Dialog.YesOrNo。

KitJs的继承实现也很简单。

实例化一个父类对象，将父类实例所有成员copy到子类原型上，然后重置子类原型的构造器为子类构造器，再给子类构造器挂一个link指向父类。通过$kit.inherit方法，在子类$kit.ui.Dialog.YesOrNo实例化过程中，即可继承父类$kit.ui.Dialog所有子类不存在的成员，实现类似静态语言的继承。

配置参数与样式解耦策略

(五)config参数，HTML与Css的耦合拆解/换肤？

Kit组件构造器习惯传入Map类型参数，以个性化组件。在Kit组件初始化时，会自动用用户提交的config参数覆盖默认的defaultConfig后开始初始化。

对于任何组件而言，摆脱不了HTML结构的变化及Css样式的改变。

Kit将这种耦合分解在config的参数配置中。

首先使用HTML模板技术，Kit提倡使用$kit.newHTML方法直接根据HTML String生成HTML DOM插入文档流。

因此，我们抽取组件的大概HTML内容，封装成HTML String模板，存放在组件的defaultConfig中。若用户需修改HTML模板，可在初始化时使用自定义config覆盖defaultConfig内的模板字段。

在HTML模板与Css的耦合分解上，Kit采用技巧是将className用js模板方式分解开来。

通过在init方法中的$kit.tpl将config中的html以${xxx}方式对应config中的xxx做替换。

同时所有样式均在css中设置。

若有多套皮肤需切换，可在初始化时通过config指定${cls}对应的实际className，从而修改模板的className，达到换肤效果。

(六)小结

基本上，透过对$kit.ui.Dialog.YesOrNo组件的代码分析，我们对KitJs的组件实现结构有了大致了解。设计一个页面组件并不难，但设计一个能适应各种要求、在各种场合下快速变形并适应开发的组件则极具挑战。Kit通过对HTML模板及Css的拆分，配合自定义config参数与defaultConfig，以及子类通过继承获得父类属性及方法，同时根据不同业务需求重构相关代码，基本上可灵活满足各种层次、各种环境下的业务UI组件需求。

KitJs包括基本库和UI库。 基本库： 选择器功能，dom操作功能，动画功能，增强dom事件，增加hashtree数据结构，io功能，本地存储功能，多线程，range等等 还有一个模拟jquery操作格式的suger.js UI库包括了：增强的form元素，弹出层，媒体播放器，验证框架，瀑布流，联动，幻灯片，日历，上传组件，模板引擎等等