本文由達觀數(shù)據(jù)研究院根據(jù)《Total Guide To Angular 6+ Dependency Injection?—?providedIn vs providers》編譯，如有不當(dāng)，還請指正。

?

Angular 6為我們提供了更好的語法——provideIn，用于將服務(wù)注冊到Angular依賴注入機制中。

接下來我們將會學(xué)習(xí)什么？

1. 依賴注入回顧（可選）

2. 使用舊語法進行依賴注入——?providers: []

3. 使用新語法進行依賴注入——?providedIn: 'root' | SomeModule

4. providedIn?的使用場景

5. 在項目中如何使用新語法的最佳實踐

6. 總結(jié)

依賴注入

讓我們快速回顧一下依賴注入是什么，如果感覺簡單，你可以跳過這一小節(jié)。

依賴注入（DI）是一種創(chuàng)建依賴其他對象的方法。在創(chuàng)建一個新的對象實例時，依賴注入系統(tǒng)將會提供依賴對象（稱為依賴關(guān)系） –?Angular Docs

我們的組件和服務(wù)都是類，每個類都有一個名為constructor的特殊函數(shù)，當(dāng)我們想要在我們的應(yīng)用程序中創(chuàng)建該類的對象（實例）時調(diào)用它。

在我們的服務(wù)中，我們都看到過類似于?constructor(private http: HttpClient)這樣的代碼。假如沒有Angular DI機制，我們必須手動提供HttpClient來創(chuàng)建我們自己的服務(wù)。

我們的代碼會像這樣：const myService = new MyService(httpClient);但是,我們還需要獲得httpClient對象。

于是，我需要再實例一個HttpClient:const httpClient = new HttpClient(httpHandler);但httpHandler又從哪來？如果這樣創(chuàng)建下去，到底什么時候是個頭。而且，這個過程相當(dāng)繁瑣，而且很容易出錯。

幸好，Angular 的DI機制自動地幫我們完成了上述的所有操作，我們所要做的只是在組件的構(gòu)造函數(shù)中指定依賴項，組件將會很輕松地就能用到這些依賴。可天下沒有免費的午餐…

使用舊語法進行依賴注入

為了讓工程實踐做的更好，Angular必須了解我們想要注入到組件和服務(wù)中的每一個實體。

在Angular 6 發(fā)布以前， 唯一的方法是在?providers: []?中指定服務(wù),如下：

根據(jù)具體使用場景，?providers: []?將有三種不同的用法：

1、在預(yù)加載的模塊的@NgModule裝飾器中指定?providers: []

2、在懶加載的模塊的@NgModule裝飾器中指定?providers: []

3、在@Component和@Directive裝飾器中指定?providers: []

在預(yù)加載模塊中使用providers: []

在這種情況下，服務(wù)將是全局單例的。即使它被多個模塊的providers: []重復(fù)申明，它也不會重新創(chuàng)建實例。注入器只會創(chuàng)建一個實例，這是因為它們最終都會注冊到根級注入器。

在懶加載模塊中使用providers: []

在應(yīng)用程序運行初始化后一段時間，懶加載模塊中提供的服務(wù)實例才會在子注入器（懶加載模塊）上創(chuàng)建。如果在預(yù)加載模塊中注入這些服務(wù)，將會報?No provider for MyService!?錯誤。

在@Component和@Directive中使用providers: []

服務(wù)是按組件實例化的，并且可以在組件及其子樹中的所有子組件中訪問。在這種情況下，服務(wù)不是單例的，每次我們在另一個組件的模板中使用組件時，我們都會獲得所提供服務(wù)的新實例。 這也意味著服務(wù)實例將與組件一起銷毀……

上面圖中，RandomService?在?RandomComponent中被注冊，因此，每當(dāng)我們在模板中使用<random> </ random>組件時，我們將得到不同的隨機數(shù)。

如果在模塊級別提供?RandomService并且將被作為單例提供，則不會出現(xiàn)這種情況。 在這種情況下，<random> </ random>?組件的每次使用都會顯示相同的隨機數(shù)，因為該數(shù)字是在服務(wù)實例化期間生成的。

