Dependency Injection (DI) один из столпов, на которых держится фреймворк Angular. Каждый разработчик, так или иначе, сталкивается с ним с первого дня: запрашивает сервисы в конструкторе, добавляет providedIn: 'root' и видит, как «магия» работает. Но именно в этом и кроется ловушка.

Для многих DI так и остается на уровне «магии» удобного механизма, который просто работает. Однако поверхностное понимание этого мощнейшего инструмента неизбежно приводит к архитектурным компромиссам: неочевидным утечкам памяти, сложностям в тестировании, созданию неявных связей между компонентами и, в конечном счете, к коду, который трудно поддерживать и масштабировать.

Эта статья не очередной пересказ официальной документации. Это глубокое погружение в архитектуру и философию Dependency Injection в Angular. Наша цель демистифицировать «магию» и превратить ее в предсказуемый, управляемый и мощный инженерный инструмент в вашем арсенале.

Мы пройдем путь от фундаментальных принципов инверсии контроля (IoC) до тонкостей иерархического инжектора. Мы разберем на атомы все стратегии предоставления зависимостей, научимся управлять их жизненным циклом и областью видимости. Мы изучим продвинутые паттерны с использованием InjectionToken и multi-провайдеров и поймем, как современная функция inject() меняет подход к композиции логики.

В Angular любое изменение в компоненте, которое отображается на экране, является результатом работы механизма отслеживания изменений (Change Detection, CD). За этим процессом стоит Zone.js, который можно представить в роли дирижера, сообщающего компонентам о необходимости обновить DOM.

Zone.js не запускает CD сам. Он лишь создает контекст, в котором Angular потом может его запустить. Его задача только уведомлять Angular о завершении асинхронных операций, после чего Angular решает, нужно ли проверять изменения.

Чтобы понять важность такого подхода, нужно учитывать особенности JavaScript. В JavaScript асинхронные операции, такие как setTimeout или fetch, разрывают стек вызовов. Это значит, что callback-функция, выполняемая после завершения асинхронной операции, не имеет информации о контексте, в котором она была вызвана. Для фреймворка, который отслеживает изменения, это создает определенные трудности: как узнать, что асинхронная операция завершилась и, возможно, изменила данные?

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

Часто в компонентах можно встретить такой код: