Скрытый потенциал функции inject в Angular

Привет! В этой заметке покажу, как можно использовать функцию 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. Поэтому объявляю интерактив!