使用新語法進行依賴注入

隨著Angular 6的出現(xiàn)，我們可以使用全新的語法在我們的應(yīng)用程序中建立依賴項， 官方名稱是“Tree-shakable providers”，我們通過使用?@Injectable?裝飾器的新增的?provideIn?屬性來使用它。

我們可以將provideIn視為以反向方式指定依賴關(guān)系。 現(xiàn)在不是模塊申明需要哪些服務(wù)，而是服務(wù)本身宣布它應(yīng)該提供給哪些模塊使用

申明的模塊可以是?root?或其他任何可用模塊。另外，root?實際上是?AppModule?的別名，這是一個很好的語法糖，我們因此不需要額外導(dǎo)入?AppModule。

新語法非常簡單，現(xiàn)在讓我們實踐一下，來探索在應(yīng)用程序開發(fā)過程中可能遇到的一些有趣場景……

使用?providedIn: 'root'

在大多數(shù)情況下，這是對我們有用的最常見的解決方案。此解決方案的主要好處是，只有真正“使用”這些服務(wù)時才會打包服務(wù)代碼。 “使用”代表注入某些組件或其他服務(wù)。

另一方面，providedIn: 'root'?在代碼可復(fù)用方面為開發(fā)人員帶來了巨大的積極影響。

在 `providedIn` 出現(xiàn)之前，需要在主模塊的 `providers: []` 中注入所有公共服務(wù)。然后，組件需要導(dǎo)入該模塊，這將導(dǎo)致所有（可能的大量）的服務(wù)導(dǎo)入進該組件，即使我們只想使用其中一個服務(wù)。

現(xiàn)在，providedIn: 'root'解決了這個問題，我們不需要在模塊中導(dǎo)入這些服務(wù)，我們要做的僅僅是使用它們。

懶加載?providedIn: 'root'?解決方案

如果我們在懶加載中使用?providedIn: 'root'?來實現(xiàn)服務(wù)會發(fā)生什么？

從技術(shù)上講，'root'代表?AppModule?，但Angular足夠聰明，如果該服務(wù)只是在惰性組件/服務(wù)中注入，那么它只會綁定在延遲加載的bundle中。

如果我們又額外將服務(wù)注入到其他正常加載的模塊中，那么該服務(wù)會自動綁定到?mian?的bundle中。

簡單來講：

1、如果服務(wù)僅被注入到懶加載模塊，它將捆綁在懶加載包中

2、如果服務(wù)又被注入到正常模塊中，它將捆綁在主包中

這種行為的問題在于，在擁有大量模塊和數(shù)百項服務(wù)的大型應(yīng)用程序中，它可能變得非常不可預(yù)測。

幸運的是，有一種方法可以防止這種情況的發(fā)生，我們將在下面的章節(jié)中探討如何加強模塊的邊界。

使用?providedIn: EagerlyImportedModule

這個解決方案通常沒有意義，我們應(yīng)該堅持使用?provideIn：'root'。

它可用于防止應(yīng)用程序的其余部分注入服務(wù)而無需導(dǎo)入相應(yīng)的模塊，但這其實并不是必需的。

附注 – 延遲加載模塊的多重好處

Angular最大的優(yōu)點之一是我們可以非常容易的將應(yīng)用程序分成完全獨立的邏輯塊，這有以下好處…

1、更小的初始化代碼，這意味著更快的加載和啟動時間

2、懶惰加載的模塊是真正隔離的。主機應(yīng)用程序應(yīng)該引用它們的唯一一點是某些路由的?loadChildren?屬性。

這意味著，如果使用正確，可以將整個模塊刪除或外部化為獨立的應(yīng)用程序/庫?？赡苡袛?shù)百個組件和服務(wù)的模塊可以在不影響應(yīng)用程序其余部分的情況下隨意移動，這是非常令人驚奇的！

這種隔離的另一個巨大好處是，對懶惰模塊的邏輯進行更改永遠不會導(dǎo)致應(yīng)用程序的其他部分出錯。

