链接:twitter flight
关键字: 基于事件交互;轻量级的组件;
flight特点:
component基于dom:组件绑定到dom上
事件驱动:组件依赖event通信
分离关注点原则(体现在组件无引用、组件间完全解耦 ,和 AOP的应用)
介于单页面型应用和开放型应用之间的框架,核心是事件驱动、基于dom的组件,强调组件之间相对独立松散的架构,但对组件的定义又十分严格,具有一定的侵入性和排他性。
- 组件,就是一个构造器,带有混入(mixin)其原型的属性。
- 每个组件都有一些基本功能,比如事件处理和组件注册。
- 此外,每个组件的定义都混入一系列自定义属性中,这些属性定义了组件的行为。
- 当向一个DOM节点附加一个组件时,该组件的一个新实例就得以创建。每个组件实例通过其node属性引用DOM节点。
- 组件实例不能直接引用,它们与其他组件通过事件通信。 (补充:并非不能获得,不使用其attachTo,而是new 的话还是可获得组件引用;不建议使用该方式)
如何定义?
通过 component模块 提供的define组件的方法来定义
如何实例化?
通过 attachTo() 方法绑定到dom节点,即创建了实例。
如何交互?
完全通过event。
flight component 特点:
扩展: 基于框架提供的mixin扩展,基于框架提供的advice 切面扩展(优劣)
不提供组件对象的引用:直接绑定到dom,避免组件间通过event外的方式交互(优劣)
当然对于开发阶段来说有用的是initialize
对于运行阶段,teardown提供了一个销毁对象的接口,避免内存泄露
组件无引用也有两面性:一方面避免了耦合,并且通过统一的注册机制也可以做到资源的合理释放;
另一方面只能通过事件通信对于一些组件来说增加了交互复杂度,比如, 对于有嵌套(继承)关系的组件(视图类有嵌套关系的组件等),父子之间不能直接的引用交互,而只能通过事件。
flight事件模型特点:
基于/依赖 jquery dom事件模型 ,而非建立新的事件总线
优势:
- 毫不费力地得到事件广播功能
- 组件可以在文档层面订阅给定的事件类型,或者选择监听来自某特定DOM节点的事件
- 订阅组件不会区分事件来自其他组件的自定义事件,还是原生DOM节点事件,并且会以完全相同方式处理这两种类型的事件。
补充 : 利用jq的dom及事件销毁机制,及时释放无效的事件监听。节省内存。
基于事件驱动的前端工程特点:
优点:模块间完全解耦。便于重用、便于测试
缺点: 阅读代码很难理清程序的流程,需要辅助文档来说明 组件提供的事件及关注的事件等。
不利于调试(虽然flight提供了debugging模块来辅助调试)
需要有一个清晰易分辨的事件命名规则
(自己调试 图片墙的例子:
首先是遗忘了具体的流程细节,
在代码中难以梳理出程序执行的先后,误判了逻辑执行的时间点,导致了错误的排查方向。
)
与我们前端对比:
相同之处:基于AMD的模块管理;基于事件的组件间交互(部分使用);
不同之处:我们未提供一个基础的、统一的组件定义方案,组件的定义相对随意,概念也相对模糊。
flight的轻量级组件是一个抽象层,提供一些实用的方法来规范、管理组件,但没有约束组件的职责。
flight组件的优势是可以mixin一些通用功能,而不用为组件重新编写,尽管我们没有类似功能,但目前的应用来看页面上很少能提取出通用的逻辑(或许页面逻辑不够复杂,或许我们的抽象不够合理), mixin功能对我们的吸引力不大;
我们的组件交互事件与flight在本质上是一样的,只不过flight把jQ的相应方法封装到了组件原型对象上,只暴露了相对简易的使用接口。
与其他mvc框架对比:
flight不关注如何提供数据、如何渲染视图、如何处理路由,flight的component很容易让人与ui类对应上,虽然flight并没有 view(ui)、model(data)、controller(router)等类型之分, 但在实际使用中(示例),还是需要你对 data和ui类的组件做好区分。
如果说 一些mvc框架是轻量级的,flight是更轻量级的,对于构建MVC的工程来说,使用flight开发者还需要做很多基础的事情。
适用何时?何地?何人?
SPA应用(目前twitter是唯一用户,类似应用应该都是用的其他mvc框架)
希望建立一些可重用的(ui widget )component
.......
浏览器支持及依赖
ie7+ , others
依赖:
jquery
es5-shim
amd(requirejs or loadrunner)