Хорошо, спасибо. Буду пока читать в области Injection Token (если правильно нагуглил) и Вашей идеи как таковой.

Добрый день.
Пытаюсь использовать Transloco v2.13.5.

this.translocoService.setActiveLang(language);

- не это ли переводит языки с одного на другой?
И есть ли проблемы Transloco с Material Angular?

ngx-translate юзай

по какой причине?

он точно работает)

Всем привет. У меня есть модуль CustomizationModule, который поддерживает конфигурирование через forRoot. В дев режиме или прод. режиме без AOT все работает прекрасно, но при компиляции с AOT.  Вопрос, как можно пофиксить ошибку при компиляции в прод режиме с включенной aot компиляцией

ERROR in src/app/private/private.module.ts(26,9): Error during template compile of 'PrivateModule'
  Function calls are not supported in decorators but 'CustomizationOptions' was called.
src/app/private/private.module.ts(26,9): Error during template compile of 'PrivateModule'
  Function calls are not supported in decorators but 'CustomizationOptions' was called.

Версия компилятора:     "@angular/compiler": "~8.2.14", @angular/cli": "~8.3.25"

Конфигурирующий модуль:

javascript
import { InjectionToken, ModuleWithProviders, NgModule } from '@angular/core';
import { CommonModule } from '@angular/common';

import { PrivateRoutingModule } from './private-routing.module';
import { HomeComponent } from './home.component';
import { NgZorroAntdModule } from 'ng-zorro-antd';
import { FormsModule } from '@angular/forms';
import { SharedModule } from '@app/shared/shared.module';
import { SegmentsModule } from '@private/segments/segments.module';
import { CustomizationModule } from '@private/customization/customization.module';
import { environment } from '@environments/environment';
import { CustomizationOptions } from '@private/customization/options/customization-options';

@NgModule({
  declarations: [
    HomeComponent,
  ],
  imports: [
    CommonModule,
    PrivateRoutingModule,
    NgZorroAntdModule,
    FormsModule,
    SharedModule,
    SegmentsModule,
    CustomizationModule.forRoot(environment.customizationOptions ?
    new CustomizationOptions(environment.customizationOptions) : new CustomizationOptions())
  ]
})
export class PrivateModule {

}

Конфигурируемый модуль:

javascript
@NgModule({
  declarations: [CustomizableHeaderComponent, CustomizableFooterComponent],
  exports: [
    CustomizableHeaderComponent,
    CustomizableFooterComponent
  ],
  imports: [
    CommonModule,
    SharedModule,
    NzLayoutModule
  ]
})
export class CustomizationModule {
  static forRoot(options) : ModuleWithProviders {
    return {
      ngModule: CustomizationModule,
      providers: [
        { provide: CustomizationOptionsToken, useValue: options, multi: true }
      ]
    };
  }
}

или возможно есть какой-то альтернативный способ динамического конфигурирования?

друзья знаю что все хоть один раз использовали материал дизайн․
что делать если на мобиле текст внутри <mat-hint>  станет 2 линия и дизайн взрывается․

Если будут вопросы, пишите, постарался комментариями передать зачем это все необходимо

// Возвращает только публичные свойства и методы
type WrapInterface<T> = { [P in keyof T]: T[P] };

// Имплементируем абстрактный класс, который будем использовать и реализовывать. Это отвязывает полностью нас от реализации сервиса из библиотеки, и мы совершенно не зависим от его реализации. Ниже это будет видно по тому, что мы сервис получаем из библиотеки.
abstract class BaseLocaleService implements WrapInterface<BsLocaleService> {
  abstract get locale(): BehaviorSubject<string>;

  abstract get localeChange(): Observable<string>;

  abstract get currentLocale(): string;

  abstract use(locale: string): void;
}

// Cобственная реализация, которая будет делать то, что нам надо. При этом реализуя абстракцию и получая сервис через DI она никак не зависит от реализации внешнего сервиса. А значит, если реализация изменится, то у нас ничего не сломается.
@Injectable()
class MyLocaleService extends BaseLocaleService {
  constructor(private ls: BaseLocaleService) {
    super();
    // Ниже этой строки в конструкторе имплементируем логику для установки локали, которая нужна:
    // if (isPlatformBrowser(...))
    //   { ... }
  }

  // Ниже реализуем абстракцию, делегируя вызовы другому сервису
  get locale(): BehaviorSubject<string> {
    return this.ls.locale;
  }

  get localeChange(): Observable<string> {
    return this.ls.localeChange;
  }

  get currentLocale(): string {
    return this.ls.currentLocale;
  }

  use(locale: string): void {
    return this.ls.use(locale);
  }
}

