本篇文章帶大家深入了解Angular中的依賴注入模式，分享依賴注入模式的應(yīng)用和玩法案例，希望對大家有所幫助！

1 注入，一種組件樹狀層級通信模式 & 設(shè)計(jì)模式

1.1 組件通信模式

在Angular工程開發(fā)中，通常我們使用Input屬性綁定和Output事件綁定進(jìn)行組件通信，然而Input和Output卻只能在父子組件中傳遞信息。組件根據(jù)調(diào)用關(guān)系形成一棵組件樹，如果只有屬性綁定和事件綁定，那么兩個(gè)非直接關(guān)系組件要通信，需要通過各個(gè)連接點(diǎn)本身，中間人需要不斷處理和傳遞一些它本身不需要知道的信息（如圖1左）。而Angular中提供的Injectable的Service，可以在模塊、組件或者指令等提供，搭配在構(gòu)造函數(shù)的注入，正好能解決這個(gè)問題（圖1右）?！鞠嚓P(guān)教程推薦：《angular教程》】

圖1 組件通信模式

左圖只通過父子組件傳遞信息，節(jié)點(diǎn)a和節(jié)點(diǎn)b進(jìn)行通信就需要經(jīng)過諸多節(jié)點(diǎn)；如果節(jié)點(diǎn)c想要通過一些配置控制節(jié)點(diǎn)b，他們中間的節(jié)點(diǎn)也必須設(shè)置額外的屬性或者事件來透傳對應(yīng)的信息。右圖的依賴注入模式節(jié)點(diǎn)c可以提供一個(gè)供節(jié)點(diǎn)a、b通信的服務(wù)，節(jié)點(diǎn)a直接和節(jié)點(diǎn)c提供 服務(wù)通信，節(jié)點(diǎn)b也直接和節(jié)點(diǎn)c提供的服務(wù)通信，最后通信就被簡化了，中間節(jié)點(diǎn)也沒有耦合該部分內(nèi)容，對上下層組件發(fā)生的通信無明顯的感知。

1.2 使用依賴注入實(shí)現(xiàn)控制反轉(zhuǎn)

依賴注入（DI）并不是Angular特有的，它是實(shí)現(xiàn)控制反轉(zhuǎn)（IOC）設(shè)計(jì)模式的手段，依賴注入的出現(xiàn)解決手動實(shí)例化過分耦合的問題，所有資源不由使用資源的雙方管理，而由不使用資源資源中心或者第三方提供，這樣能帶來很多好處。第一，資源集中管理，實(shí)現(xiàn)資源的可配置和易管理。第二，降低了使用資源雙方的依賴程度，也就是我們說的耦合度。

類比現(xiàn)實(shí)世界就是，我們?nèi)ベ徺I商品比如一支鉛筆，我們只需要找個(gè)商店購買一支類型為鉛筆的商品，我們不關(guān)心這支鉛筆產(chǎn)地是哪里，木頭和鉛筆芯都是怎么粘合的，我們只需要它能完成鉛筆的書寫功能即可，我們不會和具體的鉛筆制造商或者工廠有聯(lián)系。而對于商店，它就可以自己去合適的渠道采購鉛筆，實(shí)現(xiàn)資源的可配置。

結(jié)合編碼場景，更具體的說，使用者不需要顯式創(chuàng)建實(shí)例（new操作），就能注入并使用實(shí)例，實(shí)例的創(chuàng)建由提供商(providers)決定。資源的管理是通過令牌（token），由于不關(guān)心提供商，不關(guān)心實(shí)例的創(chuàng)建，使用方就可以通過一些局部注入的手段（對token進(jìn)行二次配置），最終實(shí)現(xiàn)替換實(shí)例，依賴注入模式的應(yīng)用和切面編程（AOP）相輔相成。

2 Angular中的依賴注入

依賴注入是Angular框架最重要幾個(gè)的核心模塊之一，Angular不僅提供Service類型的注入，本身組件樹就是一顆注入依賴樹， 函數(shù)和值也可以被注入。也就是說在Angular框架中，子組件是可以通過父組件的token（通常為類名），注入父組件實(shí)例的。在組件庫開發(fā)中有大量案例是通過注入父組件，實(shí)現(xiàn)交互和通信的，包括參數(shù)掛載，狀態(tài)共享，甚至獲取父組件所在節(jié)點(diǎn)的DOM等等。

2.1 解析依賴

