Angular 学习笔记（一）

时间 2019-12-01

原文原文链接

前言：本文是我在工做中应用和实践Angular时的一系列知识总结，本文是做为我在团队内作的一次技术分享的辅助和大纲。虽然没办法分享现场的音频，可是我也花了很多心思来准备这篇文章，但愿能对刚接触Angular的同窗有所帮助。本次先带来第一阶段的分享：Angular初探-应用架构，适合在通读Angular官方文档（中文）至少1遍后参考本文来梳理一些比较大的概念。html

一 Angular 应用架构

理解 Angular，首先须要理解三大核心概念：模块、组件和服务，其他的特性都是基于这三大概念衍生出来的。好比组件与服务之间有依赖注入特性，模块为组件和服务提供了编译的上下文以及一些功能（指令、管道等）支持。视图的更新依赖于双向绑定，视图的变换对应着组件的切换，而组件的切换须要路由机制......git

1. 模块

1.1 什么是 Angular 模块？

Angular 应用是模块化的，它拥有本身的模块化系统，称做 NgModule。github

一个 NgModule 就是一个容器，用于存放一些内聚的代码块，这些代码块专一于某个应用领域、某个工做流或一组紧密相关的功能。它能够包含一些组件、服务或其它代码文件，他们的做用域由包含它们的 NgModule 定义。编程

他做为模块还能够导入一些由其它模块中导出的功能，同时自身也能够导出一些指定的功能供其它 NgModule 使用。bootstrap

实现上，NgModule 是一个带有 @NgModule 装饰器的类：数组

关于 es7 装饰器，能够参考我翻译的这篇文章：探索 EcmaScript 装饰器浏览器

import { NgModule }      from '@angular/core';
import { BrowserModule } from '@angular/platform-browser';
@NgModule({
  imports:      [ BrowserModule ], // 导入了本模块中的组件模板所需的类的其它模块
  providers:    [ Logger ],        // 本模块向应用全局贡献的服务。 这些服务能被本应用中的任何部分使用。
  declarations: [ AppComponent ],  // 属于本 NgModule 的组件、指令、管道
                                   // 每一个组件都应该（且只能）声明在一个 NgModule 类中。
  exports:      [ AppComponent ],  // 能在其它模块的组件模板中使用的可声明对象的子集
  bootstrap?:    [ AppComponent ]  // 应用的主视图，称为根组件。它是应用中全部其它视图的宿主。
                                   // Angular 建立它并插入 index.html 宿主页面。
                                   // 只有根模块才应该设置这个 bootstrap 属性。
  entryComponents?: [SomeComponent]
})
export class AppModule { }
复制代码

@NgModule 的参数是一个元数据对象，用于描述如何编译组件的模板，以及如何在运行时建立注入器。缓存

它会标出该模块本身的组件、指令和管道，经过 exports 属性公开其中的一部分，以便外部组件使用它们。 NgModule 还能把一些服务提供商添加到应用的依赖注入器中。bash

1.2 NgModule 与 JavaScript 模块的区别

Angular 应用中使用的模块其实有两种，一种是 JavaScript 模块，一种是 NgModule。服务器

关于 js 模块系统，能够参考我翻译的这篇文章：模块系统

js 模块是一个包含代码的独立文件，经过导入导出机制为该文件内的代码加上独立的命名空间，避免了变量的冲突。
NgModule 是一个带装饰器的类，是 Angular 内部的一个概念。其做用也是把某一部分的特性代码组织起来，好比组件，服务，指令等，造成一个大的应用单元。只不过这些特性代码存在不一样的文件内，或者说存在于不一样的类中。
应该说，js 模块包含了 NgModule，NgModule 经过特定的语法（装饰器 + 元数据）将一些代码组织起来，而后经过 js 模块将其导入/导出。
另外，NgModule 只在声明 Angular 模块时会用到，而 js 模块贯穿了整个项目，由于每一块特性代码都须要经过 js 模块的导入导出机制来将其串在一块儿。

1.3 NgModule 的种类

在 angular 内部，将 NgModule 划分为了两种（注意，不管根模块仍是特性模块，其 NgModule 结构都是同样的，只是从功能上划分出这两个概念）：

根模块：顾名思义，“根”模块必然为整个 Angular 应用的基础和核心，他的功能就是将全部开发者自创的特性模块组织起来，接收一些全局的配置项，以及引导应用在浏览器中启动。根模块与其余任何特性模块的一个定义方式上的差别就是根模块装饰器的元数据中多了一个 bootstrap 属性，经过 bootstrap 属性声明一个应用的根组件（入口组件），而后基于这个根组件来生长整个应用的组件树，呈现出一个完整的应用。

