浴火重生的Angular

Angular团队近期公布了他们对2.0版本的一些考虑，很详尽，很诚恳，我读了好几遍，觉得有必要写点东西。

对于一个运行在浏览器中的JavaScript框架而言，最喜欢什么，最害怕什么？是标准的变动。那么，放眼最新的这些标准，有哪些因素会对框架产生影响呢？

• module
• Web Components
• observe
• promise

这几点，我是按照影响程度从大到小排列的。下面逐条来说：

module

早期的JavaScript在模块定义方面基本没有约束，但作为框架来说，不按照某种约定的方式去写代码，就会导致一盘散沙，所以各家都自己搞一套，大部分还是各不兼容的，这是历史原因造成的，不能怪罪这些框架。最近几年，为了解决这些问题，人们又发明了AMD，CMD，以及各种配套库和工程库。好不容易有些框架向它们靠拢了，可是module又来了。

这真是没完。我知道很多人是对module有意见的，我自己也觉得有些别扭，但我坚信一个道理：有一个可用但是稍微别扭的标准，比没有标准要好得多。所以，不管怎样，既然他来了，就得想办法往上靠。不靠拢标准的后果是什么？非常严重，因为现在的Web是加速发展的，浏览器只要过了一个升级瓶颈，后面的发展快得出奇。不要看现在还有这么多老旧浏览器，很可能你睡一觉起来突然发现已经基本没人用了，到那时候，不紧跟标准的框架就很惨了，瞬间就边缘化了。

我们来看看Angular原先的module设计，如果是在五年前，它刚起步的时候看，可能觉得还可以，现在再看，问题就比较多了。Angular现有版本的module，其实跟我们在ES中看到的module不是一个概念，更像C#里面的namespace，它的各种controller，service，factory才是真的模块。

我认为现有版本的这块，有几个不好的地方：

• 现有的module实际上毫无意义，根本不能起约束作用。
• 从API的角度强制区分模块职责是没有必要的，比如说，service和factory的区别在哪里？仅仅在于返回与封装的方式不同，其实是可以通用的，所以只需一种工厂方法就可以了，用户愿意返回什么就返回什么，他自己通过命名来区分这个模块的职责。
• 没考虑模块的动态加载。这是Angular目前版本最大的设计问题，对于大型应用来说，很致命，所以目前大家都是通过各种黑魔法来解决这个问题。

所以，Angular 2.0中，把这一块彻底改变了，使用ES6的module来定义模块，也考虑了动态加载的需求。变动很大，很多人有意见，但我是支持他们的。这件事不得不做，即使现在不做，将来也还是要做。毛主席教导我们：革命不彻底，劳动人民就要吃两茬苦，受两茬罪。在现在这个时代，如果还继续用非标准的模块API，基本等于找死，所以它需要改变。

Web Components

为什么Web Components也能带来这么大的影响呢，因为它同样会造成断代升级，也就是说，你非完全跟着它的路不可，没有选择。

Web Components标准本身同样是个见仁见智的话题，在本文中我不评价，它作为标准，既然来了，大家当然要往上靠。一个致力于大规模Web前端开发的现代框架，不考虑Web Components是完全不可想象的。那么，怎么去靠拢它呢？

Web Components提供了一种封装组件的方式，对外体现为自定义标签，对内体现为Shadow DOM，可以定义自己的属性、事件等，这样问题就来了。

我们看当前版本的Angular，能看到ng-click之类的扩展元素属性，那么，他为什么要写成ng-click？是因为这是对原生click的一层封装和转换，同理，如果我的原始事件不是click，是另外一个名字，你当然也得跟着加一个，不然针对这种东西的操作就玩不下去。所以说，其实它是给每个有价值的原生事件都写了扩展。

这就有问题了，你能这么做的原因是，你预先知道有这么一些元素，这么一些事件，也知道这些元素上的这些事件是什么行为，如果全是自定义的，他不告诉你，你急死也不知道，怎么办？所以这一块必须重新设计。