要使用Angular的注入，首先就要明白它的注入解析的過程。類似于node_modules的解析過程，當(dāng)找不到依賴都有找不到依賴會一直冒泡到父層去找依賴。舊版(v6前)的Angular會將注入解析的過程分為多級模塊注入器，多級組件注入器和元素注入器。新版（v9后）簡化為兩級模型，第一個(gè)查詢鏈?zhǔn)庆o態(tài)DOM層級的元素注入器、組件注入器等統(tǒng)稱為元素注入器，另一個(gè)查詢鏈?zhǔn)悄K注入器。解析的順序和解析失敗后的默認(rèn)值官方的這個(gè)代碼注釋文檔(provider_flag)里講的比較清楚了。

圖2 兩級注入器查找依賴過程 ( 圖片來源)

也就是說組件/指令以及在組件/指令層級提供注入內(nèi)容會優(yōu)先在組件視圖中元素里尋找依賴一直到根元素，如果沒有找到則接著在元素當(dāng)前所在模塊，引用（包含模塊引用和路由懶加載引用）該模塊的父級模塊一次往上找直到根模塊和平臺模塊。

注意這里注入器是有繼承的，元素注入器可以創(chuàng)建并繼承父元素的注入器的查找函數(shù)，模塊注入器也類似。當(dāng)不斷繼承之后，就有點(diǎn)像js對象的prototype鏈了。

2.2 配置提供商

明白了依賴解析的順序優(yōu)先級，我們就可以在合適的層級對內(nèi)容進(jìn)行提供。我們已經(jīng)知道它有兩種類型：模塊注入和元素注入。

• 模塊注入器：在@NgModule的元數(shù)據(jù)屬性里可以配置providers，還可以使用v6以后提供的@Injectable聲明provideIn聲明為模塊名、'root'等。（實(shí)際上在root根模塊之上還有兩個(gè)注入器，Platform和Null，這里不討論它們。）

• 元素注入器：在組件@Component的元數(shù)據(jù)屬性里可以配置providers，viewProviders， 或者在指令的@Directive元數(shù)據(jù)里的providers.

另外，實(shí)際上@Injectable裝飾器除了用了聲明模塊注入器外，也可以聲明為元素注入器。更經(jīng)常會將其聲明為在root提供，以實(shí)現(xiàn)單例。它通過類自己集成元數(shù)據(jù)來避免模塊或者組件直接顯式聲明provider，這樣如果該類沒有任何組件指令服務(wù)等類注入它，就沒有代碼鏈接到該類型聲明，就可以被編譯器忽略，從而實(shí)現(xiàn)了搖樹。

還有一種提供方法是聲明InjectionToken的時(shí)候直接給出值。

這里給出這幾種方式的速寫模板：

@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），服務(wù)隔離（module），多重編輯窗（component）等都有不同的適用方案，應(yīng)當(dāng)選擇合理的位置，避免共享的信息不當(dāng)，或者代碼打包的冗余。

2.3 多樣的值函數(shù)工具

如果只是提供實(shí)例的注入，那還顯示不出Angular框架依賴注入的靈活性。Angular提供了很多靈活的注入工具，useClass 自動創(chuàng)建新實(shí)例，useValue 使用靜態(tài)值， useExisting 可以復(fù)用已有的實(shí)例，useFactory 通過函數(shù)來構(gòu)造，搭配指定 deps 指定構(gòu)造函數(shù)參數(shù)，這些組合起來玩法可以非?；印？梢园肼方睾粋€(gè)類的token令牌替換成另一個(gè)自己準(zhǔn)備好的實(shí)例，可以造一個(gè)token先保存起來值或者實(shí)例，然后再在后面需要用到的時(shí)候重新替換回去，甚至可以用工廠函數(shù)返回實(shí)例的局部信息實(shí)現(xiàn)映射成另一個(gè)對象或者屬性值。這里的玩法會通過后面的案例進(jìn)行闡述，這里就先不展開。官網(wǎng)也有很多例子可以參考。

2.4 注入消費(fèi)和裝飾器

Angular中的注入可以在構(gòu)造函數(shù)constructor內(nèi)注入，也可以拿到注入器injector通過get方法獲取已有的注入元素。

Angular支持在注入的時(shí)候增加裝飾器進(jìn)行標(biāo)記，

• @Host() 來限制冒泡
• @Self() 限制為元素自身
• @SkipSelf() 限制為元素自身以上
• @Optional() 標(biāo)記為可選
• @Inject() 限制為自定義Token令牌

這里有一篇文章《@Self or @Optional @Host? The visual guide to Angular DI decorators.》非常生動形象地展示父子組件間如果使用了不同的裝飾器，最后會命中的實(shí)例有什么不同。

圖3 不同注入裝飾器的篩選結(jié)果

