Как устроена иерархия инжекторов в Angular и как разрешается зависимость при обращении вверх по дереву?

Angular использует иерархическую систему внедрения зависимостей (DI). Каждый компонент, директива и модуль создаёт собственный инжектор, который наследует провайдеры от родителя. Это позволяет изолировать зависимости на разных уровнях приложения и переиспользовать одни и те же сервисы в разных контекстах.

Как работает разрешение зависимости

Когда класс запрашивает зависимость через конструктор, Angular начинает поиск с инжектора текущего компонента. Если провайдер не найден, поиск продолжается вверх по дереву: к родительскому компоненту, затем к модулю и, наконец, к корневому инжектору (root injector). Первый найденный провайдер используется для создания или получения экземпляра.

• Element Injector — создаётся для каждого компонента/директивы, содержит провайдеры из декоратора providers.
• Module Injector — создаётся для NgModule или для providedIn: 'root', является родительским для element injector.
• NullInjector — конечная точка, выбрасывает ошибку, если зависимость не найдена.

Пример иерархии

@Component({
  selector: 'app-child',
  providers: [{ provide: LoggerService, useClass: ChildLogger }],
  template: ''
})
export class ChildComponent {
  constructor(private logger: LoggerService) {}
}

@Component({
  selector: 'app-parent',
  providers: [{ provide: LoggerService, useClass: ParentLogger }],
  template: ''
})
export class ParentComponent {}

В этом примере ChildComponent получит ChildLogger, потому что его собственный инжектор содержит провайдер. Если бы провайдера не было, использовался бы ParentLogger.

Модификаторы поиска

Angular предоставляет декораторы для управления поиском:

• @Self() — искать только в текущем инжекторе.
• @SkipSelf() — пропустить текущий инжектор и начать поиск с родительского.
• @Host() — искать до хост-компонента включительно.
• @Optional() — вернуть null вместо ошибки, если зависимость не найдена.

Иерархия инжекторов позволяет гибко управлять областью видимости сервисов: например, создавать отдельный экземпляр сервиса для каждого компонента или использовать общий singleton на уровне приложения. Это особенно полезно для изоляции состояния и тестирования.