javascript 生命周期
概述:
“
JavaScript
控件的生命周期跟其他平台UI
的生命周期类似,但是又有自己的特点,我们只有将控件的生命周期划分清晰,所有的控件编写、mixins
的编写和plugin
的编写才能遵循控件的生命周期做统一的管理。在这里我把JS
的生命周期定义为4部分:
initializer
: 初始化,做一些不牵扯DOM操作的初始化操作createDom
: 创建 DOM,在这个过程中我们创建控件需要的DOM结构renderUI
: 生成控件的内部元素,在这里调用子控件的渲染方法,开启子控件的生命周期bindUI
: 绑定事件,可以绑定子控件事件也可以绑定内部DOM的事件synUI
: DOM结构以及子控件生成完毕后,我们在配置项中传入的值或者默认的配置项要应用到DOM上,例如 width,height,focusable之类的属性destructor
: 析构函数,移除控件,清理控件上的事件,清理子控件,清理控件自己的DOM以及控件的一些对其他控件的引用。
图 1
初始化:
控件初始化过程中做以下事情:
调用继承的父类的初始化函数,包括原型链上的父类和
mixins
处理配置项,合并默认配置项和用户传入的配置项
处理绑定到改对象的事件
初始化插件(
plugin
)
初始化完成后,是否创建DOM看具体的策略,类似于ext的实现,可以延迟创建DOM
创建DOM
创建DOM的过程如下:
调用继承的父类的创建DOM的函数,包括原型链上的父类和
mixins
创建控件的DOM
调用控件插件的创建DOM的函数
渲染子控件和内部DOM操作
执行过程如下:
调用父类的渲染函数,包括原型链上的父类和
mixins
调用插件的渲染函数
我们可以在顶级的父类来初始化子控件。好处是,子类不需要做子控件初始化的操作此时:
如果子控件还未初始化则执行初始化
继续执行子控件的创建DOM、渲染子控件、绑定事件、同步配置项函数执行
绑定事件
由于此时控件的DOM和内部的子控件已经渲染完毕,则可以在子控件或者DOM上绑定事件。绑定事件的过程:
调用父类的绑定事件方法,包括原型链上的父类和
mixins
调用插件(
plugin
)的绑定事件方式
注意:在子控件或者内部DOM上绑定事件时,使用委托,不要直接在子控件或者DOM上绑定事件,一旦子控件添加或者删除,内部DOM变化都会引起事件失效。
同步配置项
首先说明一下什么叫做同步配置项,前面我们在初始化控件时,已经对配置项做过一定的处理(至于如何处理,后面讲 JS控件属性 的时候会讲到),但是配置项并未作用到DOM上或者内部子控件上。
为什么在这时候处理同步,而不是在创建DOM和渲染子控件时,有2个原因:
在创建DOM和渲染子控件时,所有的DOM和子控件并未完整生成此时同步需要进行大量判断
我们需要把同步配置项的工作提取成方法,修改配置项时,内部DOM和子控件跟着变化。
例如:配置项里有 { width : 100 }
如果我们在渲染DOM时同步,则可能把
“width=100px;”
直接设置到DOM
上,而到我们需要修改这个width
时,我们还需要写一个函数来设置这个值。反之,我们把同步配置项集中处理,将一个个的同步配置项的过程抽取成一个个函数,那么我们初始化
width
的过程和修改width
的过程完全一样,这样概念和逻辑就统一起来。
同步配置项的过程依然如其他步骤一样:
调用父类的同步方法,包括原型链上的父类和
mixins
调用插件(
plugin
)的同步方法
注意:我们应该可以配置一个配置项是否在此时同步,原因有很多,比如多个配置项会产生同一操作,如果多个配置项同时同步,那么一个过程会反复执行多次。
移除控件
任何对象都有构造函数,必定也有析构函数,但是这个函数往往是大家最容易忽视的地方,但是也是非常重要的地方,暂且不说内存泄露之类的问题,就是如果一个控件的移除工作做得不够好,会对正常的使用带来很大的麻烦。
这个函数又是最不好写的一个函数,因为它需要处理以下工作:
清理使用的其他控件,是否也移除看具体情形。区分 关联和聚合
清理子控件
清理绑定到控件和DOM上的事件
移除DOM
清理变量的引用,这个比较麻烦和繁琐,所以我们需要对控件的引用做统一的管理
同样此函数也要执行:
调用父类的析构函数,包括原型链上的父类和
mixins
调用插件的析构函数
问题
上面讲的全部是具体的步骤,但是在实现的时候遇到了一系列的问题:
调用父类的方法存在问题
调用原型链上的父类方法,只能使用
className.superclass.method.call(this)
这类的方法,this.constructor.superclass.method.call(this)
不能使用,原因在js
控件继承 的extend
一章中有讲到,这种调用方式繁琐而且维护不方便。调用
mixins
上的方法,在JS
继承mixins
一章中我讲到过mixins
的实现原理,覆盖同名方法,mixins
的方法其实已经作为控件的prototype上的方法,所以最好不要使用同名方法,如果多个mixins都是用renderUI
,synUI
之类的方法,而继承这些mixins
的控件没有实现renderUI
这类方法,那么就会被覆盖。调用插件的方法也存在问题
我们需要获得当前控件的引用
解决方式:
针对调用父类的方法我们可以在控件渲染时,按照原型链的顺序,先调用父类的方法再调用子类的方法直到当前控件:
如上面的继承关系,我们执行C.renderUI()
时,按照继承原型链的顶层向下执行。
执行
minxins
的方法,我们执行renderUI
时,去依次执行mixin
的__renderUI
方法。执行父类的
renderUI
时,如果也存在mixins
那么执行mixin
的__renderUI
方法。
图3
如上图所示:inherits
表示原型链继承,extends表示 mixin
扩展
那么c.renderUI
的执行过程如下:
A.renderUI
->D.renderUI
->B.renderUI
->E.renderUI
->C.renderUI
调用插件方法时需要传递控件本身的引用即可,如:
plugin1.render(this)
析构函数
destructor
比较特使,执行的顺序跟上面2中讲的顺序有所不同:
子类 destructor
-> 子类扩展 destructor
-> 父类 destructor
-> 父类扩展 destructor
按照图3的继承结构其析构函数执行的顺序是:
C. destructor
->E.destructor
->B.destructor
->E.destructor
->a.destructor
原因是,子类的一些引用依赖于父类或者扩展类,如果父类和扩展类先执行析构函数,那么子类在使用某些变量/属性时会报错。