Ієрархія інжекторів в Angular

AngularSenior~5 хв читання

Ієрархія інжекторів в Angular - це дерево екземплярів Injector, що відображає дерево компонентів. Коли Angular резолвить залежність, він починає з найближчого інжектора і рухається вгору, поки не знайде провайдер або не кине помилку.

Теорія

Коротко

Як корпоративна ієрархія: спочатку питаємо свого менеджера (локальний інжектор), потім керівника відділу (модуль), потім CEO (root)
Дочірній інжектор наслідує від батьківського, але перекриває його, якщо сам декларує провайдер для того ж токена
providedIn: 'root' створює один синглтон для всього застосунку; Component.providers створює новий екземпляр для кожного компонента
Ліниво завантажені модулі мають окремий інжектор, тому сервіс у NgModule.providers лінивого модуля НЕ є спільним з root
Правило вибору: спільний стан по всьому застосунку = root, ізоляція фічі = модуль, дані для конкретного екземпляра = компонент

Швидкий приклад

// Root інжектор має UserService (providedIn: 'root')
@Injectable({ providedIn: 'root' })
export class UserService { name = 'real user'; }

// ChildComponent декларує власний провайдер - перекриває root
@Component({
  selector: 'app-child',
  template: '...',
  providers: [{ provide: UserService, useClass: MockUserService }]
})
export class ChildComponent {
  constructor(private user: UserService) {
    console.log(user instanceof MockUserService); // true - локальний інжектор перемагає
  }
}

Дочірній компонент отримає MockUserService, навіть якщо в root є UserService. Сусідні компоненти ChildComponent і далі отримуватимуть root-екземпляр.

Як Angular резолвить залежності

Коли компонент або сервіс запитує токен, Angular рухається вгору по дереву інжекторів:

Перевіряє власний інжектор компонента (оголошений у providers[])
Якщо не знайдено - перевіряє інжектор батьківського компонента
Продовжує вгору через всіх предків
Досягає інжектора модуля
Досягає root (application) інжектора
Якщо нічого не знайдено - кидає NullInjectorError

Кожен екземпляр Injector зберігає резолвнуті сервіси в records map. Тому один і той самий токен не інстанціюється двічі в межах одного інжектора. Це і є гарантія синглтона на кожному рівні.

Чотири рівні інжекторів

Root інжектор. @Injectable({ providedIn: 'root' }) реєструє сервіс на рівні застосунку. Один екземпляр на весь застосунок, створюється лениво при першому запиті. Підтримує tree-shaking: якщо сервіс ніхто не інжектує, він не потрапляє в бандл.

Інжектор модуля. Якщо сервіс вказаний у @NgModule.providers, він живе в інжекторі цього модуля. Для eagerly loaded модулів це зливається з root. Для lazy-loaded модулів створюється дочірній інжектор, тобто сервіс відокремлений від root.

Інжектор компонента. Додаючи сервіс у @Component.providers, отримуємо новий екземпляр для кожного екземпляра компонента. Цей екземпляр знищується разом із компонентом. Дочірні компоненти наслідують його, якщо не перевизначають.

Інжектор елемента (директиви). @Directive.providers працює так само, як провайдери компонента, але прив'язаний до елемента, де застосовується директива.

Коли що використовувати

Спільний стан по всьому застосунку (авторизація, логування, feature flags): providedIn: 'root'
Ізоляція фічі в lazy-loaded роуті: NgModule.providers всередині лінивого модуля
Дані для конкретного екземпляра компонента (локальний стан форми, кеш картки): Component.providers
Мокування сервісу в піддереві для тестів або e2e: провайдер на рівні компонента або модуля з useClass
Бібліотечні сервіси, що не повинні забруднювати глобальний простір: providedIn: 'platform' або рівень модуля

Як Angular будує це під капотом

При завантаженні Angular рекурсивно створює екземпляри Injector для кожного @Component з масивом providers[] і пов'язує кожен із батьківським через властивість parent. Під час резолвінгу викликається getAt(), що рухається вгору від місця запиту. Результати кешуються в records map кожного інжектора, тому повторний запит того ж токена повертає закешований екземпляр без повторної інстанціації.

