MVVM时代的Web控件 ——基于AngularJS实现

前不久，Yahoo宣布了一个消息，停止YUI框架的开发，令人很多感慨。YUI作为最知名的控件库之一，影响了几乎整整一代前端开发人员。

现在这个时代，除了最基本的模式，控件库已经被极大地多样化，差异化了，所以，不用尝试在一个控件中考虑太多，你再考虑也考虑不完需求，反而会把代码变得臃肿。

一些前端MV*模式和Web Components的流行，使得我们可以用更轻松快捷的方式组织界面，在这个过程中，需要重新考虑控件和普通业务界面的分界，控件的概念实际上已经淡化了。

是不是我们就不再需要Web控件库了？也不是。在很多场景下，还是会出现一些固定的UI模式，如果有较好的封装，会对业务开发提供很大的便利。现在流行的新框架很多，AngularJS，Polymer，React，每种都有自己的一套理念，目前各自的生态圈都是不如jQuery的，但我们如果硬把jQuery的控件拖过来，也会很别扭，那怎么办呢？

毛主席教导我们，自己动手，丰衣足食。全新的引擎，就应当有全新的外围，不能开着坦克还射箭，我们试试来自己搞一下。

用每种框架实现控件，都需要遵循它的理念，利用它的优势特性，然后用一些特殊优化来绕过它的弱点。

本文主要基于AngularJS框架，对构建一个Web应用中可能会面临的“控件”进行一些探讨，用下面几个典型的控件实现来大致说明它们的理念差异。

控件的分类方式

对于不同类型的控件，我们的处理方式是不同的，先作一下分类：

容器

所谓容器，意思是主要用于放置一些东西，最多也就做一下状态切换之类的工作，比较典型的是Panel，TabNavigator，Accordion。

在ExtJS这样的控件库里，会有Panel这种纯静态容器，这样的容器其实完全没有封装的必要，封装了可以省一点点编码量，但无足轻重，所以我们无视它。

另有一些界面容器，之前我们会把它做成控件，比如Accordion，TabNavigator，但其实它的内部实现并不复杂，无非是选中项切换，创建或者移除子项等等，而且，还要顺便提供一大堆的参数配置，用于实现界面。

比如，jQuery UI的Accordion实现：https://github.com/jquery/jquery-ui/blob/master/ui/accordion.js，内部封装了各种DOM操作，把HTML打成碎片混在JavaScript中，如果想要做一些UI层面的调整，非常困难。

在MVVM时代，如果借助数据绑定的力量，有可能把这个控件的实现改得跟原先完全不一样。

在AngularJS的主页上，有这么一个Demo：

<tabs>
  <pane title="Localization">
  </pane>
  <pane title="Pluralization">
  </pane>
</tabs>

这个Demo做了两个自定义的标签，用于简化实现TabNavigator的HTML代码。原先我们可能要这么写：

<ul class="nav nav-tabs" role="tablist">
  <li class="active"><a href="#">Home</a></li>
  <li><a href="#">Profile</a></li>
  <li><a href="#">Messages</a></li>
</ul>
<div class="tab-content">
  ...content
</div>

它这么一搞，就比较语义化，代码的可读性增强了，但灵活性丢了很多，想要好用，至少还有一大堆配置项，比如我们想要在每个tab上加个关闭按钮，简直很麻烦。

把容器封装成指令，基本上都是得不偿失的事情，我们还是直接一些，来看一个简单的代码：

http://jsbin.com/homas/6

怎么样，是不是很简单？

因为像Accordion这类控件，内部的逻辑无非是对数组的增删改，使用AngularJS的双向绑定机制，可以极大简化低级的DOM操作，直接用清晰的逻辑把整个业务表达出来，然后给UI充分的自由度。

类似，TabNavigator这个实现选项卡的功能，也可以用一样的方式实现，甚至它的模型跟Accordion都是一样的。看我们的改写：

http://jsbin.com/homas/8

怎样，我们就直接用着Accordion的模型，搞了完全不同的另外一个东西出来，有了这样的方式，还要控件干什么？

数据列表

所谓列表型控件，侧重于数组型数据的表达和展示，比如，List，DataGrid，Tree，一般会有选中等操作。

简单列表

