Привет! В этой заметке покажу, как можно использовать функцию inject на сто процентов.

Обычно ведь как: если функцией inject и пользуются, то только для того, чтобы заменить инжект через конструктор. Было:

@Injectable()
export class SomeService {
  constructor(protected readonly duckService: DuckService) {}
  // ...
}

И стало:

@Injectable()
export class SomeService {
  protected readonly duckService = inject(DuckService);
  // ...
}

Удобно, конечно. Особенно тем, что от SomeService теперь легче наследоваться: не нужно в дочернем классе перечислять токены, а затем через super передавать их родителю. Кстати, по этой же причине я почти всегда объявляю сервисы через protected, чтобы ими можно было легко пользоваться в дочерних классах.

Но что, если я скажу, что это не всё, на что способна функция inject? Давайте посмотрим на паре примеров, как ещё её можно использовать.

Оборачиваем inject

Вы замечали, что с query-параметрами работать немного заморочено? Ну то есть: нам сначала надо заинжектить ActivatedRoute, чтобы получить данные о каком-то параметре:

private readonly route: ActivatedRoute = inject(ActivatedRoute);

Потом вытащить из него queryParams, а оттуда смапить объект на нужный нам параметр:

private readonly id$: Observable<string> = 
  this.route.queryParams.pipe(map(({ id }) => id))

А если мы захотим параметр обновить, то нам придётся инжектить роутер:

private readonly router: Router = inject(Router);

И вспоминать его синтаксис, а потом не забыть выставить режим merge для query-параметров (иначе все остальные параметры испарятся):

this.router.navigate(
  [], 
  { queryParams: { id }, queryParamsHandling: 'merge' }
)

А если мы захотим считать параметр синхронно, а не через Observable, то придётся отдельно обращаться к снапшоту:

const id: string = this.route.snapshot.queryParams.id;

Если нам нужно будет поменять название параметра, то нам нужно будет пробежаться по трём местам; и не забываем, что queryParams не типизирован, и TS нас тут в случае ошибки не спасёт.

Вам не кажется, что это всё сильно похоже на работу BehaviorSubject? Этот тот самый, на который можно подписаться, через который можно обновить значение и синхронно получить последнее. Что, если весь этот распылённый код собрать воедино, и управлять пресловутым query-параметром через одну точку входа?

Ну как-нибудь вот так:

@Component({ /* ... */ })
export class SomeComponent {
  protected readonly id$: QueryParam<string> = useQueryParam('id');
  public readonly entity$: Observable<SomeEntity> = this.id$.pipe(
    switchMap(/* ... */)
  );

  public updateForm(): void {
    const id: string = this.id$.getValue();
    // ...
  }

  public changeEntity(id: string): void {
    this.id$.update(id);
  }
}

Здесь нет ни Router, ни ActivatedRoute. Ведь всё, что нам нужно — это query-параметр, и у нас теперь есть объект, через который мы можем управлять этим параметром и получать о нём информацию. Можно ли так сделать? Можно! В этом нам как раз поможет функция inject.

У функции inject есть важный нюанс: ей необязательно пользоваться именно в конструкторе – это можно делать и в отдельной функции, которая к компоненту никак не относится. Главное, чтобы при вызове этой функции мы находились в injection-контексте, в противном случае Angular выкинет ошибку.

Мы находимся в injection-контексте на протяжении работы конструктора injectable-класса (и ещё в некоторых случаях, но они нам пока не интересны). Если во время работы конструктора мы вызовем функцию useQueryParam (как в примере выше), то она тоже будет находиться в контексте, а значит пользоваться функцией inject можно и там.

Таки давайте напишем функцию, которая будет создавать этот магический объект QueryParam. Для начала создадим сам класс, который унаследует Observable. Мы переносим в этот класс всю логику работы с роутером и активным роутом, поэтому передадим их через конструктор. Также нам понадобится ключ query-параметра, с которым мы будем работать — это строка, тоже передадим её через конструктор.

