¿Cuál es la forma mejor/adecuada de importar un servicio basado en el entorno actual dentro de un proyecto angular-cli?
He configurado un nuevo entorno llamado dev-mock al que puedo llamar con...
ng serve --environment=mockLuego configuré el proveedor en el módulo con useClass
aplicación/aplicación.módulo.ts ...
import {environment} from '../environments/environment'; import {ApiService} from './api/api.service'; import {MockApiService} from './api/mock/mock-api.service'; @NgModule({ declarations: [ AppComponent, ], imports: [ BrowserModule, FormsModule, HttpModule ], providers: [ { provide: ApiService, useClass: (environment.name === 'dev-mock') ? MockApiService : ApiService } ], bootstrap: [AppComponent] })Esto funciona bien, el problema entonces es qué hago cuando quiero inyectar eso en otro servicio o componente, por ejemplo...
app/ticket/ticket.service.ts
import {ApiService} from '../api/api.service'; // *** WHAT AM I TO DO HERE? *** @Injectable() export class TicketService { constructor(private api: ApiService, private http: Http) { } }Obviamente mi enfoque es incorrecto. ¿Cuál es el enfoque correcto?
Cree una interfaz para MockApiService y ApiService, por ejemplo. Servicio IApi. Si quieres intercambiarlos tiene que haber uno.
Cree un archivo con token y expórtelo:
import { OpaqueToken } from '@angular/core'; export let API_SERVICE = new OpaqueToken('api.service');Luego registre su servicio en algún lugar usando el token:
const apiServiceClass = (environment.name === 'dev-mock') ? MockApiService : ApiService; providers: [{ provide: API_SERVICE, useClass: apiServiceClass }]Finalmente, puede usarlo en cualquier lugar usando el decorador Inject () aplicado en el constructor, por ejemplo.
import {IApiService} from '../api/iapi.service'; import { Inject, Injectable } from '@angular/core'; @Injectable() export class TicketService { constructor(@Inject(API_SERVICE) private api: IApiService) {} }El truco es usar la interfaz como tipo de propiedad y usar Inject() con OpaqueToken para decirle al inyector de dependencias lo que debe poner.
En mis bibliotecas, estoy usando una clase de entorno abstracta que define variables de entorno comunes.
export abstract class Environment { abstract readonly production: boolean; abstract readonly appUrls: { readonly public: string; readonly portal: string; readonly admin: string; }; }Luego cambié los archivos environment.ts para que sean los siguientes.
import { Environment } from '@my-lib-prefix/common'; class EnvironmentImpl implements Environment { production = false; appUrls = { public: 'http://localhost:4200', portal: 'http://localhost:4201', admin: 'http://localhost:4202' }; } export const environment = new EnvironmentImpl();El environment.prod.ts sería, por supuesto, simétrico al dev environment.ts. Luego proporciono la dependencia del entorno respectivo, en la raíz app.module.ts para cada una de las aplicaciones de Angular.
import { BrowserModule } from '@angular/platform-browser'; import { NgModule } from '@angular/core'; import { AppComponent } from './app.component'; import { Environment } from '@my-lib-prefix/common'; import { environment } from '../environments/environment'; @NgModule({ declarations: [AppComponent], imports: [BrowserModule], providers: [{ provide: Environment, useValue: environment }], bootstrap: [AppComponent] }) export class AppModule {}Ahora cualquier componente puede inyectar dependencias del entorno de una manera limpia y común.
import { Component } from '@angular/core'; import { Environment } from '@my-lib-prefix/common'; @Component({ selector: 'my-login', templateUrl: './my-login.component.html' }) export class MyLoginComponent { constructor(private env: Environment) {} }Hace cumplir cada environment.ts para implementar las variables de entorno "comunes" definidas en la clase abstracta. Además, cada EnvironmentImpl respectivo se puede ampliar con sus propias variables de entorno específicas específicas de la aplicación. Este enfoque parece muy flexible y limpio. ¡Salud!