关于前端:Angular依赖注入模式的应用和玩法案例

1 注入，一种组件树状层级通信模式 & 设计模式

1.1 组件通信模式

在 Angular 工程开发中，通常咱们应用 Input 属性绑定和 Output 事件绑定进行组件通信，然而 Input 和 Output 却只能在父子组件中传递信息。组件依据调用关系造成一棵组件树，如果只有属性绑定和事件绑定，那么两个非间接关系组件要通信，须要通过各个连接点自身，中间人须要一直解决和传递一些它自身不须要晓得的信息（如图 1 左）。而 Angular 中提供的 Injectable 的 Service，能够在模块、组件或者指令等提供，搭配在构造函数的注入，正好能解决这个问题（图 1 右）。

图 1 组件通信模式

左图只通过父子组件传递信息，节点 a 和节点 b 进行通信就须要通过诸多节点；如果节点 c 想要通过一些配置管制节点 b，他们两头的节点也必须设置额定的属性或者事件来透传对应的信息。右图的依赖注入模式节点 c 能够提供一个供节点 a、b 通信的服务，节点 a 间接和节点 c 提供 服务通信，节点 b 也间接和节点 c 提供的服务通信，最初通信就被简化了，两头节点也没有耦合该局部内容，对上上层组件产生的通信无显著的感知。

1.2 应用依赖注入实现管制反转

依赖注入（DI）并不是 Angular 特有的，它是实现管制反转（IOC）设计模式的伎俩，依赖注入的呈现解决手动实例化过分耦合的问题，所有资源不禁应用资源的单方治理，而由不应用资源资源核心或者第三方提供，这样能带来很多益处。第一，资源集中管理，实现资源的可配置和易治理。第二，升高了应用资源单方的依赖水平，也就是咱们说的耦合度。

类比事实世界就是，咱们去购买商品比方一支铅笔，咱们只须要找个商店购买一支类型为铅笔的商品，咱们不关怀这支铅笔产地是哪里，木头和铅笔芯都是怎么粘合的，咱们只须要它能实现铅笔的书写性能即可，咱们不会和具体的铅笔制造商或者工厂有分割。而对于商店，它就能够本人去适合的渠道洽购铅笔，实现资源的可配置。

联合编码场景，更具体的说，使用者不须要显式创立实例（new 操作），就能注入并应用实例，实例的创立由提供商 (providers) 决定。资源的治理是通过令牌（token），因为不关怀提供商，不关怀实例的创立，应用方就能够通过一些部分注入的伎俩（对 token 进行二次配置），最终实现替换实例，依赖注入模式的利用和切面编程（AOP）相辅相成。

2 Angular 中的依赖注入

依赖注入是 Angular 框架最重要几个的外围模块之一，Angular 不仅提供 Service 类型的注入，自身组件树就是一颗注入依赖树，函数和值也能够被注入。也就是说在 Angular 框架中，子组件是能够通过父组件的 token（通常为类名），注入父组件实例的。在组件库开发中有大量案例是通过注入父组件，实现交互和通信的，包含参数挂载，状态共享，甚至获取父组件所在节点的 DOM 等等。

2.1 解析依赖

要应用 Angular 的注入，首先就要明确它的注入解析的过程。相似于 node_modules 的解析过程，当找不到依赖都有找不到依赖会始终冒泡到父层去找依赖。旧版 (v6 前) 的 Angular 会将注入解析的过程分为多级模块注入器，多级组件注入器和元素注入器。新版（v9 后）简化为两级模型，第一个查问链是动态 DOM 层级的元素注入器、组件注入器等统称为元素注入器，另一个查问链是模块注入器。解析的程序和解析失败后的默认值官网的这个代码正文文档 (provider_flag) 里讲的比较清楚了。

图 2 两级注入器查找依赖过程 (图片起源)

也就是说组件 / 指令以及在组件 / 指令层级提供注入内容会优先在组件视图中元素里寻找依赖始终到根元素，如果没有找到则接着在元素以后所在模块，援用（蕴含模块援用和路由懒加载援用）该模块的父级模块一次往上找直到根模块和平台模块。

留神这里注入器是有继承的，元素注入器能够创立并继承父元素的注入器的查找函数，模块注入器也相似。当一直继承之后，就有点像 js 对象的 prototype 链了。

