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 系统无法作到这点。