Twitter Flight 学习小结

链接：twitter flight

关键字： 基于事件交互；轻量级的组件；

flight特点：

     component基于dom：组件绑定到dom上

     事件驱动：组件依赖event通信

     分离关注点原则（体现在组件无引用、组件间完全解耦 ，和 AOP的应用）

介于单页面型应用和开放型应用之间的框架，核心是事件驱动、基于dom的组件，强调组件之间相对独立松散的架构，但对组件的定义又十分严格，具有一定的侵入性和排他性。

 

Flight component的概念：

如何定义？

     通过 component模块 提供的define组件的方法来定义

 如何实例化？    

     通过 attachTo（） 方法绑定到dom节点，即创建了实例。

如何交互？

     完全通过event。

 

flight  component 特点：

     扩展：        基于框架提供的mixin扩展，基于框架提供的advice 切面扩展（优劣）

     不提供组件对象的引用：直接绑定到dom，避免组件间通过event外的方式交互（优劣）

     简单的生命周期：  initialize （before，after） ，teardown

                              当然对于开发阶段来说有用的是initialize

                              对于运行阶段，teardown提供了一个销毁对象的接口，避免内存泄露

 

组件无引用也有两面性：一方面避免了耦合，并且通过统一的注册机制也可以做到资源的合理释放；

另一方面只能通过事件通信对于一些组件来说增加了交互复杂度，比如， 对于有嵌套（继承）关系的组件（视图类有嵌套关系的组件等），父子之间不能直接的引用交互，而只能通过事件。

 

 

 

flight事件模型特点：

     基于/依赖 jquery dom事件模型 ，而非建立新的事件总线    

     优势：

               需要有一个清晰易分辨的事件命名规则

          （自己调试 图片墙的例子：

                    首先是遗忘了具体的流程细节，

                    在代码中难以梳理出程序执行的先后，误判了逻辑执行的时间点，导致了错误的排查方向。

          ）

 

与我们前端对比：

     相同之处：基于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)