2.4.1 補(bǔ)充：宿主視圖和@Host

這幾個(gè)裝飾器里面，最不好理解的可能就是@Host了，這里補(bǔ)充一些@Host的具體說明。 官方對@Host裝飾器的解釋是

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

Host在這里是宿主的意思，@Host這個(gè)裝飾器將會限定查詢的范圍在宿主元素(host element)以內(nèi)。什么是宿主元素呢？假如B組件是A組件模板使用的組件，那么A組件實(shí)例就是B組件實(shí)例的宿主元素。組件模板產(chǎn)生的內(nèi)容稱為View（視圖），同一個(gè)View對于不同組件來說可能是不同視圖。如果A組件在自己的template范圍內(nèi)使用B組件（見圖4），A的模板內(nèi)容形成的視圖（紅框部分）對A組件來說就是A的內(nèi)嵌視圖，B組件在這個(gè)視圖內(nèi)，所以對B來說這個(gè)視圖就是B的宿主視圖。裝飾器@Host就是限定搜索范圍為宿主視圖之內(nèi)，找不到不會再進(jìn)行冒泡了。

圖4 內(nèi)嵌視圖和宿主視圖

3 案例和玩法

下面我們通過真實(shí)的案例，來看看依賴注入到底是怎么運(yùn)轉(zhuǎn)起來的，怎么排查錯(cuò)誤，以及還能怎么玩。

3.1 案例一： 模態(tài)窗創(chuàng)建動態(tài)組件，找不到組件問題

DevUI組件庫的模態(tài)窗組件提供了一個(gè)服務(wù)ModalService，該服務(wù)可以彈出一個(gè)模態(tài)框，而且可以配置為自定義的組件。業(yè)務(wù)的同學(xué)經(jīng)常在使用這個(gè)組件的時(shí)候報(bào)錯(cuò)，包找不到自定義的組件。

比如以下的報(bào)錯(cuò)：

圖5 使用ModalService的時(shí)候創(chuàng)建引用EditorX的組件的報(bào)錯(cuò)找不到對應(yīng)服務(wù)提供商

分析ModalService是如何創(chuàng)建自定義組件的，ModalService源碼Open函數(shù) 第52行和第95行。能看到，componentFactoryResolver如果沒有傳入就使用ModalService注入的componentFactoryResolver。而大多數(shù)情況下，業(yè)務(wù)會在根模塊引入一次DevUIModule，但是不會在當(dāng)前模塊里引入ModalModule。也就是現(xiàn)狀圖6是這樣的。根據(jù)圖6，ModalService的injector內(nèi)是沒有EditorXModuleService的。

圖6 模塊服務(wù)提供關(guān)系圖

根據(jù)注入器的繼承，解決辦法有四個(gè)：

• 把 EditorXModule 放到 ModalModule 聲明的地方，這樣注入器就能找到EditorXModule提供的EditorModuleService —— 這是最糟糕的一種解法，本身loadChildren實(shí)現(xiàn)的懶加載就是為了減少首頁模塊的加載，結(jié)果是子頁內(nèi)需要用到的內(nèi)容卻放在AppModule，首次加載就把富文本的大模塊給加載了，加重了FMP（First Meaningful Paint），不可采取。

• 在引入 EditorXModule 且使用 ModalService 的模塊里引入 ModalService —— 可取。僅有一種情況不太可取，就是調(diào)用 ModalService 的是另一個(gè)靠頂層的公共 Service，這樣還是把不必要的模塊放在了上層去加載。

• 在觸發(fā)使用ModalService的組件，注入當(dāng)前模塊的componentFactoryResolver，并傳給ModalService的open函數(shù)參數(shù) —— 可取， 可以在真正使用的地方再引入EditorXModule。

• 在使用的模塊里，手動提供一個(gè)ModalService —— 可取，解決了注入搜索的問題。

四種方法其實(shí)都是在解決 ModalService 所用的componentFactoryResolver的injector內(nèi)部鏈?zhǔn)缴嫌蠩ditorXModuleService問題。保證在兩層搜索鏈上，這個(gè)問題就可以解決了。

知識點(diǎn)小結(jié)：模塊注入器繼承和查找范圍。

3.2 案例二：CdkVirtualScrollFor找不到 CdkVirtualScrollViewport

通常我們多個(gè)地方使用同一個(gè)模板的時(shí)候，會通過 template 提取公共部分，之前 DevUI Select組件開發(fā)的時(shí)候開發(fā)者想將共用的部分抽取出來報(bào)錯(cuò)了。

圖7 代碼移動和找不到注入報(bào)錯(cuò)