使用?providedIn: LazyLoadedModule

?

這個解決方案非常棒，因為它可以幫助我們防止在所需模塊之外使用我們的服務(wù)。在開發(fā)大型應(yīng)用程序時，保持依賴關(guān)系圖是非常有必要的，因為無約束的無處不在的注入可能會導(dǎo)致無法解決的巨大混亂！

不幸的是，有一個小問題……循環(huán)依賴

幸運的是，我們可以通過創(chuàng)建一個?LazyServiceModule?來避免這個問題，它將是?LazyModule?的一個子模塊，并將被用作我們想要提供的所有懶加載服務(wù)的“錨”。如下圖所示：

雖然有點不方便，但我們只需增加一個模塊，這種方法結(jié)合了兩者的優(yōu)點:

1. 它防止我們將懶加載的服務(wù)注入應(yīng)用程序的正常加載模塊
2. 只有當(dāng)服務(wù)被真正注入其他惰性組件時，它才會打包到服務(wù)中

新語法能在?@Component和?@Directive中使用嗎?

不，它們并不能。

我們?nèi)匀恍枰?@Component?或?@Directive?中使用?provider:[]來創(chuàng)建多個服務(wù)實例（每個組件）。 目前還沒有辦法解決這個問題……

最佳實踐

庫

當(dāng)處理開發(fā)庫、實用程序或任何其他形式的可重用 Angular 邏輯時，providedIn: 'root'是非常好的解決方案。

當(dāng)消費者應(yīng)用程序只需要可用庫功能的一個子集時，它也處理的非常好。只有真正使用的東西才會打包進我們的應(yīng)用程序中，我們都希望打包出來的文件越小越好。

懶加載模塊

使用?providedIn: LazyServicesModule，然后由?LazyModule?導(dǎo)入，再由 Angular 路由器惰性加載，以實施嚴(yán)格的模塊邊界和可維護的架構(gòu)！

這種方法可以防止我們將懶加載的服務(wù)注入應(yīng)用程序的正常加載模塊

使用providedIn: 'root'?,?'root'將會正常工作，服務(wù)也會被正確捆綁，但是使用?providedIn: LazyServiceModule?為我們提供了早期的“missing provider”錯誤，這是一個很好的早期信號，這有助于我們重新思考我們的架構(gòu)。

什么時候使用老的?providers:[]?語法？

我們需要將配置傳遞給我們的服務(wù)嗎？

或者換句話說，我們是否有一個使用?SomeModule.forRoot(someConfig)?解決的場景？

在這種情況下，我們?nèi)匀恍枰褂?providers: []，因為新的語法無助于我們定制服務(wù)。

另一方面，如果我們曾經(jīng)使用?SomeModule.forRoot()?來阻止延遲加載模塊創(chuàng)建服務(wù)的其他實例，我們可以簡單地使用?providedIn: 'root'?來實現(xiàn)這一點。

總結(jié)

1. 將?providedIn: 'root'用于在整個應(yīng)用程序中作為單例可用的服務(wù);

2. 永遠不要使用?providedIn:EagerLiymportedmodule，您不需要它，如果有一些非常特殊的用例，那么請使用?providers: []?來代替；

3. 使用?providedIn: LazyServiceModule來防止我們將懶加載的服務(wù)注入應(yīng)用程序的正常加載模塊;

4. 如果我們想使用?LazyServiceModule，那么我們必須將其導(dǎo)入?LazyModule，以防止循環(huán)依賴警告。然后，LazyModule將以標(biāo)準(zhǔn)方式使用 Angular Router 為某些路由進行懶加載。

5. 使用?@Component?或?@Directive?內(nèi)部的?providers: []，為特定的組件子樹提供服務(wù)，這也將導(dǎo)致創(chuàng)建多個服務(wù)實例(每個組件使用一個服務(wù)實例)

6. 始終嘗試保守地確定您的服務(wù)范圍，以防止依賴蔓延和由此產(chǎn)生的巨大混亂！