export class QueryParam<T> extends Observable<T> {
  constructor(
    private readonly paramKey: string,
    private readonly activatedRoute: ActivatedRoute,
    private readonly router: Router
  ) {}
}

Итак, этот класс в первую очередь Observable, а значит, при подписке мы должны получать значения этого query-параметра. Свяжем наш класс со значением параметра вот таким образом:

export class QueryParam<T> extends Observable<T> {
  // заведём поток для получения значений из query-параметра
  private readonly paramValue$ = this.activatedRoute.queryParams.pipe(
    distinctUntilKeyChanged(this.paramKey), // отсеиваем одинаковые значения
    map(() => this.getValue()), // достаём из словаря с параметрами нужный
    share({
      connector: () => new BehaviorSubject(this.getValue()),
      resetOnRefCountZero: true,
    }) // зашейрим это значение, 
    // чтобы новый подписчик не инициировал каждый раз вызов getValue()
  );

  constructor(
    private readonly paramKey,
    private readonly activatedRoute: ActivatedRoute,
    private readonly router: Router
  ) {
    super((subscriber) => {
      // каждый новый подписчик будет проксироваться в наш paramValue$
      const subscription = this.paramValue$.subscribe(subscriber);

      // при отписке от нашего Observable разрываем прокси
      return () => subscription.unsubscribe(); 
    });
  }

  public getValue(): T {
    return this.activatedRoute.snapshot.queryParams[this.paramKey];
  }
}

Теперь у нас есть возможность получать значение по подписке и синхронно через функцию getValue. Осталось сделать возможность обновить значение. Добавим функцию update, которая будет пользоваться полем router и обновлять значение прямо в адресной строке.

export class QueryParam<T> extends Observable<T> {
  private readonly paramValue$; // = ...

  costructor(/* ... */) {
    // ...
  };

  public getValue(): T {
	  // ...
  }
  
  public update(value: T): Promise<boolean> {
    return this.router.navigate([], {
      queryParams: { [this.paramKey]: value },
      queryParamsHandling: 'merge',
    });
  }
}

И теперь самое главное: напишем функцию-фабрику, которая будет генерировать нам такой объект:

export function useQueryParam<T>(paramKey: string): QueryParam<T> {
  return new QueryParam(paramKey, inject(ActivatedRoute), inject(Router));
}

Обращаем внимание, что в неё требуется передать только ключ параметра, остальное (роутер и роут) функция добудет сама через функцию inject. Чтобы посмотреть, как этим пользоваться, ещё раз взглянем на продемострированный выше пример:

@Component({ /* ... */ })
export class SomeComponent {
	protected readonly id$: QueryParam<string> = useQueryParam('id');
	//                                                        ~~~~~~
	// нам достаточно передать только ключ параметра, и уже можно пользоваться
	
	public readonly entity$: Observable<SomeEntity> = this.id$.pipe(
	  switchMap(/* ... */)
	);

	public updateForm(): void {
	  const id: string = this.id$.getValue();
	  // ...
	}
	
	public changeEntity(id: string): void {
	  this.id$.update(id);
	}
}

Очевидно, что в такой же манере можно организовать работу и с path-параметрами. Здесь можно поиграться в StackBlitz.

Заменяем stateless-сервисы

Давайте разберём ещё один пример, где функция inject поможет избавиться от одного неудобства. На этот раз будем говорить про модальные окна. Откроем раздел Overview в документации по MatDialog и немного отредактируем его первый пример.

Там ничего особенного: просто кнопка, которая открывает модальное окно и передаёт туда информацию. Модальное окно, как мы знаем, открывается с помощью сервиса MatDialog, который всегда запровайжен в root.

А теперь давайте создадим некоторый сервис, который нужно запровайдить в компонент с кнопкой. Например такой:

@Injectable()
export class SomeService {
  a = 'hello';
}

Провайдим в компонент:

@Component({
	// ...
  providers: [SomeService] // <-- вот так
})
export class DialogOverviewExample {
  // ...
}

Это значит, что на каждый экземпляр компонента будет создаваться свой экземпляр SomeService. Проверим, что им можно пользоваться:

export class DialogOverviewExample {
  // ...
  constructor(public dialog: MatDialog, public someService: SomeService) {
	  console.log(this.someService.a);
  }
  // ...
}

Работает. Ну впрочем, мы ничего сверъестественного и не сделали.

Теперь попробуем им воспользоваться внутри компонента модального окна:

export class DialogOverviewExampleDialog {
  constructor(
    public dialogRef: MatDialogRef<DialogOverviewExampleDialog>,
    @Inject(MAT_DIALOG_DATA) public data: DialogData,
    public someService: SomeService // <-- инжектим
  ) {
    console.log(this.someService.a); // <-- пользуемся
  }
}

Если вы хорошо знаете, как работает дерево DI, то уже поняли, какая ошибка будет выведена при открытии модального окна. Удостоверимся: нажмём на кнопку. Получим классический NullInjectorError. Модалка, понятное дело, не откроется. У некоторых вкатывающихся в Angular должны начаться флэшбэки.

Почему так? Почему в компоненте DialogOverviewExample мы можем пользоваться этим сервисом, а в компоненте DialogOverviewExampleDialog уже нет? Мы ведь его запровайдили в компоненте, и из него же вызвали модальное окно.

Давайте нарисуем дерево провайдеров.

Вот так оно выглядит до открытия модального окна: MatDialog, как и положено, находится в инжекторе root. От него наследуется инжектор под названием DialogOverviewExample (наследование показано стрелочкой). Внутри него есть сам компонент DialogOverviewExample и тот самый несчастный SomeService.

Что произойдёт, когда мы откроем модальное окно? Смотрим:

У нас добавился новый инжектор под названием DialogOverviewExampleDialog. Он уже относится к компоненту модалки. Стрелкой снова показано наследование, а пунктирной линией я показал, что этот инжектор был создан именно сервисом MatDialog.

Как видим, действительно, сервису SomeService в этой модалке взяться просто неоткуда: у него в арсенале есть собственный инжектор и родительский, и нигде нужного сервиса нет.

Что делать? Есть несколько вариантов.

Вариант 1

Перенести SomeService в root. Решило бы проблему, но нельзя, потому что нам нужен не синглтон, а свой экземпляр на каждый экземпляр компонента. Ну вот по бизнесу так надо. Не подходит.

Вариант 2

Перенести MatDialog внутрь инжектора DialogOverviewExample. Тогда модальное окно унаследуется уже от него, и сервис будет доступен. Создать лишний экземпляр сервиса мы можем, так как мы там не храним никаких данных, нам от него нужна лишь функция.

Это уже можно, и это решит проблему. Указываем MatDialog в списке провайдеров:

@Component({
  // ...
  providers: [SomeService, MatDialog] // <-- добавляем сюда
})
export class DialogOverviewExample { /* ... */ }

Открываем модалку и получаем… точно такой же NullInjectorError. У тех, кто обновлялся до 15 версии теперь тоже должны начаться флэшбэки. Потому что начиная с 15 версии MatDialog под капотом использует сервис Dialog, который также по умолчанию провайдится в root. А его-то мы не поднимали вверх по дереву, он там в корне висеть и остался. Добавим, мы не гордые:

@Component({
  // ...
  providers: [SomeService, MatDialog, Dialog] // <-- добавляем сюда
})
export class DialogOverviewExample {
  // ...
}

Открываем модалку и видим, что всё работает как положено.

А что, если мы всё-таки гордые? Согласитесь, неприятно, когда обновляешь Angular до 15 версии, а у тебя перестали работать некоторые модалки, потому что теперь нужно поднимать на уровень компонента не один, а два провайдера. А если завтра их будет три? Нестабильно.

Вариант 3. Как правильно