同理，属性也是这样，之前像img的src，就有一个ng-src，如果没这个，你设置在上面的表达式就会被当成真的url，先去加载一次，显然是不对的。所以，设置在ng-src上，它等表达式解析出结果了，再把结果设置到src去。如果是用Web Components扩展的自定义组件，它不知道你有哪些属性，就搞不下去了。

所以，Angular 2.0团队在这一块还很纠结，需要很多探索，很多权衡才能找到一种能接受的方式。

后来在这一块，我跟@RubyLouvre 探讨了一下，他的观点是不要让数据绑定接触到Web Components，也就是说，不让扫描进入“暗世界”，我想了想，觉得也有道理，只是这样Web Components跟原生元素就要区别对待了。

或者对所有Web Components使用同一个壳子再次封装？感觉还是很怪。

observe

当前版本的Angular使用脏检测的方式来实现数据的关联更新，这种机制有一定优点，但缺点也非常明显。

在其他语言中要监控数据的变更，很多在语言层面上有get和set，一般都是从这个角度入手，有不少JavaScript框架也是从这个方面做下去的，Angular不是。

Angular的脏检测很有特色，它采用的是新旧值比对的方式，也就是说，对每个可变动的模型，保存上一次的值，然后通过手动，或者是封装事件调用检测，一遍又一遍地刷新模型，直到稳定，或者超出容忍限度。

为什么这里面会有不稳定现象呢？我举个简单的例子，这是伪代码，仅供演示：