В Angular 14+ providedIn: 'root' аналізується статично, що уможливлює tree-shaking. Сервіси в масивах providers[] не підлягають tree-shaking, бо вони явно вказані в метаданих модуля або компонента.

Standalone-компоненти (Angular 14+) частково спрощують цю картину: вони використовують EnvironmentInjector замість NgModule-інжекторів. Але провайдери на рівні компонента і далі створюють елементні інжектори так само.

Типові помилки

Помилка 1: очікування що провайдер лінивого модуля використовує root-екземпляр

// Неправильно: це створює ОКРЕМИЙ екземпляр, а не root-синглтон
@NgModule({
  providers: [DataService]  // Ліниво завантажений модуль має власний інжектор!
})
export class FeatureModule {}

Якщо DataService також providedIn: 'root', провайдер лінивого модуля перекриє його для всього, що всередині. Компоненти поза модулем і далі отримують root-екземпляр. Щоб використовувати root: видали з NgModule.providers і покладайся лише на providedIn: 'root'.

Помилка 2: оголошення сервісу і в модулі, і в компоненті

@NgModule({ providers: [CartService] })
// ...і також:
@Component({ providers: [CartService] })
export class CartComponent {}

Інжектор компонента перекриє інжектор модуля. Ти отримаєш два окремі екземпляри, що витрачають зайву пам'ять. Angular DevTools покаже це: відкрий дерево компонентів і перевір джерела інжектора для кожного компонента.

Помилка 3: забуваєш що дочірні компоненти наслідують провайдери батьківського компонента

@Component({ providers: [SharedService] })
export class ParentComponent {}

// ChildComponent отримає екземпляр SharedService від ParentComponent
// НЕ root-екземпляр, НЕ новий
@Component({ selector: 'app-child', template: '' })
export class ChildComponent {
  constructor(private s: SharedService) {}
}

Я бачив як команди додають провайдер до батьківського компонента "тільки для цього батька", а потім дивуються чому дочірній компонент отримує несподіваний стан. Дочірній наслідує автоматично.

Помилка 4: providedIn: 'root' у бібліотеці, що публікується

Це реєструє сервіс у root-інжекторі застосунку під час збірки. Для звичайних застосунків - нормально. Але для бібліотек це може конфліктувати зі споживачами. Використовуй providedIn: 'platform' для сервісів, що мають бути спільними між мікрофронтендами, або залиш вибір застосунку-споживачу.

Помилка 5: плутанина між viewProviders і providers

viewProviders обмежує сервіс лише view компонента (шаблоном), виключаючи контент, проєктований через <ng-content>. providers ділиться і з view, і з content-дочірніми. Неправильний вибір призводить до NullInjectorError у проєктованих компонентах, що намагаються інжектувати цей сервіс.

Де зустрічається в реальних проєктах

Angular Material: OverlayRef і сервіси діалогів використовують providedIn: 'root' для синглтона overlay-контейнера
NgRx: StoreModule.forRoot() реєструє стан на рівні root; StoreModule.forFeature() додає стан фічі в дочірній інжектор модуля
Nx workspaces: ліниві feature-бібліотеки використовують провайдери на рівні модуля для ізоляції сервісів від shell-застосунку
Angular Universal (SSR): провайдери на рівні платформи замінюють браузерні API на Node-сумісні без будь-яких змін у root

Питання на співбесіді

Q: Що відбувається коли lazy-loaded модуль надає сервіс, що також є providedIn: 'root'?
A: Інжектор лінивого модуля перекриє root для будь-якого компонента всередині цього модуля. Компоненти поза лінивим модулем і далі отримують root-синглтон. Два окремі екземпляри існують одночасно в одному застосунку.

Q: Як @SkipSelf() змінює резолвінг?
A: Він пропускає інжектор поточного компонента і починає пошук з батьківського. Корисно коли сервіс потребує доступу до своєї батьківської версії, наприклад вузол дерева, якому потрібен TreeService батька, а не свій власний.