这里插播一个组件的概念：入口组件（entry component）。他是命令式生成的一种组件，区别于声明式（开发者显式地在模板中引用某一个组件）的方式，入口组件多是根组件（由 Angular 的启动机制自动加载到 index.html 模板中），也能够是定义在路由中的组件（此时由路由器根据相应的路由规则来动态插入到当前视图中）。

理论上说，全部的入口组件都应该声明到@NgModule 装饰器的 entryComponents 元数据对象属性中，可是 Angular 编译器会隐式地把根组件和路由定义的组件添加为 entryComponents，因此咱们不须要显示声明这一类入口组件了。

Angular 编译器只会为那些能够从 entryComponents 中直接或间接访问到的组件生成代码，内部使用摇树优化(tree shaker)来剥离那些无关的组件，保持应用的精简和高效。基于这个原理，有时候咱们可能会使用到一些 UI 库提供的组件（弹窗），为了不这类组件被编译器排除，咱们就须要手动在 entryComponents 中添加这些组件的引用声明。
特性模块：能够理解为开发者建立的其余 NgModule 的统称。根据不一样特性模块的功能特征，又能够分为：
- 领域特性模块
- 带路由的特性模块
- 路由模块
- 服务特性模块
- 可视部件特性模块
这个分类其实只是为了区分不一样 NgModule 的功能，是一个组织应用的最佳实践准则，并不须要严格划分。举个例子，几乎每个复杂的模块都须要定义路由，可是咱们能够把路由这个关注点专门抽离出来，统一到一个路由特性模块中，这样方便咱们统必定义和划分应用路由层次。这样就能够在应用不断成长时保持应用的良好结构，而且当复用本模块时，你能够轻松的让其路由保持无缺。

2. 组件

组件控制屏幕上被称为视图的一小片区域。咱们在类中定义组件的应用逻辑，为视图提供数据和行为支持。组件经过一些由属性和方法组成的 API 与视图交互。

实现上，经过@Component 装饰器和元数据来将一个类标记为组件：

@Component({
  selector: 'app-hero-list',
  templateUrl: './hero-list.component.html',
  providers: [HeroService]
})
export class HeroListComponent implements OnInit {
  /* . . . */
}
复制代码

selector：是一个选择器，它会告诉 Angular，一旦在模板 HTML 中找到了这个选择器对应的标签，就建立并插入该组件的一个实例。
templateUrl：该组件的 HTML 模板文件地址。 或者，使用 template 属性的值来直接定义内联的 HTML 模板。 这个模板定义了该组件的宿主视图。
providers 是当前组件所需的依赖注入提供商的一个数组。在这里声明的依赖注入会提供一个与组件一同建立和销毁的实例。

2.1 组件的模板

模板很像标准的 HTML，可是它还包含 Angular 的模板语法，这些模板语法能够根据应用逻辑、应用状态和 DOM 数据来修改这些 HTML。模板可使用数据绑定来协调应用和 DOM 中的数据，使用管道在显示出来以前对其进行转换，使用指令来把程序逻辑应用到要显示的内容上。

下面的例子：

<h2>Hero List</h2>

<p><i>Pick a hero from the list</i></p>
<ul>
  <li *ngFor="let hero of heroes" (click)="selectHero(hero)">
    {{hero.name}}
  </li>
</ul>

<app-hero-detail *ngIf="selectedHero" [hero]="selectedHero"></app-hero-detail>
复制代码

这个模板使用了典型的 HTML 元素，好比 <h2> 和 <p>，还包括一些 Angular 的模板语法元素，如 *ngFor，{{hero.name}}，(click)、[hero] 和 <app-hero-detail></app-hero-detail>。这些模板语法元素告诉 Angular 该如何根据程序逻辑和数据在屏幕上渲染 HTML。

模板语法分红三类：数据绑定，管道和指令。

2.1.1 数据绑定

经过特定的绑定语法，Angular 能够自动地将组件中的属性和方法与模板对应起来，创建一种带有方向的映射关系。

上面的例子中，{{hero.name}}的语法称为插值表达式，他是一种从组件类绑定属性到 DOM 的模板语法。

[hero]="selectedHero"的语法称为属性绑定，他也是一种将组件类的属性绑定到 DOM 的模板语法。他们之间的区别在于，使用插值表达式是为了显示对应的数据到视图中，而属性绑定是一种数据的传递，将宿主组件的属性传递到子组件或者指令中，而后由接受者决定如何使用这部分数据，某种意义上说，属性绑定是一种通讯机制。