2.2 配置提供商

明确了依赖解析的程序优先级，咱们就能够在适合的层级对内容进行提供。咱们曾经晓得它有两种类型：模块注入和元素注入。

• 模块注入器：在 @NgModule 的元数据属性里能够配置 providers，还能够应用 v6 当前提供的 @Injectable 申明 provideIn 申明为模块名、’root’ 等。（实际上在 root 根模块之上还有两个注入器，Platform 和 Null，这里不探讨它们。）
• 元素注入器：在组件 @Component 的元数据属性里能够配置 providers，viewProviders，或者在指令的 @Directive 元数据里的 providers.

另外，实际上 @Injectable 装璜器除了用了申明模块注入器外，也能够申明为元素注入器。更常常会将其申明为在 root 提供，以实现单例。它通过类本人集成元数据来防止模块或者组件间接显式申明 provider，这样如果该类没有任何组件指令服务等类注入它，就没有代码链接到该类型申明，就能够被编译器疏忽，从而实现了摇树。

还有一种提供办法是申明 InjectionToken 的时候间接给出值。

这里给出这几种形式的速写模板：

@NgModule({
  providers: [// 模块注入器]
})
export class MyModule {}

@Component({
  providers: [// 元素注入器 - 组件]，viewProviders: [// 元素注入器 - 组件视图]
})
export class MyComponent {}

@Directive({
  providers: [// 元素注入器 - 指令]
})
export class MyDirective {}

@Injectable({providedIn: 'root'})
export class MyService {}

export const MY_INJECT_TOKEN = new InjectionToken<MyClass>('my-inject-token', {
 providedIn: 'root',
 factory: () => {return new MyClass();
 }
});

提供依赖的地位不同的抉择会带来一些差别，最终影响着包的大小，依赖的能被注入的范畴和依赖的生命周期。对于不同的场景，如单例（root），服务隔离（module），多重编辑窗（component）等都有不同的实用计划，该当抉择正当的地位，防止共享的信息不当，或者代码打包的冗余。

2.3 多样的值函数工具

如果只是提供实例的注入，那还显示不出 Angular 框架依赖注入的灵活性。Angular 提供了很多灵便的注入工具，useClass 主动创立新实例，useValue 应用动态值，useExisting 能够复用已有的实例，useFactory 通过函数来结构，搭配指定 deps 指定结构函数参数，这些组合起来玩法能够十分花色。能够半路截胡一个类的 token 令牌替换成另一个本人筹备好的实例，能够造一个 token 先保存起来值或者实例，而后再在前面须要用到的时候从新替换回去，甚至能够用工厂函数返回实例的部分信息实现映射成另一个对象或者属性值。这里的玩法会通过前面的案例进行论述，这里就先不开展。官网也有很多例子能够参考。

2.4 注入生产和装璜器

Angular 中的注入能够在构造函数 constructor 内注入，也能够拿到注入器 injector 通过 get 办法获取已有的注入元素。

Angular 反对在注入的时候减少装璜器进行标记，

• @Host() 来限度冒泡
• @Self() 限度为元素本身
• @SkipSelf() 限度为元素本身以上
• @Optional() 标记为可选
• @Inject() 限度为自定义 Token 令牌

这里有一篇文章《@Self or @Optional @Host? The visual guide to Angular DI decorators.》十分活泼形象地展现父子组件间如果应用了不同的装璜器，最初会命中的实例有什么不同。

图 3 不同注入装璜器的筛选后果

2.4.1 补充：宿主视图和 @Host

这几个装璜器外面，最不好了解的可能就是 @Host 了，这里补充一些 @Host 的具体阐明。
官网对 @Host 装璜器的解释是

…retrieve a dependency from any injector until reaching the host element

Host 在这里是宿主的意思，@Host 这个装璜器将会限定查问的范畴在宿主元素 (host element) 以内。什么是宿主元素呢？如果 B 组件是 A 组件模板应用的组件，那么 A 组件实例就是 B 组件实例的宿主元素。组件模板产生的内容称为 View（视图），同一个 View 对于不同组件来说可能是不同视图。如果 A 组件在本人的 template 范畴内应用 B 组件（见图 4），A 的模板内容造成的视图（红框局部）对 A 组件来说就是 A 的内嵌视图，B 组件在这个视图内，所以对 B 来说这个视图就是 B 的宿主视图。装璜器 @Host 就是限定搜寻范畴为宿主视图之内，找不到不会再进行冒泡了。

图 4 内嵌视图和宿主视图

3 案例和玩法

上面咱们通过实在的案例，来看看依赖注入到底是怎么运行起来的，怎么排查谬误，以及还能怎么玩。

3.1 案例一：模态窗创立动静组件，找不到组件问题

DevUI 组件库的模态窗组件提供了一个服务 ModalService，该服务能够弹出一个模态框，而且能够配置为自定义的组件。业务的同学常常在应用这个组件的时候报错，包找不到自定义的组件。

比方以下的报错：

图 5 应用 ModalService 的时候创立援用 EditorX 的组件的报错找不到对应服务提供商

剖析 ModalService 是如何创立自定义组件的，ModalService 源码 Open 函数 第 52 行和第 95 行。能看到，componentFactoryResolver如果没有传入就应用 ModalService 注入的componentFactoryResolver。而大多数状况下，业务会在根模块引入一次 DevUIModule，然而不会在以后模块里引入 ModalModule。也就是现状图 6 是这样的。依据图 6，ModalService 的 injector 内是没有 EditorXModuleService 的。

图 6 模块服务提供关系图

依据注入器的继承，解决办法有四个：

1. 把 EditorXModule 放到 ModalModule 申明的中央，这样注入器就能找到 EditorXModule 提供的 EditorModuleService —— 这是最蹩脚的一种解法，自身 loadChildren 实现的懒加载就是为了缩小首页模块的加载，后果是子页内须要用到的内容却放在 AppModule，首次加载就把富文本的大模块给加载了，减轻了 FMP（First Meaningful Paint），不可采取。
2. 在引入 EditorXModule 且应用 ModalService 的模块里引入 ModalService —— 可取。仅有一种状况不太可取，就是调用 ModalService 的是另一个靠顶层的公共 Service，这样还是把不必要的模块放在了下层去加载。
3. 在触发应用 ModalService 的组件，注入以后模块的componentFactoryResolver，并传给 ModalService 的 open 函数参数 —— 可取，能够在真正应用的中央再引入 EditorXModule。
4. 在应用的模块里，手动提供一个 ModalService —— 可取，解决了注入搜寻的问题。

四种办法其实都是在解决 ModalService 所用的 componentFactoryResolver 的 injector 外部链式上有 EditorXModuleService 问题。保障在两层搜寻链上，这个问题就能够解决了。

知识点小结：模块注入器继承和查找范畴。

3.2 案例二：CdkVirtualScrollFor 找不到 CdkVirtualScrollViewport

通常咱们多个中央应用同一个模板的时候，会通过 template 提取公共局部，之前 DevUI Select 组件开发的时候开发者想将共用的局部抽取进去报错了。

图 7 代码移动和找不到注入报错

这里是因为 CdkVirtualScrollFor 指令须要注入一个 CdkVirtualScrollViewport，然而元素注入 injector 继承体系是继承动态 AST 关系的 DOM，动静的不行，所以产生以下查问行为，查找后报失败。

图 8 元素注入器查问链查找范畴

最初解法：：要么 1）放弃原代码地位不变，要么 2）须要把整个模板内嵌就能找到了。

图 9 内嵌整块模块使得能 CdkVitualScrollFo 能找到 CdkVirtualScrollViewport(解法二)

知识点小结：元素注入器的查问链条是动态模板的 DOM 元素先人。

3.3 案例三：表单校验的组件被封装到子组件内无奈校验问题

这个案例来自这篇博客《Angular: Nested template driven form》。

在应用表单校验的时候咱们也遇到了一样的问题。如图 10 所示，因为某些起因咱们把三个字段的地址封装成一个组件以供复用。

图 10 把表单的地址三个字段封装成一个子组件

这时候咱们会发现报错了，ngModelGroup须要一个 host 外部的ControlContainer，也就是 ngForm 指令提供的内容。

图 11 ngModelGroup 找不到 ControlContainer

查看 ngModelGroup 代码能够看到它只增加了 host 装璜器的限度。

图 12 ng_model_group.ts 限定了注入 ControlContainer 的范畴

这里能够应用 viewProvider 搭配 usingExisting 给 AddressComponent 的宿主视图减少 ControlContainer 的 Provider

图 13 应用 viewProviders 给嵌套组件提供内部的 Provider

知识点小结：viewProvider 和 usingExisting 搭配的妙用。

3.4 案例四：拖拽模块提供的 Service，因为懒加载，不是单例了，导致无奈相互拖拽

外部的业务平台有波及跨多个模块的拖拽，因为波及了 loadChildren 懒加载，每个模块会独自打包 DevUI 组件库的 DragDropModule，该 Module 提供了一个 DragDropService。拖拽指令分为可拖起指令 Draggable 和可搁置指令 Droppable，两个指令通过 DragDropService 进行通信。原本引入同一个模块应用模块提供的 Service 是能够通信的，然而懒加载后 DragDropModule 模块被打包了两次，也对应产生两份隔离的实例。这时候处于一个懒加载模块里的 Draggable 指令就无奈与另一个懒加载模块里的 Droppable 指令进行通信了，因为此时 DragDropService 并不是同个实例了。

图 14 懒加载模块导致服务不是同一实例 / 单例

这里显著咱们的述求是须要单例，而单例的做法通常就是 providerIn: 'root' 就好了，那么是不是就让组件库的 DragDropService 不要提供在模块级别，间接提供 root 界别的可好。然而细细想下来，这外面又会有其余的问题。组件库自身是提供给多种多样的业务应用的，万一有的业务在页面的两个中央别离有两组对应的拖拽并不想要联动起来。这时候单例反而就毁坏了这种基于模块的人造隔离。

那么要实现单例由业务侧来做替换会更正当。记得咱们后面提到的依赖查问链，元素的注入器是优先被查找的，找不到才开始找模块注入器。所以替换思路就是咱们提供元素级别的 provider 即可。

图 15 用扩大办法取得一个新的 DragDropService 并把它标记为在 root 级别提供

图 16 利用同个 selector 能够叠加反复指令，给组件库的 Draggable 指令和 Droppable 指令叠加一个额定的指令并把 DragDropService 的 token 替换成曾经在 root 提供单例的 DragDropGlobalService

如图 15 和 16，咱们通过元素注入器，叠加了指令，把 DragDropService 这个令牌替换成咱们本人的全局单例的实例。这时候须要应用这个全局单例的 DragDropService 的中央，咱们只须要引入申明并导出了这两个 extra 指令的模块就是使得组件库的 Draggable 指令 Droppable 指令可能跨懒加载模块进行通信了。

知识点小结：元素注入器优先级高于模块注入器。

3.5 案例五：部分主题性能场景怎么让下拉菜单附着在部分问题

DevUI 组件库的主题化是应用了 CSS 自定义属性（css 变量）申明:root 的 css 变量值从而实现了主题切换。如果咱们要在一个界面内同时展现不同主题的预览，咱们能够在 DOM 元素部分从新申明 css 变量从而达到部分主题的性能。之前在做主题仿色生成器的时候就用了这样一个方法来是部分利用一个主题。

图 17 部分主题性能

然而仅仅部分利用 css 变量值还不够，有一些下拉弹出层它是默认附着在 body 最初面的，也就是说它的附着层在局部变量的内部，这将会导致一个十分难堪的问题。部分主题的组件的下拉框下拉进去是内部的主题的款式。

图 18 部分主题内组件附着内部的叠加层下拉框主题不正确

这时候怎么办？咱们应该把附着点挪动回部分主题 dom 外部。

已知 DevUI 组件库的 DatePickerPro 组件的 Overlay 应用的是 Angular CDK 的 Overlay，通过一轮剖析咱们用注入替换如下：

1）首先咱们继承 OverlayContainer 并实现本人的 ElementOverlayContainer 如下图。

图 19 自定义 ElementOverlayContainer 并替换掉_createContainer 逻辑

2）而后在预览的组件侧，间接提供咱们新 ElementOverlayContainer，并提供新的 Overlay，以便新的 Overlay 能应用咱们的 OverlayContainer。本来 Overlay 和 OverlayContainer 都提供在 root 上，这里咱们须要笼罩这两个。

图 20 替换 OverlayContainer 为自定义的 ElementOverlayContainer，提供一个新的 Overlay

这时候再去预览网站，弹出层的 DOM 就顺利被附着到 component-preview 这个元素外面了。

图 21 cdk 的 Overlay 容器被附着到指定的 dom 外部，部分主题预览胜利

DevUI 组件库外部还有自定义的 OverlayContainerRef 用于局部组件和模态框抽屉板凳，也须要进行相应的替换。最终能实现弹窗弹出层等完满反对部分主题。

知识点小结：好的形象模式能够使得模块可替换，实现优雅的切面编程。

3.6 案例六：CdkOverlay 要求在滚动条中央加上 CdkScrollable 指令，但无奈给入口组件最外层加上该指令如何解决

到了最初一个案例，想讲一点不太正规的做法，以不便大家了解 provider 的实质，配置 provider 实质上就是让它帮你做实例化或者映射到某个存在的实例。

咱们晓得如果应用了 cdkOverlay，如果咱们想要弹出框追随滚动条滚动也能悬浮在正确的地位的话，咱们就须要给滚动条加上 cdkScrollable 的指令。

还是上一个例子的场景。咱们整个页面是通过路由加载进来的，贪图简便我把滚动条写在了组件的 host 了。

图 22 内容溢出滚动条把 overflow:auto 写在了组件:host 里

这样咱们就遇到了一个比拟难搞的问题，模块是 router 定义指定过去的，也就是没有任何中央显式地调用<app-theme-picker-customize></app-theme-picker-customize>，那 cdkScrollable 指令该怎么加进去呢？解法如下，这里暗藏掉了局部代码只留下外围代码。

图 23 通过注入创立实例并手动调用生命周期

这里通过注入生成了一个 cdkScrollable 的实例，并在组件的生命周期阶段同步地调用生命周期。

这种解法不是正规伎俩，但的确解决了问题，这里就作为一种思路和摸索留给读者品尝。

知识点小结：依赖注入配置提供商能够实现创立实例，但要留神实例将当做一般 Service 类看待，无奈领有用残缺生命周期。

3.7 更多玩法：自定义替换 platform，实现让 Angular 框架跑在 terminal 终端上的交互

能够参考这篇博文：《Rendering Angular applications in Terminal》

图 24 替换 RendererFactory2 渲染器等内容，让 Angular 运行在终端 terminal 上

作者通过替换 RendererFactory2 等渲染器，让 Angular 利用能够跑在终端 terminal 上。这就是 Angular 设计的灵便度，连 platform 都能够替换掉的弱小的灵便。具体的替换细节能够查看原文章，这里就不开展了。

知识点小结：依赖注入的弱小之处，在于提供商能够自行配置，最初实现替换逻辑。

4 总结

本文介绍了管制反转的依赖注入模式及其益处，介绍了 Angular 中依赖注入是如何查找依赖，如何配置提供商，如何用限定和过滤作用的装璜器拿到想要的实例，进一步通过 N 个案例剖析如何联合依赖注入的知识点来解决开发编程中会遇到的问题。

正确的了解依赖查找过程，咱们便能在精确的地位配置上提供商（案例一二），截胡替换其余实例为单例（案例四、五），甚至能跨嵌套组件包裹的限度连接上提供的实例（案例三）或者用提供的办法曲线实现指令实例化（案例六）。

其中案例五看似是简略的替换，然而要能写出能被替换的代码构造须要对注入模式有深刻的理解，并对各个性能有比拟好的正当的形象，形象不得当，就无奈施展依赖注入的最大效用了。注入模式为模块可插拔，插件化，整机化提供了更多可能的空间，升高耦合度，减少灵活性，是模块之间能更加优雅、协调地一起工作。

依赖注入性能的弱小，除了能实现优化组件通信门路，更重要的是还能实现管制反转，给封装好的组件裸露更多切面编程的切面，一些业务非凡逻辑的实现也能够变得灵便起来。

往期文章举荐

Angular CLI 下的自定义 Webpack 配置办法和自定义 loader 解决案例实际

Web 界面深色模式和主题化开发

20 行代码，给你的我的项目减少 DevUI 主题切换能力