function Entity() {      //初始化      this.a = 1;      this.b = 1;      this.c = 1;        //监控语句，伪代码      this.b = this.a + 1;      this.c = this.b + 1;  }

这里面几条语句不是真的赋值，是用来表示：每当a变化了，b就跟着变，然后c也跟着变，那我们在这里就要创建两个监控，一个是对a的监控，在里面给b赋值，一个是对b的监控，在里面给c赋值。

好了，比如有人给a赋了个新值，我们一个脏检测循环下来，b增加了1，c也跟着增加了，好像没什么问题。那我们怎么知道整个模型稳定了呢？很简单也很无奈，再运行脏检测一次，这次a没变，所以另外两个也不变了，跟上一次检测之后的结果一样，所以就认为它稳定了。

这里我们看到，不管你怎样，只要变过数据，至少要跑两次脏检测。为什么说至少呢，因为我们这种情况刚好把坑给绕过了，来改下代码：

function Entity() {      //初始化      this.a = 1;      this.b = 1;      this.c = 1;        //监控语句，伪代码      this.c = this.b + 1;      this.b = this.a + 1;  }

没改什么，只是把两条监控语句互换了，这个结果就不对了。为什么呢，比如a赋值为1之后，第一遍结果是这样的：

• a = 1;
• c = 2;
• b = 2;

这里讨厌的是c的监控语句先执行了，但b还没有变，可是我们当时是不知道的。然后，我们想看看模型稳定了没有，就再检测一次。所谓的检测，其实是两个步骤：把所有监控语句跑一遍，对比本次结果与上次的差异。

那么，这次变成了：

• a = 1;
• c = 3;
• b = 2;

第二轮结束。模型稳定了吗？其实已经稳定了，但是代码是不知道的，它判断稳定的依据是，本次结果与上次相同，可事实是不同的，所以它还得继续跑。

第三次跑完，终于跟第二次结果一样了，于是他认为模型稳定了，开始把真正的值拿出去用了。

所以这个过程的效率在很多种情况下偏低，但好在他这个变更不是实时的，而是通过某些东西批量触发，所以也还凑合。另外有些框架，是每次对数据赋值了就去立刻更新关联值，这当数据结构比较复杂的时候，这样比较高效。

Object.observe与之相比，在定义监控的时候比较直观一些，而且，基于set get的绑定框架，有些会在原始数据的原型上定义一些“私有”方法，相比来说，observe这种方式从数据的外部视角来处理变更，更合理一些。

Angular 2.0的数据绑定机制应该会使用observe重写，可以期待这个方面有较大的提升。

但不管什么绑定方式，都是有坑的。我知道读者中有不少坏人，你们看到这里肯定想到很多坏主意了，比如刚才的脏检测，有没有办法把这个过程搞死？很容易，我帮你写个简单的：

function Entity() {      //初始化      this.a = 1;      this.b = 1;        //监控语句，伪代码      this.a = this.b + 1;      this.b = this.a + 1;  }

这个代码死循环了，形成了监控闭环。所以，在Angular里面发现循环到一定量的时候，就会觉得它停不下来，终止这个循环。在其他技术实现的绑定框架中，同样要解决此类问题，所以监控到变更的时候，也不是直接拿去应用。

promise

很奇怪啊，我一直喜欢promise这种编写异步代码的方式。可能我对它的喜好来自一些背景，比如说，做可视化组件编程。这个可视化的意思是指通过拖拽配置，配置逻辑流程（注意，不是拖UI）。

比如说，流程细到方法的粒度，每个步骤映射到一个方法，然后拖拽这些步骤，配置出执行流程。这里面有个麻烦就是异步，比如说，某个方法异步了，那就麻烦了，因为在一个纯拖动的配置系统中，如果你还要让他手工调整什么东西甚至改代码的话，这个事情基本就白做了。

所以你看，promise在这里优势很大。每一个有异步倾向的方法，我都让它返回promise，甚至为了一致性，不异步的方法也这么干，每个方法的入参出参都是map，让promise带着，是不是就很好了？

以上是我个人见解，可忽略，谢谢。

那么，在Angular 2.0中promise有什么影响呢？

回顾Angular 1.x版本，在其中已经可以看到很多promise的身影，只是那时候用了$q，一个小型的promise实现。在2.0中，promise的使用将更加广泛，因为更多的东西是异步的了，比如新的路由系统。

promise本身是很容易被降级的，在原生不支持它的浏览器中也很容易搞出一个polyfill来。

这个事情在我个人看来是很喜闻乐见的。

Angular 2.0除了作出符合标准的改进，还有一些提升的方面：

依赖注入

Angular大量使用了依赖注入。在JavaScript里面怎样做依赖注入呢？比如这段代码：

function foo(moduleA, moduleB) {      moduleA.aaa(moduleB);  }

a跟b这两个模块都要注入进来。对于依赖注入系统而言，首先要知道注入什么，比如这里，至少要先知道a和b是什么，怎么知道呢？很多框架都用一种方式，就是先把foo这个待注入函数toString，这就取得了函数定义的文本，然后使用正则表达式提取参数名。

这个办法可行，但不可靠，它害怕压缩。随便什么压缩工具，肯定认为形参名是没用的，随手就改成a或者b了，这样你连正确的模块名都找不到了。那怎么办呢，只能老土一些：

foo.$inject = ["moduleA", "moduleB"];

这样总可以了吧？

这样写起来还是有些折腾，而且运行时的数据也不够完全，所以Angular 2.0很激进地引入了一种类似TypeScript的语言叫AtScript，支持类型和注解，比如它的这个例子：

import {Component} from 'angular';  import {Server} from './server';    @Component({selector: 'foo'})  export class MyComponent {    constructor(server:Server) {        this.server = server;    }  }

一些配置信息就可以搞在注解里，类型信息也就丰富了，然后这代码编译成ES6或者5，多么美好。更美好的是，2.0借助这种语言，可能把原来的指令、控制器之类的东西统一成组件，使用普通ES6 class加注解的方式来编写它们的代码，消除原来那么多复杂冗余的概念。

其实还有很多改进点，比如路由等等，没法一一列出了，感兴趣的可以查阅Angular 2.0已经流出的文档，或者查阅它的github库。

小结

Angular 2.0这次的规划真是脱胎换骨，看了介绍文档，简直太喜欢了，之前我考虑过的所有问题都得到了解决。这一次版本跟之前有太大变化，从旧版本迁移可能是个难题，不过相对它所带来的改进，这代价还是值得的。勇于革自己的命，总比被别人革命好，期待Angular的浴火重生！