Q: Що робить @Self()?
A: Обмежує пошук лише інжектором поточного компонента. Якщо токен там не знайдено - Angular одразу кидає помилку без підйому по дереву. Використовується щоб гарантувати що залежність обов'язково надається на тому ж рівні, що й споживач.

Q: Як standalone-компоненти змінюють ієрархію інжекторів?
A: Standalone-компоненти (Angular 14+) використовують EnvironmentInjector замість NgModule-інжекторів. Функція bootstrapApplication() створює root EnvironmentInjector. Провайдери на рівні компонента і далі створюють елементні інжектори. Функція inject() в реактивних контекстах, зокрема в сигналах, використовує те саме дерево.

Q (senior): Директива застосована до компонента і директива інжектує сервіс. Де Angular шукає цей сервіс?
A: Пошук починається в інжекторі елемента, на якому стоїть директива. Він включає провайдери і компонента, і директиви одночасно. Після цього Angular рухається вгору по дереву компонентів звичайним чином. Директива не має окремої гілки інжектора; вона поділяє контекст інжектора елемента з хост-компонентом.

Приклади

Базовий: ізольований екземпляр на компонент

// counter.service.ts
@Injectable()
export class CounterService {
  count = 0;
  increment() { this.count++; }
}

// card.component.ts
@Component({
  selector: 'app-card',
  template: `
    <button (click)="counter.increment()">+</button>
    <span>{{ counter.count }}</span>
  `,
  providers: [CounterService]  // Кожна картка отримує свій власний лічильник
})
export class CardComponent {
  constructor(public counter: CounterService) {}
}

Два елементи <app-card> на одній сторінці показують незалежні лічильники. Якби CounterService був providedIn: 'root', вони б ділили стан і обидві кнопки збільшували б одне число.

Середній: мокування сервісу в lazy-loaded фічі

// auth.service.ts
@Injectable({ providedIn: 'root' })
export class AuthService {
  isLoggedIn = false;
  login() { this.isLoggedIn = true; }
}

// mock-auth.service.ts
@Injectable()
export class MockAuthService extends AuthService {
  isLoggedIn = true;  // Завжди залогований для e2e-тест модуля
}

// auth-test.module.ts (lazy loaded)
@NgModule({
  providers: [{ provide: AuthService, useClass: MockAuthService }]
})
export class AuthTestModule {}

// dashboard.component.ts (всередині AuthTestModule)
@Component({ template: `<span *ngIf="auth.isLoggedIn">Вітаємо</span>` })
export class DashboardComponent {
  constructor(public auth: AuthService) {}
  // Отримує MockAuthService - завжди показує "Вітаємо"
}

Root-екземпляр AuthService залишається незміненим. Лише компоненти всередині AuthTestModule бачать мок. Все поза лінивою межею і далі використовує реальний синглтон.

Просунутий: `@SkipSelf()` для самореференційних сервісів

// logger.service.ts
@Injectable()
export class LoggerService {
  constructor(
    @Optional() @SkipSelf() private parent: LoggerService
  ) {}

  log(msg: string) {
    const prefix = this.parent ? '[child]' : '[root]';
    console.log(`${prefix} ${msg}`);
  }
}

// parent.component.ts
@Component({
  selector: 'app-parent',
  template: '<app-child></app-child>',
  providers: [LoggerService]  // Root логер
})
export class ParentComponent {
  constructor(private logger: LoggerService) {
    this.logger.log('parent init');  // "[root] parent init"
  }
}

// child.component.ts
@Component({
  selector: 'app-child',
  template: '',
  providers: [LoggerService]  // Дочірній логер, знає про батька
})
export class ChildComponent {
  constructor(private logger: LoggerService) {
    this.logger.log('child init');  // "[child] child init"
  }
}

@SkipSelf() каже Angular шукати LoggerService починаючи з батьківського компонента, а не з поточного. У поєднанні з @Optional() це уникає помилки кругової залежності на рівні root, де батьківського логера просто немає.

Коротка відповідь

Для співбесіди

Premium

Коротка відповідь допоможе вам впевнено відповідати на цю тему під час співбесіди.