(click)="selectHero(hero)"的语法称为事件绑定，这里的事件是一系列用户触发的 UI 行为，鼠标操做，键盘行为等，这些行为附带一些信息。咱们须要从 DOM 监听到这些行为和信息，而后传递给咱们的组件类中相应的处理函数，在组件类中来处理这些行为，好比更新视图中的部分属性，向服务器请求一些数据，甚至是引发视图的变换等。很明显，它的绑定方向是从 DOM 到组件的，与前两种相反。

实际上事件绑定一样支持开发者本身定义的事件，这部分会在深刻使用部分详细介绍。

还有一种绑定形式是 angular 最为著名的双向绑定。他是属性绑定和事件绑定的结合，语法以下：

<input [(ngModel)]="hero.name">
复制代码

在 Angular 内部会将这种语法作即时、自动的处理（隐式），用户的输入会自动更新到组件类中对应的属性上，而组件类中对应属性的变化也会当即反映到视图中来。

2.1.2 管道

管道是一类转换函数，他接收一个输入，经过预先设定的处理规则对输入作加工和转化，而后输出结果，并用结果替换掉本来的输入。管道的使用须要与插值表达式和管道操做符( | )结合起来：

<p>Today is {{today | date}}</p> 经过管道咱们能够很方便地对视图内一些数据进行统一转化，以更为友好的方式来展现这些数据。同时他又具备通用性，他从本该作这部分工做的组件类中分离出来，让咱们的组件类更加精简和专一于业务。

2.1.3 指令

指令就是一个带有 @Directive 装饰器的类。和组件同样，指令的元数据把指令类和一个选择器关联起来，选择器用来把该指令插入到 HTML 中。他们都是 Angular 编译器对模板作解析和编译的基础，Angular 编译器找到这些选择器指令分为结构型指令和属性性指令，结构型指令经过添加、移除或替换 DOM 元素来修改布局，属性型指令会修改现有元素的外观或行为。

上文中提到的*ngIf就是一个结构型指令，而 ngModel 则是一个属性型指令。

2.1.4 总结一下

模板会把 HTML 和 Angular 的模板标记语法组合起来，这些模板标记语法能够在 HTML 元素显示出来以前修改它们。

模板中的指令会提供程序逻辑，而绑定语法会把你应用中的数据和 DOM 链接在一块儿。

属性绑定让你将从应用数据中计算出来的值插入到 HTML 中，显示给用户。
事件绑定让你的应用能够经过更新应用的数据来响应目标环境下的用户输入。

在视图显示出来以前，Angular 会先根据你的应用数据和逻辑来运行模板中的指令并解析绑定表达式，以修改 HTML 元素和 DOM。

Angular 支持双向数据绑定，这意味着 DOM 中发生的变化（好比用户的选择）一样能够反映回你的程序数据中。

模板也能够用管道转换要显示的值以加强用户体验。

2.2 路由

在用户使用应用程序时，Angular 的路由器能让用户从一个视图导航到另外一个视图。

首先分析一下浏览器的导航模式：

在地址栏输入 URL，浏览器就会导航到相应的页面。
在页面中点击连接，浏览器就会导航到一个新页面。
点击浏览器的前进和后退按钮，浏览器就会在你的浏览历史中向前或向后导航。

Angular 的 Router（即“路由器”）借鉴了这个模型：

它把浏览器中的 URL 看作一个指南，据此导航到一个由客户端生成的视图，并能够把参数传给支撑视图的相应组件，帮它决定具体该展示哪些内容。
你能够为页面中的连接绑定一个路由，这样，当用户点击连接时，就会导航到应用中相应的视图。当用户点击按钮、从下拉框中选取，或响应来自任何地方的事件时，你也能够在（组件）代码控制下进行导航。
路由器还在浏览器的历史日志中记录下这些活动，这样浏览器的前进和后退按钮也能照常工做。

每一个带路由的 Angular 应用都有一个 Router（路由器）服务的单例对象。当浏览器的 URL 变化时，路由器会查找对应的 Route（路由），并据此决定该显示哪一个组件。

2.2.1 路由配置

咱们使用路由配置来声明应用中咱们预设的一些路由规则，这样 Angular 的路由器就能够按照这些预设的规则将 URL 的变化与咱们的应用视图变换对应起来。

const appRoutes: Routes = [
  { path: 'crisis-center', component: CrisisListComponent },
  { path: 'hero/:id', component: HeroDetailComponent },
  {
    path: 'heroes',
    component: HeroListComponent,
    data: { title: 'Heroes List' }
  },
  {
    path: '',
    redirectTo: '/heroes',
    pathMatch: 'full'
  },
  { path: '**', component: PageNotFoundComponent }
];
复制代码