简单的列表其实跟上面的TabNavigator、Accordion的模型一样，就是把数组迭代而已，也基本没有继续成为控件的必要性。

简单的列表可能包含哪些形态呢？

• 纵向的列表，子项纵向排成单列
• 横向的列表，子项横向排成单行
• 下拉列表，子项通过某种操作触发展开
• 瓦片列表，子项流式布局

这些其实都是简单的数组迭代，唯一的差别在样式上。

这个示例给出了纵向列表和瓦片列表的大致代码，它们使用同样的数据源：

http://jsbin.com/yeciga/1

数据表格

比列表稍微复杂一些的是表格。表格是一种很常见的展示多列数据的方式，那么，表格有没有必要封装成控件呢？

这个要看业务场景有多复杂。常规的表格是可以不用封装成控件的，只要普通带样式的table，tr跟td绑定到数据源，选中样式再处理一下，就差不多可以了，单元格里面还可以包含各种复杂的其他组件，都很容易。即使是表头需要排序，这个模板也比较容易写。

那什么样的场景需要封装控件呢？比如说，行列都比较单一，纯展示文本数据，表格头可能要带拖动列宽等效果，总之，在表格数据源之外的方面作了比较多的工作，这种就可以搞成控件。

树形结构

比数组型数据更复杂的是树形数据的展示。

其实，树形结构是一个比较麻烦的东西，任何一个前端的MV*框架，都会希望你把数据模型尽量扁平化，避免过深的层次，而树恰好是反着来的，所以这就导致对树形数据的展现非常别扭。

有一些用AngularJS实现的树控件，使用了递归的数组绑定来实现，写起来确实是很简洁的，但效果不一定好，因为它的监控机制在这种场景下有较大的浪费，比如说，树节点的选中样式绑定到一个监控表达式，当很大数据量中一个节点被选中的时候，可能会要把所有的监控都跑一遍。当然这里的数据模型设计也是会有一些技巧的，比如，改在单个节点上存放选中状态，用于判定样式，会比依赖于控件级的selectedNode变量效率要高不少。

那么，对于这类控件，有什么好办法吗？

我觉得这个东西有两种思路：

• 如果预先知道数据量不大，用递归的方式也无妨。
• 如果数据量比较大，就不使用angular自身的绑定机制来做，而是在directive内部自行控制，做精确的DOM变更。React框架的Virtual DOM技术处理这种情况会有不少优势。

DOM辅助

这类控件比较典型的是ContextMenu，它的核心特征在于：自身的DOM一般直接从属于document对象，或者某个特定容器，不属于触发它的界面部件。AngularJS讲究的是分层、有序，尽量避免DOM操作，但这类控件的特点使得我们不太容易建立它的映射关系，因而不得不从DOM层面入手。

怎么办呢？

我们可以把两种截然不同的东西分离出来，比如说，右键菜单，它的菜单本体使用数据绑定来实现，而用DOM事件来控制它的弹出和关闭过程：

<ul class="dropdown-menu">
    <li ng-repeat-start="menu in menuArr" ng-if="menu.action">
        <a>{{menu.title}} {{aaa}}</a>
    </li>
    <li ng-repeat-end ng-if="!menu.action" class="divider"></li>
</ul>

$http.get("templates/menu/menu.html").then(function(result) {
    var menu = angular.element(result.data);

    $compile(menu)(angular.extend($rootScope.$new(), {
        menuArr: scope.$eval(attrs["snContextmmenu"])
    }));

    element.on("contextmenu", function (evt) {
        if ($document.find("body")[0].contains(menu[0])) {
            menu.css("display", "block");
        }
        else {
            $document.find("body").append(menu);
        }

        //这里根据事件设置一下菜单位置
    });

    $document.on("click", function (evt) {
        menu.css("display", "none");
    });
});

这类控件的处理方式基本上跟传统的是类似的，一般来说只有很特别的，状态跟事件相关的才需要这么做。像下拉式的菜单就不必通过这种方式，因为它的弹出层可以跟自身的DOM放在一起，绑定一个状态变量，当点击触发的时候，把这个变量改变掉就可以了。

公共服务

什么叫做公共服务型呢？是那种直接插入代码流程的UI展现，比较典型的是自定义的Alert，Dialog和Hint，这类代码的调用，是不涉及DOM操作，也不涉及绑定的，设计成公共服务会比较好。

