Что такое механизм Dependency Injection в Angular? На каких уровнях и где, помимо сервисов, его можно использовать?

Что такое Dependency Injection?

Dependency Injection — это подход, при котором объект получает свои зависимости извне, а не создает их сам. В Angular это реализовано через систему инжекторов: каждый класс, помеченный декоратором @Injectable(), может быть зарегистрирован в провайдере, и Angular автоматически создаст его экземпляр и передаст туда, где он запрошен.

Уровни DI в Angular

Angular использует иерархическую систему инжекторов. Существует три основных уровня:

• Корневой инжектор — создается при старте приложения, доступен всем. Сервисы, указанные в providedIn: 'root', попадают сюда.
• Инжектор модуля — если сервис указан в providers конкретного NgModule, он доступен только в пределах этого модуля.
• Инжектор компонента — если сервис указан в providers компонента, он создается отдельно для каждого экземпляра компонента и доступен только ему и его дочерним элементам.

Где еще можно использовать DI?

DI в Angular применяется не только к сервисам. Вы можете внедрять зависимости в:

• Компоненты и директивы — через конструктор.
• Пайпы — если пайп объявлен как класс с декоратором @Injectable().
• Фабрики и значения — используя токены и провайдеры с типом useFactory или useValue.
• Другие сервисы — сервисы могут зависеть от других сервисов.

Пример кода

// Сервис с providedIn: 'root'
@Injectable({ providedIn: 'root' })
export class LoggerService {
  log(msg: string) { console.log(msg); }
}

// Компонент, использующий DI
@Component({...})
export class AppComponent {
  constructor(private logger: LoggerService) {}

  ngOnInit() {
    this.logger.log('App started');
  }
}

// Пример с фабрикой
const TOKEN = new InjectionToken<string>('config');
providers: [
  { provide: TOKEN, useFactory: () => 'some value' }
]

Вывод

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