2.2.2 路由出口

路由出口就是用于告诉 Angular 路由器，当 URL 的变化匹配到路由配置里的某一项的path时，在模板中的何处插入component对应的组件实例。

<router-outlet></router-outlet>
<!-- 路由命中时的组件会被插入到此处 -->
复制代码

2.2.3 路由连接

稍微了解过 html 的话，就会知道页面中的跳转、连接是以<a href="SOME_URL">标签的形式来实现的，这种方式在 Angular 里有另外一种形式，经过一个叫routerLink的指令来作这件事，由于 Angular 是单页应用，尽管看起来在一个 Angular 应用里能够处处穿梭，页面不断变化，但这只是一个障眼法，是 Angular 经过不断修改同一个页面中的 DOM，不断建立、更新、隐藏、销毁一个个组件来实现的。因此要想在 Angular 里作“跳转”的操做，也须要一个障眼法机制，他就是路由连接。

<a routerLink="/heroes" routerLinkActive="active">Heroes</a>
复制代码

3 服务

理解服务这个概念，能够从他的词性来入手。名词性质的服务是服务这个概念的具体实现，狭义地讲，他就是一个类，这个类有一些明确的用途。

服务作了一类事情，好比从服务器获取数据并预处理，验证用户的输入，或者是写日志，在内存中缓存一些能够被全局应用共享的数据或状态，还能够做为组件之间通讯的中间介质。

动词性质的服务则与组件关联起来，依赖注入（Dependency Injection）是他们之间的桥梁，服务是生产者，组件是服务的消费者。

Angular 里将组件和服务区分开，是为了提升模块性和复用性，同时进一步将组件的功能划分出来，让组件更加专一于特定的业务。

3.1 依赖注入

依赖注入是 Angular 另外一个著名的特性，他是不少面向对象语言框架设计原则中的“控制反转”的一种实现方式。在依赖注入模式中，应用组件无需关注所依赖对象的建立和初始化过程，能够认为框架已初始化好了，开发者只管调用便可。

依赖注入有利于应用程序中各模块之间的解耦，使得代码更容易维护。这种优点可能一开始体现不出来，但随着项目复杂度的增长，各模块、组件、第三方服务等相互调用更频繁时，依赖注入的优势就体现出来了。开发者能够专一于所依赖对象的消费，无需关注这些依赖对象的产生过程，这将大大提高开发效率。

举个例子：

export class Car {

  public engine: Engine;
  public tires: Tires;
  public description = 'No DI';

  constructor() {
    this.engine = new Engine();
    this.tires = new Tires();
  }
}
复制代码

Car 类在本身的构造函数中建立了它所需的一切。这样作的话 Car 类是脆弱、不灵活以及难于测试的。

为何？

Car 类须要一个引擎 (engine) 和一些轮胎 (tire)，它没有去请求现成的实例，而是在构造函数中用具体的 Engine 和 Tires 类实例化出本身的副本。若是 Engine 类升级了，它的构造函数要求传入一个参数，此时这个 Car 类就被破坏了，在更新 Engine 实例化方式以前 Car 类都不可用，原本是 Engine 类的更改，引发了连锁反应，连累了 Car 类也要跟着修改，Car 类变得脆弱了。另外一方面，测试的时候更麻烦了，你会受制于它背后的那些依赖，你须要考虑 Engine 类的建立是否成功了，若是 Engine 类还有依赖，那就得一层一层继续深刻，原本测试一个 Car 类，结果你无法控制这辆车背后隐藏的依赖。当不能控制依赖时，类就会变得难以测试。

如何让 Car 类更强壮、可测试？

答案是把 Car 的构造函数改形成 DI 的版本：
constructor(public engine: Engine, public tires: Tires) { }
复制代码
而后咱们在建立一辆车的时候就能够往构造函数中传入 Engine 和 Tire 的实例来实例化 Car 类：
let car = new Car(new Engine(), new Tires());
复制代码
这样一来引擎和轮胎这两个依赖的定义与 Car 类自己解耦了。若是有人扩展了 Engine 类，那就再也不是 Car 类的烦恼了。

刚刚了解了什么是依赖注入：它是一种编程模式，可让类从外部源中得到它的依赖，而没必要亲自建立它们。他是用来建立对象及其依赖的其它对象的一种方式。当依赖注入系统建立某个对象实例时，会负责提供该对象所依赖的对象（称为该对象的依赖）。

