Angular 1.x和ES6的结合
Angular 1.x和ES6的结合
在Web前端技术飞速发展的今天，Angular 1.x可以说是一个比较旧的东西，而ES6是新生事物。我们想要把这两个东西结合起来，感觉就好像“十八新娘八十郎，苍苍白发对红妆。”但这件事的难度也并不大，因为我们最终是要把ES6构建成ES5代码，而ES5代码是可以很容易和Angular 1.x协作的。
不过，为什么我们要干这件事呢？
尽管在整个前端开发圈中，大家并不是很欢迎Angular，而且很多人认为它的1.x版本已经衰落，但我跟 @小猪有个观点是一致的，那就是：“在企业开发领域，ng1的应用才方兴未艾”，也就是说，它在这个领域其实还是上升阶段。
所以，在不少场合下，它还是要承载一些开发工作，部分老系统的逐步平滑迁移也是比较重要的。
做这件事的另外一个意图是：虽然未来的框架选型会有不少争议，但有一点毋庸置疑，那就是业务JS代码的全面ES6或者TS化，这一点我们现在就可以着手去做，并且可以尽量把数据和业务逻辑层实现成框架无关的形式。
模块机制
Angular 1.x的module机制是比较别扭的，也是一种框架私有的模块机制，所以，我们需要淡化这层东西，具体的措施是：
- 把各功能模块的具体实现代码独立出来
- module机制作为一个壳子，对功能模块进行包装
- 每个功能分组，使用一个总的壳子来包装，减少上级模块的引用成本
- 每个壳子文件把module的name属性export出去
举例来说，我们有一个moduleA，里面有serviceA，serviceB，那么，就有这样一些文件：
serviceA的实现，service/a.js
export default class ServiceA {}
serviceB的实现，service/b.js
export default class ServiceB {}
moduleA的壳子定义，moduleA.js
import ServiceA from "./services/a";
import ServiceB from "./services/b";
export default angular.module("moduleA", [])
.service("ServiceA", ServiceA)
.service("ServiceB", ServiceB)
.name;
存在一个moduleB要使用moduleA：
import moduleA from "./moduleA";
export default angular.module("moduleB", [moduleA]).name;
注意，这里为什么我们要export module的name呢？这是为了这个module的引用者方便，如果某个module改名了，所有依赖它的module可以不修改代码。
在这里我们可以看到，a.js，b.js，moduleA.js这三个文件，只有moduleA是作为一次性的配置项，而a和b可以尽量实现成框架无关的代码，这样将来的迁移代价会比较小。
service，factory，controller，filter
在Angular 1.x里面，有factory和service两个概念，其实这两者可以替换，service传入的是构造函数，通过new创建出实例，而factory传入的是工厂函数，通过对这个工厂函数的调用而创建实例。
所以，如果要使用ES6代码来编写这个部分，也就很自然了：
serviceA的实现，service/a.js
export default class ServiceA {}
serviceA的模块包装器moduleA的实现
import ServiceA from "./service/a";
export angular.module("moduleA", [])
.service("ServiceA", ServiceA)
.name;
factoryA的实现，factory/a.js
import EntityA from "./model/a";
export default function FactoryA {
return new EntityA();
}
factoryA的模块包装器moduleA的实现
import FactoryA from "./factory/a";
export angular.module("moduleA", [])
.factory("FactoryA", FactoryA)
.name;
注意看这个例子中，FactoryA函数的返回结果是new EntityA，在实际项目中，这里不一定是通过某个实体类创建的，也可能是直接一个对象字面量：
export default function FactoryA {
return {
a: 1
};
}
在ES6下，factory的定义其实可以有一些优化，比如说，我们可以不需要factory/a.js这个文件，也不需要这层factory封装，而是在module定义的地方，这样写：
import EntityA from "./model/a";
export angular.module("moduleA", [])
.factory("FactoryA", () => new EntityA())
.name;
使用ES6定义controller的方式大致与service相同，
如何处理依赖注入
有一点值得注意，刚才我们提到的模块定义方式里，并没有考虑依赖注入，但实际业务中一般都要注入点东西，那怎么办呢？
有两种办法：
controllers/a.js
export default class ControllerA {
constructor(ServiceA) {
this.serviceA = ServiceA;
}
}
ControllerA.$inject = ["ServiceA"];
import ControllerA from "./controllers/a";
export angular.module("moduleA", [])
.controller("ControllerA", ControllerA);
或者：
controllers/a.js
export default class ControllerA {
constructor(ServiceA) {
this.serviceA = ServiceA;
}
}
import ControllerA from "./controllers/a";
export angular.module("moduleA", [])
.controller("ControllerA", ["ServiceA", ControllerA]);
个人推荐前一种，理由是，一个模块的依赖项声明，最好跟其实现放在一起，这样对可维护性更有利。
在考虑依赖注入的时候，还存在另外一个问题，我们现在这样做，实质上已经弱化了Angular自身的DI，但这时候，为什么我们还需要DI？如果我们在一个Controller里面依赖某个Service，大可以直接import它啊，为什么还非要去从DI走一圈？
这里面有个麻烦，如果你所依赖的东西没有对Angular DI依赖，那还好，不然的话，没法实例化，比如说：
export default class ServiceA {
constructor($http) {}
}
ServiceA.$inject = ["$http"];
如果我要在一个别的东西里实例化这个ServiceA，就没法给它传入$http，这些东西要从ng里获取，考虑是不是搞个专门的实例化函数，类似provider，专门去做这个实例化，这样可以消除DI，直接import。
directive
这个是终极纠结点了，因为一个directive，可能包含有compile，link等多个成员函数，各种配置项，一个可选controller之类，这里面我们要考虑这么一些东西：
- directive自身怎么定义为ES6代码
- 里面的各项成员如何处理
- controller如何定义
我们看一下directive主要包含些什么东西，它其实是一个ddo（Directive Definition Object），所以本质上这是一个对象，我们可以给它构建一个类。
export default class DirectiveA {
}
DDO上面的东西大致可以分两类，属性和方法，所以就在构造函数里这样定义：
constructor () {
this.template = template;
this.restrict = "E";
}
像这些都是基础的配置字符串，没什么特别的。剩下的就是controller和link，compile等函数了，这些东西其实也简单，比如controller，可以先实现一个普通controller类，然后赋值到controller属性上来：
this.controller = ControllerA;
注意现在写directive，尽量使用controllerAs这样的语法，这样controller可以清晰些，不必注入$scope，而且还可以使用bindToController属性，把在attr上定义的属性或者方法直接传递到controller实例上来。
比如我们要做一个日期控件，最后合起来就是这样：
import template from "../templates/calendar.html";
import CalendarCtrl from "../controllers/calendar";
import "../css/calendar.css";
export default class CalendarDirective {
constructor() {
this.template = template;
this.restrict = "E";
this.controller = CalendarCtrl;
this.controllerAs = "calendarCtrl";
this.bindToController = true;
this.scope = {
minDate: "=",
maxDate: "=",
selectedDate: "=",
dateClick: "&"
};
}
link (scope) {
// 这段代码太别扭了，但问题是如果搬到controller里面去写成setter，会在constructor之前执行，真头疼，先这样吧
scope.$watch("calendarCtrl.selectedDate", newDate => {
if (newDate) {
scope.calendarCtrl.calendar.year = newDate.getFullYear();
scope.calendarCtrl.calendar.month = newDate.getMonth();
scope.calendarCtrl.calendar.date = newDate.getDate();
}
});
}
}
然后，在module定义的地方：
import CalendarDirective from "./directives/calendar";
export default angular.module("components.form.calendar", [])
.directive("snCalendar", () => new CalendarDirective())
.name;
上面这个例子里，还有些比较头疼的地方。本来我们剥离了清晰的controller，就是为了里面不要有$scope这些奇奇怪怪的东西，但我们需要$watch这个selectedDate的赋值，就折腾了，$watch是定义在$scope上面的，而如果在controller上给selectedDate定义一个setter，可能由于babel跟angular共同的作用，时序有点问题……后面再想办法优化吧。
一个directive除了有这些，还可以有template的定义，所以在这个例子里我们也是用import把一个html加进来了，Webpack的html loader会自动把它变成一个字符串。
还有，组件化的思想指导下，单个组件也应当管理自己的样式，所以我们在这里也import了一个css，这个后面会被Webpack的css loader处理。
消除显式的$scope
我们前面提到，做这套方案有一个很重要的意图，那就是在数据和业务逻辑层尽量清除Angular的影子，使得除了最上层的部分，其他都可以被其他框架方案使用，比如React和Vue，这里面有一些关键。
在Angular 1.x中，一个核心的东西是$scope，它是一切东西运行的基石，然而，把这些东西暴露给一线开发者，其实并不优雅，所以，Angular 1.2之后，逐步提供了一些选项，用于减少开发过程中对$scope的显式依赖。
那么，我们可能会在什么场景下用到$scope，主要用到它的什么能力呢？
- controller中注入，给界面模板中的绑定变量或者方法用
- 依赖属性的计算，比如说我们可以手动$watch一个变量、对象、数组，然后在变更回调中更改另外的东西
- 事件的冒泡和广播，根作用域
- directive中的controller，link等函数使用
我们一个一个来看，这些东西怎么消除。
controller注入
以前我们一般要在controller中注入$scope，但是从1.2版本之后，有了controllerAs语法，所以这个就不再必要了，之前是这样：
<div ng-controller="TestCtrl">
<input ng-model="aaa">
div>
xxx.controller("TestCtrl", ["$scope", function($scope) {
$scope.aaa = 1;
}]);
现在成了：
<div ng-controller="TestCtrl as testCtrl">
<input ng-model="testCtrl.aaa">
div>
xxx.controller("TestCtrl", [function() {
this.aaa = 1;
}]);
这里的关键点就在于，controller变成了一个纯净的视图模型，实际上框架会做一件事：
$scope.testCtrl = new TestCtrl();
所以，对于这一块，其实我们是不必担忧的，把那个function换成一个普通的ES6 Class就好了。
依赖属性的计算
我们知道，在$scope上，除了有$watch，$watchGroup，$watchCollection，还有$eval（作用域上的表达式求值）这类东西，我们必须想到对它们的替代办法。
先来看看$watch，一个典型的例子是：
$scope.$watch("a", function(val) {
$scope.b = val + 1;
});
这个我们的办法很简单，在ES5+，对象上是有setter和getter的，那我们只要在ES6代码里这么定义就行了：
class A {
set a(val) {
this.b = val + 1;
}
}
如果有多个变量的观测，比如：
$scope.$watchGroup(["firstName", "lastName"], function(val) {
$scope.fullName = val.join(",");
});
我们可以写多个setter来做，也可以写一个getter：
class A {
get fullName() {
return this.firstName + "," + this.lastName;
}
}
下一个，$watchCollection，这个有些复杂，因为它可以观测数组内部元素的变化，但其实JavaScript语法层面是缺少一些东西的，对比其他语言，早在十多年前，C# 1.0中就支持了indexer，也就是可以自定义下标操作。
不过这个也难不倒我们，在Adobe Flex里面，有一个ArrayCollection，实际上是封装了对于数组的操作，所以，我们需要的只是把数组的变更操作封装起来，不直接在原始数组上进行操作就好了。
所以我们的结构就类似如下：
class A {
constructor() {
this.arr = [];
}
add(item) {
this.arr.push[item];
//这里干点别的
}
}
对于这个封装好的东西，我们的原则是：读取操作可以直接取引用，但是写入操作必须通过封装的这些方法去调用。
这里还有技巧，我们其实是可以把这类数组操作全部封装，也搞成类似ArrayCollection那样，但很多时候，ArrayCollection太通用了，我们其实要的是强化的领域模型，而不是通用模型。所以，针对每个业务模型单独封装，有其自身的优势。
注意，我们这里仅仅是封装了数组元素的操作，并未对元素自身属性的变更，或者高维数组，这些需要多层封装。
事件的冒泡和广播
在$scope上，另外一套常用的东西是$emit，$broadcast，$on，这些API其实是有争议的，因为如果说做组件的事件传递，应当以组件为单位进行通信，而不是在另外一套体系中。所以我们也可以不用它，比较直接的东西通过directive的attr来传递，更普遍的东西用全局的类似Flux的派发机制去通信。
根作用域的问题也是一样，尽量不要去使用它，对于一个应用中全局存在的东西，我们有各种策略去处理，不必纠结于$rootScope。
directive等地方中的$scope
哎，其实理论上是可以把业务代码中每个地方都搞得完全没有$scope的，而且也能比较优雅通用，但是。。。总有一些例外。
先看看正常的吧。
我们知道，在定义directive的时候，ddo中有个属性是scope，这个里面定义了要在directive内外进行传递的属性或者方法，并且有不同的传递类型。我们又知道，directive有个controllerAs选项，可以类似前面提到的，controller中不注入$scope：
class TestCtrl {
constructor() {
this.a = 1;
}
}
export default class CalendarDirective {
constructor() {
//...
this.controller = TestCtrl;
this.controllerAs = "testCtrl";
this.scope = {
a: "="
};
}
}
这时候就有个问题了，我们知道，最终结构会变成：
$scope.testCtrl.a == 1;
但这句：
this.scope = {
a: "="
};
又会导致$scope.a == 1，而且，在testCtrl这个实例中，如果你不显式传入$scope，还访问不到外面那个a，这跟我们的预期是不相符的。所以，这时候我们要配合用bindToController，可以写个属性true，也可以把scope对象搬上去（1.4以上版本支持）。
所以代码就成了这样：
class TestCtrl {
constructor() {
this.a = 1;
}
}
export default class CalendarDirective {
constructor() {
//...
this.controller = TestCtrl;
this.controllerAs = "testCtrl";
this.bindToController = true;
this.scope = {
a: "="
};
}
}
这样都对了吗，并不会……
我们再综合一下：
class TestCtrl {
constructor() {
this.a = 1;
}
set a(val) {
this.b = val + 1;
}
}
export default class CalendarDirective {
constructor() {
//...
this.controller = TestCtrl;
this.controllerAs = "testCtrl";
this.bindToController = true;
this.scope = {
a: "="
};
}
}
这里，只是在TestCtrl中给a加了一个setter，然而这个代码是不运行的，貌似绑定过程有问题，所以我才会在上面那个地方加了个很别扭的$watch，也就是：
class TestCtrl {
constructor() {
this.a = 1;
}
}
export default class CalendarDirective {
constructor() {
//...
this.controller = TestCtrl;
this.controllerAs = "testCtrl";
this.bindToController = true;
this.scope = {
a: "="
};
}
link(scope) {
scope.$watch("testCtrl.a", val => scope.testCtrl.b = val + 1);
}
}
而且，这里再$watch的话，需要把controller实例的别名也作为路径放进去，testCtrl.a，而不是a。总之还是有些别扭，但我觉得这里应该还有办法解决。
// 上面这段等我有空详细再想想
有的时候，直接把setter或者getter绑定到界面，会不太适合，虽然Angular的ng-model中支持getterSetter这种辅助，但毕竟还有所不同，所以很多时候我们很多时候可能需要把带getter和setter的业务对象下沉一级，外面再包装一层给angular绑定用。
小结
在任何一个严谨的项目中，应当有比较确定的业务模型，即使脱离界面本身，这些模型也应当是可以运作的，而ES6之类语法的便利性，使得我们可以更好地组织下层业务代码。即使目的不是为了使用Angular 1.x，这一层的精心构造也是有价值的。当做完这层之后，上层迁移到各种框架都基本只剩体力活了。