// и в модуле
providers: [
  // провайдим базовый класс, и по-умолчанию в нем будет класс из библиотеки
  { provide: BaseLocaleService, useClass: BsLocaleService },
  // провайдим собственный класс
  { provide: BsLocaleService, useClass: MyLocaleService }
]

// Возвращает только публичные свойства и методы
type WrapInterface<T> = { [P in keyof T]: T[P] };

// Имплементируем абстрактный класс, который будем использовать и реализовывать. Это отвязывает полностью нас от реализации сервиса из библиотеки, и мы совершенно не зависим от его реализации. Ниже это будет видно по тому, что мы сервис получаем из библиотеки.
abstract class BaseLocaleService implements WrapInterface<BsLocaleService> {
  abstract get locale(): BehaviorSubject<string>;

  abstract get localeChange(): Observable<string>;

  abstract get currentLocale(): string;

  abstract use(locale: string): void;
}

// Cобственная реализация, которая будет делать то, что нам надо. При этом реализуя абстракцию и получая сервис через DI она никак не зависит от реализации внешнего сервиса. А значит, если реализация изменится, то у нас ничего не сломается.
@Injectable()
class MyLocaleService extends BaseLocaleService {
  constructor(private ls: BaseLocaleService) {
    super();
    // Ниже этой строки в конструкторе имплементируем логику для установки локали, которая нужна:
    // if (isPlatformBrowser(...))
    //   { ... }
  }

  // Ниже реализуем абстракцию, делегируя вызовы другому сервису
  get locale(): BehaviorSubject<string> {
    return this.ls.locale;
  }

  get localeChange(): Observable<string> {
    return this.ls.localeChange;
  }

  get currentLocale(): string {
    return this.ls.currentLocale;
  }

  use(locale: string): void {
    return this.ls.use(locale);
  }
}

// и в модуле
providers: [
  // провайдим базовый класс, и по-умолчанию в нем будет класс из библиотеки
  { provide: BaseLocaleService, useClass: BsLocaleService },
  // провайдим собственный класс
  { provide: BsLocaleService, useClass: MyLocaleService }
]

а можно от меня вопрос

па че му
геттеры

// Возвращает только публичные свойства и методы
type WrapInterface<T> = { [P in keyof T]: T[P] };

// Имплементируем абстрактный класс, который будем использовать и реализовывать. Это отвязывает полностью нас от реализации сервиса из библиотеки, и мы совершенно не зависим от его реализации. Ниже это будет видно по тому, что мы сервис получаем из библиотеки.
abstract class BaseLocaleService implements WrapInterface<BsLocaleService> {
  abstract get locale(): BehaviorSubject<string>;

  abstract get localeChange(): Observable<string>;

  abstract get currentLocale(): string;

  abstract use(locale: string): void;
}

// Cобственная реализация, которая будет делать то, что нам надо. При этом реализуя абстракцию и получая сервис через DI она никак не зависит от реализации внешнего сервиса. А значит, если реализация изменится, то у нас ничего не сломается.
@Injectable()
class MyLocaleService extends BaseLocaleService {
  constructor(private ls: BaseLocaleService) {
    super();
    // Ниже этой строки в конструкторе имплементируем логику для установки локали, которая нужна:
    // if (isPlatformBrowser(...))
    //   { ... }
  }

  // Ниже реализуем абстракцию, делегируя вызовы другому сервису
  get locale(): BehaviorSubject<string> {
    return this.ls.locale;
  }

  get localeChange(): Observable<string> {
    return this.ls.localeChange;
  }

  get currentLocale(): string {
    return this.ls.currentLocale;
  }

  use(locale: string): void {
    return this.ls.use(locale);
  }
}

// и в модуле
providers: [
  // провайдим базовый класс, и по-умолчанию в нем будет класс из библиотеки
  { provide: BaseLocaleService, useClass: BsLocaleService },
  // провайдим собственный класс
  { provide: BsLocaleService, useClass: MyLocaleService }
]

Спасибо за пример с объяснениями. Всё очень хорошо расписано, но в моём случае это не совсем подошло, т.к. по видимому инстанция создаётся единожды, а мне эту логику нужно выполнять каждый раз, как создаётся компонент.  Даже, если я в компоненте это передам как провайдер, то он выполнится намного позже, чем нужно. Мне же критически важно, что бы эта логика выполнялась до отрисовки.

почему это критически важно?

именно каждый раз при создание компонента

похоже на костыль какой то

в каких случаях ngOnChanges нельзя заменить на сеттеры @Input’ов?

ни в каких

ngOnChanges же запускается при любом изменении любого инпута, верно? Получается, что заменив его на сеттеры, мы чуток ускорим приложение

не думаю

про какое ускорение речь ?