比如说，当业务操作成功，要给出一个统一的提示，就让他用这样的API：

HintService.hint(param);

比如，要弹出自定义的确认取消对话框，就这样：

AlertService.confirm(param)
    .then(confirmHandler, cancelHandler);

又比如，要弹出自定义的对话框，就这样：

DialogService.modal(param, data);

有些使用AngularJS的人会有认识上的误区，认为一切DOM操作都应当放在directive中，并不是这样，要看这个操作是干什么的，如果它起的是一个公共服务的作用，对业务来说不存在关联关系，那就应该设计成service。放在directive中的东西，应当是可以当做一个“组件”来使用的，

独立功能块

这类控件一般是独立功能的区块，跟外界的联系是松散的，跟业务界面没有明显的区别。主要通过事件来通讯，比较典型的是Calendar，Pager。

用一个分页控件pager来举例，它每次在当前选中页变更的时候对外发送一个事件，外界监听这个事件，并作出相应的操作。分页在很多管理系统中，真是一个很常见的东西。有些UI框架会把分页功能跟数据表格等控件捆绑，内置为它们的一个选项，这么做其实有不少缺点。

首先是增加了控件本身的逻辑复杂度，其次是不灵活了。

当分页控件独立出来之后，它如何跟外界交互呢？这其实跟普通的多块界面部件之间的通信并无差异，实际上，界面部件自身并不通信，因为他们都只是实例化之后的视图模板，真正可以用于通信的是随同它们一起实例化的视图模型，也就是AngularJS中的控制器，在控制器上通过$scope可以进行通信。

所有随界面模板实例化的$scope都挂在$rootScope为根的树上，然后通过事件进行通讯，从上往下是$broadcast，从下往上是$emit。当然，也可以自己造一个事件总线用于跨层级通讯。

那么，对于分页控件这样的东西来说，应当怎样去跟包含它的界面通信呢？

在有些基于AngularJS的控件库中，分页控件直接操作$parent的数据，在我看来，这不是一种好方式，原因稍后说。对于此类控件来说，使用事件与外界交互是最自然的方式，它使得界面组件之间的耦合性大幅降低。

表单增强

比较典型的是DatetimePicker，ColorPicker。

这类控件其实也可以算独立功能型，作这样的划分，主要是考虑到在大部分MVVM框架里，原生的input，select，textarea等都是有特殊增强的，可以直接跟数据模型绑定，它们跟外界唯一的交互就是数据模型。对于像DatetimePicker这样的控件，其实业务方并不关心它内部是怎么实现的，做了什么操作，只需要关注最后的选中值，从这一点来看，它跟普通的input并无区别。

这类控件是最适合封装成Angular指令（directive）的。

现在我们有些纠结了，从形态来说，表单增强类控件跟上面这种独立功能块的差别在哪里？为什么把分页划分到独立功能，而把DatetimePicker划分到表单增强呢？

分类的原则不是说它像不像表单元素，而是它是否应当能直接访问包含它的界面块的数据模型。

对于表单增强型的控件，设计思路一般是没有歧义的，大家都会让它直接绑定数据模型。那独立功能型的控件，为什么不能让它直接绑定数据模型呢？

这个差别主要来源于控件和数据模型的“距离”。表单增强型控件跟数据模型的距离非常近，因此它直接使用数据模型没有问题，但是界面增强型控件，很可能这个距离较远，比如说，至少要从父级视图模型中转一下。

设想我们要构建一个多widgets的门户，其中有一个widget是个日历，使用了Calendar控件，这个日历取值变更的时候，可能影响其他到其他widgets的行为。如果我们让它能访问父级数据，会导致系统结构变得混乱，所以只能限制它用事件。

动画

那么，碰到一些要使用动画的情况，该怎么办呢？

传统的方式，用JavaScript去根据浏览器的支持度，封装不同的实现，通常是三种：JavaScript动画，CSS Transition，CSS Animation。

在AngularJS中，如果用于状态变迁的动画，用后两种非常方便，只需要把各状态对应成CSS样式类，然后使用ng-class来绑定样式名就可以了。

如果是专门的动画效果，可以用directive封装起来，根据特征的不同，选择封装成元素或者属性。

