Angular 4 依賴注入教程之四 FactoryProvider的使用typescript
Angular 4 依賴注入教程之七 ValueProvider的使用bootstrap
Angular 4 依賴注入教程之八 InjectToken的使用segmentfault
本系列教程的開發環境及開發語言:api
OpaqueToken
用於建立可在 Provider
中使用的 Token
。
export class OpaqueToken { constructor(protected _desc: string) {} toString(): string { return `Token ${this._desc}`; } }
import { ReflectiveInjector } from '@angular/core'; var t = new OpaqueToken("value"); var injector = ReflectiveInjector.resolveAndCreate([ {provide: t, useValue: "bindingValue"} ]); injector.get(t); // "bindingValue"
InjectionToken
用於建立可在 Provider
中使用的 Token
。
export class InjectionToken<T> extends OpaqueToken { private _differentiate_from_OpaqueToken_structurally: any; constructor(desc: string) { super(desc); } toString(): string { return `InjectionToken ${this._desc}`; } }
import { ReflectiveInjector } from '@angular/core'; var t = new InjectionToken<string>("value"); var injector = ReflectiveInjector.resolveAndCreate([ {provide: t, useValue: "bindingValue"} ]); injector.get(t); // "bindingValue"
在介紹 InjectionToken
相關內容以前,咱們先回顧一下 "ValueProvider的使用" 這篇中咱們介紹的內容:
@NgModule({ ..., providers: [ { provide: 'apiUrl', useValue: 'http://localhost:4200/heros' } ], bootstrap: [AppComponent] }) export class AppModule { }
@Injectable() export class HeroService { constructor(private loggerService: LoggerService, private http: Http, @Inject('apiUrl') private apiUrl) { } getHeros(): Observable<Array<{ id: number; name: string }>> { this.loggerService.log('Fetching heros...'); return this.http.get(this.apiUrl) .map(res => res.json()) } }
爲了可以更方便地管理與維護 apiUrl
地址,咱們利用了 ValueProvider
和 Inject
裝飾器。一切看起來很是順利,但某一天假設咱們引入了一個第三方庫 - third-lib.ts
,該文件的內容以下所示:
export const THIRD_PARTY_PROVIDERS = [ { provide: 'apiUrl', useValue: 'Other Url' } ];
接着咱們在 AppModule
中配置對應的 Provider
信息,具體以下:
import { THIRD_PARTY_PROVIDERS } from './third-party'; @NgModule({ ..., providers: [ { provide: 'apiUrl', useValue: 'http://localhost:4200/heros' }, THIRD_PARTY_PROVIDERS ], bootstrap: [AppComponent] }) export class AppModule { }
當更新完上述代碼,成功保存後,你會發現 http://localhost:4200/
頁面,又是空空如也了。這時若是咱們打開開發者工具,切換到 Console
面板你會看到以下異常信息:
GET http://localhost:4200/Other%20value 404 (Not Found)
什麼狀況,咱們的英雄信息的接口地址被替換了,其實真正的緣由是使用字符串做爲 Token
引發衝突了。那麼怎麼解決呢?最簡單的方式是對調一下 ValueProvider
與 THIRD_PARTY_PROVIDERS
的位置。你會發如今 http://localhost:4200/
頁面,你又能看到英雄信息。固然這不能解決本質問題,由於這樣會致使你引入的第三方庫不能正常工做。
相信不少讀者已經習慣了個人 "套路",固然要讓咱們的主角 - InjectionToken
出馬,來解決這個問題咯。爲了統一管理應用中的 Token
信息 ,咱們新建一個 app.tokens.ts
文件來保存應用中的 Token
信息。該文件的具體內容以下:
import { InjectionToken } from '@angular/core'; export const API_URL = new InjectionToken<string>('apiUrl');
接下來咱們在更新一下 AppModule
:
import { API_URL } from './app.tokens'; @NgModule({ ..., providers: [ { provide: API_URL, useValue: 'http://localhost:4200/heros' }, THIRD_PARTY_PROVIDERS ], bootstrap: [AppComponent] }) export class AppModule { }
而後在更新 HeroService
服務,具體更新內容以下:
import { API_URL } from './app.tokens'; @Injectable() export class HeroService { constructor(private loggerService: LoggerService, private http: Http, @Inject(API_URL) private apiUrl) { } }
當更新完上述代碼,成功保存後,你會發現 http://localhost:4200/
頁面,又能正常顯示英雄信息了。問題已經解決了,但其實這是由於咱們使用了不一樣的 Token
。咱們再來驗證一個問題:
import { InjectionToken } from '@angular/core'; const API_URL = new InjectionToken<string>('apiUrl'); export const THIRD_PARTY_PROVIDERS = [ { provide: API_URL, useValue: 'Other value' } ];
你會發現更新完 third-lib.ts
庫,且成功保存後,在 http://localhost:4200/
頁面,仍是能正常顯示英雄信息。此時,咱們的 Angular 4
依賴注入教程已經結束了,但其實本教程只介紹了 Angular
依賴注入的部分知識。若是讀者有興趣的話,能夠繼續瞭解如下的內容:
涉及 useClass、useValue、useExisting、useFactory 及 Provider 使用方式。
涉及 multi provider 做用及 Angular 4.x 內部應用。
涉及 forwardRef 的做用及內部工做原理,同時解釋 JavaScript 解釋器不能自動提高 Class。
Angular 4.x OpaqueToken & InjectionToken
涉及使用字符串做爲 Token存在問題,詳細介紹如何使用 OpaqueToken、InjectionToken 解決問題。
涉及 IoC 和 DI、DI 在 AngularJS 1.x 中的應用、內部工做原理及存在的問題等。
涉及依賴注入的概念及Angular 4.x 注入器的內部實現 (慎入)。
Angular Element Injector
還沒有完成,敬請期待
它們都是用於建立可在 Provider
中使用的 Token
。
OpaqueToken
是 Angular
2.x 版本中引入的類。
InjectionToken
是在 Angular
4.x 版本中引入的類,該類繼承於 OpaqueToken
,且引入了泛型用於定義所關聯的依賴對象的類型。
內部緩存:AngularJS 1.x 應用程序中全部的依賴項都是單例,咱們不能靈活地控制是否使用新的實例。
命名空間衝突: 在系統中咱們使用字符串來標識服務 (Service) 的名稱,假設咱們在項目中已有一個 CarService
,然而第三方庫中也引入了一樣的服務,這樣的話就容易出現衝突。
DI 耦合度過高: AngularJS 1.x 中 DI 功能已經被框架集成了,咱們不能單獨使用它的依賴注入功能。
未能和模塊加載器結合: 在瀏覽器環境中,不少場景都是異步的過程,咱們須要的依賴模塊並非一開始就加載好的,或許咱們在建立的時候纔會去加載依賴模塊,再進行依賴建立,而 AngularJS 1.x 的 DI 系統無法作到這點。