這里是由于 CdkVirtualScrollFor指令需要注入一個(gè)CdkVirtualScrollViewport，然而元素注入injector繼承體系是繼承靜態(tài)AST關(guān)系的DOM，動態(tài)的不行，所以發(fā)生以下查詢行為，查找后報(bào)失敗。

圖8 元素注入器查詢鏈查找范圍

最后解法：：要么1）保持原代碼位置不變，要么2）需要把整個(gè)模板內(nèi)嵌就能找到了。

圖9 內(nèi)嵌整塊模塊使得能CdkVitualScrollFo能找到CdkVirtualScrollViewport(解法二)

知識點(diǎn)小結(jié)：元素注入器的查詢鏈條是靜態(tài)模板的DOM元素祖先。

3.3 案例三： 表單校驗(yàn)的組件被封裝到子組件內(nèi)無法校驗(yàn)問題

這個(gè)案例來自這篇博客《Angular: Nested template driven form》。

在使用表單校驗(yàn)的時(shí)候我們也遇到了一樣的問題。如圖10所示，由于某些原因我們把三個(gè)字段的地址封裝成一個(gè)組件以供復(fù)用。

圖10 把表單的地址三個(gè)字段封裝成一個(gè)子組件

這時(shí)候我們會發(fā)現(xiàn)報(bào)錯(cuò)了，ngModelGroup需要一個(gè)host內(nèi)部的ControlContainer，也就是ngForm指令提供的內(nèi)容。

圖11 ngModelGroup 找不到ControlContainer

查看ngModelGroup代碼可以看到它只添加了host裝飾器的限制。

圖12 ng_model_group.ts限定了注入ControlContainer的范圍

這里可以使用viewProvider搭配usingExisting給AddressComponent的宿主視圖增加ControlContainer的Provider

圖13 使用viewProviders給嵌套組件提供外部的Provider

知識點(diǎn)小結(jié)：viewProvider 和 usingExisting 搭配的妙用。

3.4 案例四：拖拽模塊提供的Service，由于懶加載，不是單例了，導(dǎo)致無法互相拖拽

內(nèi)部的業(yè)務(wù)平臺有涉及跨多個(gè)模塊的拖拽，由于涉及了loadChildren懶加載，每個(gè)模塊會單獨(dú)打包DevUI組件庫的DragDropModule，該Module提供了一個(gè)DragDropService。拖拽指令分為可拖起指令Draggable和可放置指令Droppable，兩個(gè)指令通過DragDropService進(jìn)行通信。 本來引入同一個(gè)模塊使用模塊提供的Service是可以通信的，但是懶加載后DragDropModule模塊被打包了兩次，也對應(yīng)產(chǎn)生兩份隔離的實(shí)例。這時(shí)候處于一個(gè)懶加載模塊里的Draggable指令就無法與另一個(gè)懶加載模塊里的Droppable指令進(jìn)行通信了，因?yàn)榇藭r(shí)DragDropService并不是同個(gè)實(shí)例了。

圖14 懶加載模塊導(dǎo)致服務(wù)不是同一實(shí)例/單例

這里明顯我們的述求是需要單例，而單例的做法通常就是providerIn: 'root'就好了，那么是不是就讓組件庫的DragDropService不要提供在模塊級別，直接提供root界別的可好。但是細(xì)細(xì)想下來，這里面又會有其他的問題。組件庫本身是提供給多種多樣的業(yè)務(wù)使用的，萬一有的業(yè)務(wù)在頁面的兩個(gè)地方分別有兩組對應(yīng)的拖拽并不想要聯(lián)動起來。這時(shí)候單例反而就破壞了這種基于模塊的天然隔離。

那么要實(shí)現(xiàn)單例由業(yè)務(wù)側(cè)來做替換會更合理。記得我們前面提到的依賴查詢鏈，元素的注入器是優(yōu)先被查找的，找不到才開始找模塊注入器。所以替換思路就是我們提供元素級別的provider即可。

圖15 用擴(kuò)展方法獲得一個(gè)新的DragDropService并把它標(biāo)記為在root級別提供

圖16 利用同個(gè)selector可以疊加重復(fù)指令，給組件庫的Draggable指令和Droppable指令疊加一個(gè)額外的指令并把DragDropService的token替換成已經(jīng)在root提供單例的DragDropGlobalService

如圖15和16， 我們通過元素注入器，疊加了指令，把DragDropService這個(gè)令牌替換成我們自己的全局單例的實(shí)例。這時(shí)候需要使用這個(gè)全局單例的DragDropService的地方，我們只需要引入聲明并導(dǎo)出了這兩個(gè)extra指令的模塊就是使得組件庫的Draggable指令Droppable指令能夠跨懶加載模塊進(jìn)行通信了。