可是上面的尝试，只作到了 Car 类的可维护性，可是对于要实例化 Car 类的外部环境来讲，工做量反而多了：本来只关心 Car 类的构造，如今连 Engine 和 Tire 类的构造工做也要作了，WTF?

若是，有一种机制，咱们只须要直接列出想要的东西，而不用管这些东西如何建造，直接拿现成的，该多好。

像这样：let car = injector.get(Car);，使用 Car 的消费者不须要知道如何建立 Car 类，Car 类也不须要知道如何建立 Engine 和 Tire 类，这些工做都交给注入器，无论是消费者仍是 Car 类，都直接向注入器索要须要的依赖。

这种机制就是“依赖注入框架”。A 依赖于 B，那 B 就是 A 的依赖，同时 A 和 B 都会被这个 DI 框架维护起来。

3.2 Angular 中的 DI

首先介绍几个简单的概念。

注入器(Injector): 就像制造工厂，提供了一系列的接口用于建立依赖对象的实例。
- 咱们不须要不用自行建立 Angular 注入器，Angular 会在启动过程当中为你建立全应用级注入器。该注入器维护一个包含它已建立的依赖实例的容器，并尽量复用它们。
提供商(Provider)：用于配置注入器，注入器经过它来建立被依赖对象的实例，Provider 把标识映射到工厂方法中，被依赖的对象就是经过该方法建立的。
- 对于 Angular 服务来讲，Provider 一般就是这个服务类自己。
依赖(Dependence)：指定了被依赖对象的类型，注入器会根据此类型建立对应的对象。

在把 Angular 中的服务类注册进依赖注入器以前，它只是个普通类而已。Angular 自己无法自动判断你是打算自行建立服务类的实例，仍是等注入器来建立它。你必须经过为每一个服务指定服务提供商来配置它。提供商会告诉注入器如何建立该服务，而后 Angular 的依赖注入器负责建立服务的实例，并把它们注入到组件类中。你不多须要本身建立 Angular 的依赖注入器。当 Angular 运行本应用时，它会为你建立这些注入器，首先会在引导过程当中建立一个根注入器。

有不少方式能够为注入器注册服务提供商。

3.2.1 在服务类前加上装饰器@Injectable 和相应的元数据来标记出该服务类是用来注入的，也即配置了一个提供商。

import { Injectable } from '@angular/core';

@Injectable({
  providedIn: 'root' // providedIn 告诉 Angular，它的根注入器要负责调用 HeroService 类的构造函数来建立一个实例，并让它在整个应用中都是可用的。
})
export class HeroService {
  constructor() {}
}
复制代码

3.2.2 在 NgModule 的 providers 元数据中注册提供商

providers: [
  UserService, // { provide: UserService, useClass: UserService }
  { provide: APP_CONFIG, useValue: SOME_DI_CONFIG }
],
复制代码

3.2.3 在组件中注入服务

Angular 在底层作了大量的初始化工做，这大大简化了建立依赖注入的过程，在组件中使用依赖注入须要完成如下三个步骤：

经过 import 导入被依赖对象的服务
在组件中配置注入器。在启动组件时，Angular 会读取@Component 装饰器里的 providers 元数据，它是一个数组，配置了该组件须要使用到的全部依赖，Angular 的依赖注入框架就会根据这个列表去建立对应对象的实例。
在组件构造函数中声明所注入的依赖。注入器就会根据构造函数上的声明，在组件初始化时经过第二步中的 providers 元数据配置依赖，为构造函数提供对应的依赖服务，最终完成注入过程。

当 Angular 建立组件类的新实例时，它会经过查看该组件类的构造函数，来决定该组件依赖哪些服务或其它依赖项。

当 Angular 发现某个组件依赖某个服务时，它会首先检查是否注入器中已经有了那个服务的任何现有实例。若是所请求的服务尚不存在，注入器就会使用之前注册的服务提供商来制做一个，并把它加入注入器中，而后把该服务返回给 Angular。

当全部请求的服务已解析并返回时，Angular 能够用这些服务实例为参数，调用该组件的构造函数。

import { Component } from '@angular/core';
import { SomeService } from './some-service.service';

@Component({
  selector: 'app-some-component',
  templateUrl: './some-component.component.html',
  styleUrls: ['./some-component.component.less']
})
export class SomeComponent {
  constructor(private _someService: SomeService) {}
}
复制代码

4. 例子应用

基于以上知识，咱们来分析一个最小化的 Angular 应用，看看以上内容是怎么有机结合起来的。

这部份内容不便于文字展现，这里就省略了。