Убираем MatDialog и Dialog из списка провайдеров, пользуемся теми, что лежат в root. Внутри корневого компонента инжектим Injector и передаём его при создании модалки:

@Component({
  // ...
  providers: [SomeService] // <-- ничего лишнего
})
export class DialogOverviewExample {
  constructor(
    public dialog: MatDialog, 
    public someService: SomeService, 
    public injector: Injector // <-- ижективно инжектим инжектор через инжекшен
  ) {
    console.log(someService.a);
  }

  openDialog(): void {
    const dialogRef = this.dialog.open(DialogOverviewExampleDialog, {
      data: { name: this.name, animal: this.animal }, 
      injector: this.injector // <-- и передаём его сюда
    });
	  // ...
  }
}

Вариант на все времена, работает как часы. Но чувствуете ли вы удовлетворение? Я нет. Мало того, что об этом не написано в документации, так я ещё должен вручную дополнительно доставать Injector и передавать его в специальный параметр. Это вообще не моя работа во-первых, во вторых у меня в классе теперь висит одно мутное лишнее поле, которого могло и не быть. Так сразу и говорите: чтобы пользоваться модалками, вам нужно всегда нужно доставать два провайдера.

Вариант 4. Как можно

Когда я рассказывал про второй вариант, где мы переносили провайдер на уровень компонента, я выделил там небольшой кусок предложения:

Создать лишний экземпляр сервиса мы можем, так как мы там не храним никаких данных, нам от него нужна лишь функция.

И вправду, перед нами пример stateless-сервиса — MatDialog. Да, я знаю, что он не совсем stateless, но по крайней мере, его можно спокойно поделить на две части — stateful и stateless. Первая часть будет хранить список открытых модалок и так далее, а вторая открывать модалки и передавать их в список первой. Первая часть нас вообще редко интересует, нам бы просто модалку открыть. Давайте напишем обёртку для MatDialog, которая сама разодобудет тот самый Injector из предыдущего решения, и сама его передаст при открытии модалки.

Напишем снова функцию с использованием inject:

export function useMatDialog() {
  const injector = inject(Injector);
  const matDialog = inject(MatDialog);

  return {
    // сигнатуру я скопировал из деклараций MatDialog
    open<T, D = any, R = any>(template: ComponentType<T> | TemplateRef<T>, config?: MatDialogConfig<D>): MatDialogRef<T, R> {
      const newConfig: MatDialogConfig<D> = { injector, ...config };
      return matDialog.open(template, newConfig)
    }
  }
}

Здесь мы получаем всю необходимую для нормальной работы информацию: Injector и MatDialog. Возвращаем объект с единственной функцией, которая проксирует метод open в сервис, перед этим подставляя в него параметр injector, если другой не указали извне.

Как пользоваться:

@Component({
  // ...
  providers: [SomeService], // <-- здесь только SomeService
})
export class DialogOverviewExample {
  dialog = useMatDialog(); // <-- получаем обёртку MatDialog
  
  // ...

  openDialog(): void {
    const dialogRef = this.dialog.open(DialogOverviewExampleDialog, {
      // в параметры передаём только бизнесовую информацию:
      data: { name: this.name, animal: this.animal } 
    });
    // ...
  }
}

Вот теперь я удовлетворён: здесь нет ничего лишнего, и следить ни за чем не нужно, всё самое страшное инкапсулировано в useMatDialog. Когда-то давно это сохранило бы мне 10 часов разбирательств, почему не открывается модалка, и я мог бы потратить их на что-то более полезное, например резать воду.

В общем, так можно поступать с любым stateless-сервисом, и забыть хотя бы о проблеме получения актуальных провайдеров. Ссылка на StackBlitz.

У меня всё. Я ещё иногда пишу в телеграм-канал.

P.S. У. меня стойкое желание назвать эти функции хуками. Особенно из-за того, что я использую слово “use” как префикс, и это перекликается с React. Поэтому объявляю интерактив!