tw_wangzhengquan
tw_wangzhengquan

i致我们终将组件化的Web

阅读更多

转载自AlloyTeam：http://www.alloyteam.com/2015/11/we-will-be-componentized-web-long-text/

这篇文章将从两年前的一次技术争论开始。争论的聚焦就是下图的两个目录分层结构。我说按模块划分好，他说你傻逼啊，当然是按资源划分。

i致我们终将组件化的Web_第1张图片 《=》i致我们终将组件化的Web_第2张图片

 

 

”按模块划分“目录结构，把当前模块下的所有逻辑和资源都放一起了，这对于多人独自开发和维护个人模块不是很好吗？当然了，那争论的结果是我乖乖地改回主流的”按资源划分“的目录结构。因为，没有做到JS模块化和资源模块化，仅仅物理位置上的模块划分是没有意义的，只会增加构建的成本而已。

虽然他说得好有道理我无言以对，但是我心不甘，等待他日前端组件化成熟了，再来一战！

而今天就是我重申正义的日子！只是当年那个跟你撕逼的人不在。

 

##  模块化的不足

    模块一般指能够独立拆分且通用的代码单元。由于JavaScript语言本身没有内置的模块机制（ES6有了！！），我们一般会使用CMD或ADM建立起模块机制。现在大部分稍微大型一点的项目，都会使用requirejs或者seajs来实现JS的模块化。多人分工合作开发，其各自定义依赖和暴露接口，维护功能模块间独立性，对于项目的开发效率和项目后期扩展和维护，都是是有很大的帮助作用。

    但，麻烦大家稍微略读一下下面的代码

 

 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
require ( [
     'Tmpl!../tmpl/list.html' , 'lib/qqapi' , 'module/position' , 'module/refresh' , 'module/page' , 'module/net'
] , function ( listTmpl , QQapi , Position , Refresh , Page , NET ) {
     var foo = '' ,
         bar = [ ] ;
     QQapi . report ( ) ;
     Position . getLocaiton ( function ( data ) {
         //...
     } ) ;
     var init = function ( ) {
         bind ( ) ;
         NET . get ( '/cgi-bin/xxx/xxx' , function ( data ) {
             renderA ( data . banner ) ;
             renderB ( data . list ) ;
         } ) ;
     } ;
     var processData = function ( ) {
     } ;
     var bind = function ( ) {
     } ;
     var renderA = function ( ) {
     } ;
     var renderB = function ( data ) {
         listTmpl . render ( '#listContent' , processData ( data ) ) ;
     } ;
     var refresh = function ( ) {
         Page . refresh ( ) ;
     } ;
     // app start
     init ( ) ;
} ) ;

 

上面是具体某个页面的主js，已经封装了像Position，NET，Refresh等功能模块，但页面的主逻辑依旧是”面向过程“的代码结构。所谓面向过程，是指根据页面的渲染过程来编写代码结构。像：init -> getData -> processData -> bindevent -> report -> xxx 。 方法之间线性跳转，你大概也能感受这样代码弊端。随着页面逻辑越来越复杂，这条”过程线“也会越来越长，并且越来越绕。加之缺少规范约束，其他项目成员根据各自需要，在”过程线“加插各自逻辑，最终这个页面的逻辑变得难以维护。

i致我们终将组件化的Web_第3张图片

开发需要小心翼翼，生怕影响“过程线”后面正常逻辑。并且每一次加插或修改都是bug泛滥，无不令产品相关人员个个提心吊胆。

 

## 页面结构模块化

基于上面的面向过程的问题，行业内也有不少解决方案，而我们团队也总结出一套成熟的解决方案：Abstractjs，页面结构模块化。我们可以把我们的页面想象为一个乐高机器人，需要不同零件组装，如下图，假设页面划分为tabContainer，listContainer和imgsContainer三个模块。最终把这些模块add到最终的pageModel里面，最终使用rock方法让页面启动起来。

i致我们终将组件化的Web_第4张图片
（原过程线示例图）

i致我们终将组件化的Web_第5张图片
（页面结构化示例图）

下面是伪代码的实现

 

 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
require ( [
     'Tmpl!../tmpl/list.html' , 'Tmpl!../tmpl/imgs.html' , 'lib/qqapi' , 'module/refresh' , 'module/page'
] , function ( listTmpl , imgsTmpl , QQapi , Refresh , Page ) {
 
     var tabContainer = new RenderModel ( {
         renderContainer : '#tabWrap' ,
         data : { } ,
         renderTmpl : "
  • {{item}}
    • "     ,
             event : function ( ) {
                 // tab's event
             }
         } ) ;
     
         var listContainer = new ScrollModel ( {
             scrollEl : $ . os . ios ? $ ( '#Page' ) : window ,
             renderContainer : '#listWrap' ,
             renderTmpl : listTmpl ,
             cgiName : '/cgi-bin/index-list?num=1' ,
             processData : function ( data ) {
                 //...
             } ,
             event : function ( ) {
                 // listElement's event
             } ,
             error : function ( data ) {
                 Page . show ( '数据返回异常[' + data . retcode + ']' ) ;
             }
         } ) ;
     
         var imgsContainer = new renderModel ( {
             renderContainer : '#imgsWrap' ,
             renderTmpl : listTmpl ,
             cgiName : '/cgi-bin/getPics' ,
             processData : function ( data ) {
                 //...
             } ,
             event : function ( ) {
                 // imgsElement's event
             } ,
             complete : function ( data ) {
               QQapi . report ( ) ;
             }
         } ) ;
        
         var page = new PageModel ( ) ;
         page . add ( [ tabContainer , listContainer , imgsContainer ] ) ;
         page . rock ( ) ;
     
    } ) ;

     

    我们把这些常用的请求CGI，处理数据，事件绑定，上报，容错处理等一系列逻辑方法，以页面块为单位封装成一个Model模块。

    这样的一个抽象层Model，我们可以清晰地看到该页面块，请求的CGI是什么，绑定了什么事件，做了什么上报，出错怎么处理。新增的代码就应该放置在相应的模块上相应的状态方法（preload，process，event，complete…），杜绝了以往的无规则乱增代码的行文。并且，根据不同业务逻辑封装不同类型的Model，如列表滚动的ScrollModel，滑块功能的SliderModel等等，可以进行高度封装，集中优化。

     

    现在基于Model的页面结构开发，已经带有一点”组件化“的味道。每个Model都带有各自的数据，模板，逻辑。已经算是一个完整的功能单元。但距离真正的WebComponent还是有一段距离，至少满足不了我的”理想目录结构“。

     

    ## WebComponents 标准

    我们回顾一下使用一个datapicker的jquery的插件，所需要的步奏：

    1. 引入插件js

    2. 引入插件所需的css（如果有）

    3. copy 组件的所需的html片段

    4. 添加代码触发组件启动

    现阶段的“组件”基本上只能达到是某个功能单元上的集合。他的资源都是松散地分散在三种资源文件中，而且组件作用域暴露在全局作用域下，缺乏内聚性很容易就会跟其他组件产生冲突，如最简单的css命名冲突。对于这种“组件”，还不如上面的页面结构模块化。

    于是W3C按耐不住了，制定一个WebComponents标准，为组件化的未来指引了明路。

    下面以较为简洁的方式介绍这份标准，力求大家能够快速了解实现组件化的内容。（对这部分了解的同学，可以跳过这一小节）

     

    1.