图表

以AngularJS为代表的MVVM框架，使我们能够远离烦琐的DOM操作。我们回想在业务中使用的不同控件，似乎还有一类没有覆盖到，那就是图表库。

传统的JavaScript图表库，有些是基于Canvas的，从实现机制上来说，无需依赖jQuery这样的DOM操作库，这类通常封装了自己的基础操作，自成一体，本身做得很优秀，典型的有百度的ECharts。如果想把它跟Angular这样的框架集成，一般来说在上面套一个directive的壳即可，在内部调用真正的实现。

注意到还有另外一些图表库，核心是适配了SVG或者VML实现的，比如说，基于RaphaelJS做的图表控件。我们看一下Raphael的常见代码写法：

for (var i = 0; i < 5; i++) {
  paper.circle(10 + 15 * i, 10, 10)
    .attr({fill: "#000"})
    .data("i", i)
    .click(function () {
      alert(this.data("i"));
    });
}

哎，这代码的样子怎么这么熟悉？像不像jQuery？因为使用SVG或者VML来显示图形，本质是跟DOM操作一样的，所以它也选用了像jQuery一样的代码方式。

我们大胆再想一步，普通的基于HTML元素的控件，我们不用jQuery了，而是通过绑定的方式，那图表库是不是也可以这样呢？

来尝试一下：

http://jsbin.com/yokik/1

是不是很有意思？

这个例子本身很简单，用来代替成熟图表库的话，可以说差得非常远，但它说明了我们有可能用怎样的思路去实现图表库。

传统图表库的缺点是，整个视觉方面都只能由程序员控制，对视觉方面有经验的人只能给出配色和布局的建议，然后等程序员实现了之后，再回头来继续提出建议修改。

使用我们提到的这种方式，就把数据逻辑和界面展现分离得非常好，可以像写普通HTML界面那样，分别由不同的人员协作，然后组装在一起。

如果我们想要把同样的数据换一种图形来展示，也会非常容易，不需要改变模型，只要把视图层换掉，立刻完成。

比如这个例子，使用了同一个数据模型：

http://xufei.github.io/ng-charts/index.html

这个例子还可以进一步封装成directive，以SVG片段作模板，从元素属性和上级作用域中获取参数，这样使用起来更便利。

小结

我们回过头来想一想，控件的本质是什么？是特定数据结构的交互展现。会有哪些数据结构呢？总结起来，真的是很简单，因为常见的就这么几种：

• 简单值或者单个对象
• 数组
• 树

其他好像都没有了。

传统的控件，封装的主要逻辑是数据模型跟DOM之间的对应关系，而这种关系被AngularJS这种MVVM框架作为基础设施提供了。把代码重构之后，我们会惊奇地发现，控件的界面和逻辑分离得干干净净，我们可以复用这个逻辑，在不同的场景下把控件界面多样化，以此来面对不停变更的需求。

因此，在MVVM的时代，我们需要把控件库用与以往完全不同的方式来重新设计，去掉一些不再适合作为控件的，把其他的控件展现跟行为分离，让模型更精炼，给UI层更多的自由度，控件这个概念会淡化很多。

从这一点看，新的模式会对我们的HTML和CSS规划能力要求更高，因为之前在控件内部封装了DOM的处理，当需要整体调整的时候，有机会在控件这个层面去统一处理，但把控件界面分离并多样化之后，这部分压力就会转移到DOM和样式规划者手中。

所以，我们会发现，那些使用AngularJS的人，会很倾向于用BootStrap或者Foundation这类样式框架，因为对他来说，样式和界面结构规划变成了一个非常重要的事情了，而这类框架会帮助他们把这个部分的基础工作做好。

总而言之，把数据模型从控件中提取出来，把UI层配置化，是使用AngularJS这类框架的核心要点。

随着时代的发展，浏览器特性逐渐增强，新框架层出不穷，我们能够有机会选用一些较新的实现技术，大幅简化或者完全改变之前的实现方式。

未来会更加美好。

本文提到的一些控件的基础demo可以参见这里，因为比较仓促，所以问题还有很多，只是大致说明了构建不同控件的思路，以后会逐步完善。

http://xufei.github.io/ng-control/index.html