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 模块服务提供关系图
依据注入器的继承，解决办法有四个：
- 把 EditorXModule 放到 ModalModule 申明的中央，这样注入器就能找到EditorXModule提供的EditorModuleService —— 这是最蹩脚的一种解法，自身loadChildren实现的懒加载就是为了缩小首页模块的加载，后果是子页内须要用到的内容却放在AppModule，首次加载就把富文本的大模块给加载了，减轻了FMP（First Meaningful Paint），不可采取。
- 在引入 EditorXModule 且应用 ModalService 的模块里引入 ModalService —— 可取。仅有一种状况不太可取，就是调用 ModalService 的是另一个靠顶层的公共 Service，这样还是把不必要的模块放在了下层去加载。
- 在触发应用ModalService的组件，注入以后模块的
componentFactoryResolver，并传给ModalService的open函数参数 —— 可取， 能够在真正应用的中央再引入EditorXModule。 - 在应用的模块里，手动提供一个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 主题切换能力