知識點(diǎn)小結(jié)：元素注入器優(yōu)先級高于模塊注入器。

3.5 案例五： 局部主題功能場景怎么讓下拉菜單附著在局部問題

DevUI組件庫的主題化是使用了CSS自定義屬性（css變量）聲明:root的css變量值從而實(shí)現(xiàn)了主題切換。如果我們要在一個(gè)界面內(nèi)同時(shí)展示不同主題的預(yù)覽，我們可以在DOM元素局部重新聲明css變量從而達(dá)到局部主題的功能。之前在做主題仿色生成器的時(shí)候就用了這樣一個(gè)辦法來是局部應(yīng)用一個(gè)主題。

圖17 局部主題功能

但是僅僅局部應(yīng)用css變量值還不夠，有一些下拉彈出層它是默認(rèn)附著在body最后面的，也就是說它的附著層在局部變量的外部，這將會導(dǎo)致一個(gè)非常尷尬的問題。局部主題的組件的下拉框下拉出來是外部的主題的樣式。

圖18 局部主題內(nèi)組件附著外部的疊加層下拉框主題不正確

這時(shí)候怎么辦？我們應(yīng)該把附著點(diǎn)移動回局部主題dom內(nèi)部。

已知DevUI組件庫的DatePickerPro組件的Overlay使用的是Angular CDK的Overlay，經(jīng)過一輪分析我們用注入替換如下：

1）首先我們繼承OverlayContainer并實(shí)現(xiàn)自己的ElementOverlayContainer如下圖。

圖19 自定義ElementOverlayContainer并替換掉_createContainer邏輯

2）然后在預(yù)覽的組件側(cè)，直接提供我們新ElementOverlayContainer，并提供新的Overlay，以便新的Overlay能使用我們的OverlayContainer。原本Overlay和OverlayContainer都提供在root上，這里我們需要覆蓋這兩個(gè)。

圖20 替換OverlayContainer為自定義的ElementOverlayContainer，提供一個(gè)新的Overlay

這時(shí)候再去預(yù)覽網(wǎng)站，彈出層的DOM就順利被附著到component-preview這個(gè)元素里面了。

圖21 cdk的Overlay容器被附著到指定的dom內(nèi)部， 局部主題預(yù)覽成功

DevUI組件庫內(nèi)部還有自定義的OverlayContainerRef用于部分組件和模態(tài)框抽屜板凳，也需要進(jìn)行相應(yīng)的替換。最終能實(shí)現(xiàn)彈窗彈出層等完美支持局部主題。

知識點(diǎn)小結(jié)：好的抽象模式可以使得模塊可替換，實(shí)現(xiàn)優(yōu)雅的切面編程。

3.6 案例六： CdkOverlay要求在滾動條地方加上CdkScrollable指令，但無法給入口組件最外層加上該指令如何處理

到了最后一個(gè)案例，想講一點(diǎn)不太正規(guī)的做法，以方便大家理解provider的本質(zhì)，配置provider本質(zhì)上就是讓它幫你做實(shí)例化或者映射到某個(gè)存在的實(shí)例。

我們知道如果使用了cdkOverlay，如果我們想要彈出框跟隨滾動條滾動也能懸浮在正確的位置的話，我們就需要給滾動條加上cdkScrollable的指令。

還是上一個(gè)例子的場景。我們整個(gè)頁面是通過路由加載進(jìn)來的，貪圖簡便我把滾動條寫在了組件的host了。

圖22 內(nèi)容溢出滾動條把overflow:auto 寫在了組件:host里

這樣我們就遇到了一個(gè)比較難搞的問題，模塊是router定義指定過來的，也就是沒有任何地方顯式地調(diào)用<app-theme-picker-customize></app-theme-picker-customize>，那cdkScrollable指令該怎么加進(jìn)去呢？解法如下，這里隱藏掉了部分代碼只留下核心代碼。

圖23 通過注入創(chuàng)建實(shí)例并手動調(diào)用生命周期

這里通過注入生成了一個(gè)cdkScrollable的實(shí)例，并在組件的生命周期階段同步地調(diào)用生命周期。

這種解法不是正規(guī)手段，但確實(shí)解決了問題，這里就作為一種思路和探索留給讀者品味。

知識點(diǎn)小結(jié)： 依賴注入配置提供商可以實(shí)現(xiàn)創(chuàng)建實(shí)例，但要注意實(shí)例將當(dāng)做普通Service類對待，無法擁有用完整生命周期。

3.7