Я только что попробовал один подход, который, кажется, работает:
- Объявите соответствующую фабрику обслуживания в ваших
environment.{env}.ts
файлах - Используйте фабрику среды в качестве поставщика услуг
Моя тестовая установка:
базовый класс
@Injectable()
export abstract class TestService {
abstract environment: string;
}
служба разработки
@Injectable()
export class DevTestService extends TestService {
environment = 'qwertydev';
}
сервисное обслуживание
@Injectable()
export class ProdTestService extends TestService {
environment = 'qwertyprod';
}
environment.ts
export const environment = {
testServiceFactory: () => new DevTestService()
};
environment.production.ts
export const environment = {
testServiceFactory: () => new ProdTestService()
};
app.module.ts
providers: [
{ provide: TestService, useFactory: environment.testServiceFactory }
],
app.component.ts
constructor(private testService: TestService) {}
ngOnInit() {
console.log(this.testService.get());
}
Когда я проверяю свой файлы сборки, я нахожу только qwertydev
в сборке dev и qwertprod
в сборке prod, что говорит о том, что они были потрясены деревом.
Я использовал строки qwerty*
, чтобы упростить его. поиск файлов сборки после минимизации.
Объявление сервисов в модуле
Я объявил провайдера в модуле, чтобы избежать циклических ссылок. Циркулярную ссылку легко ввести, объявив службу как providedIn: Module
.
Вы можете обойти эту проблему, объявив сторонний модуль, но это кажется излишним.
Я продемонстрировал это в более старом ответе: @ Injectable () массив декоратора и провайдеров
Альтернативные подходы
Это не вполне чувствовать себя правильно, объявляя фабрики обслуживания в файлах среды Я сделал это для тестирования просто для простоты. Вы можете создать свой собственный набор c файлов, специфичных для среды, которые перезаписываются во время сборки так же, как файлы среды, но, откровенно говоря, это звучит как кошмар обслуживания.