Современный Angular — это мощный фреймворк с множеством возможностей, вместе с которыми приходят и сложные, на первый взгляд, концепции и механизмы. Особенно это заметно тем, кто только начал работу как во фронтэнде в принципе, так и с Angular в частности. С этой же проблемой столкнулся и я, когда примерно два года назад пришел в Тинькофф на позицию Junior Frontend Developer и погрузился в мир Angular. Поэтому предлагаю вам короткий рассказ о пяти вещах, понимание которых очень облегчило бы мою работу на первых порах.  Первое время я заходил в компонент и видел, что в конструкторе класса есть какие-то аргументы. Я провел небольшой анализ работы методов класса, и стало понятно, что это какие-то внешние зависимости. Но как они попали в класс? В каком месте вызвали конструктор? Предлагаю сразу разобраться на примере, а для этого нам понадобится класс. Если в «обычном» JavaScript ООП присутствует с определенными «хаками», то вместе с ES6 появился и «настоящий» синтаксис. В Angular прямо из коробки используется TypeScript, в котором синтаксис примерно такой же. Поэтому далее предлагаю использовать его. Представим, что в нашем приложении существует класс JokerService, который управляет шутками. Метод getJokes() возвращает список шуток. Допустим, мы его используем в трех местах. Как получить шутки в трех разных местах в коде? Есть несколько способов: Итак, у нас есть три вполне рабочих варианта. Первый нам не подойдет — в данном случае он неэффективен. Мы не хотим создавать лишние экземпляры, так как они будут полностью идентичны. Остается два варианта. Давайте усложним задачу, чтобы понять, какой способ нам подходит больше. Допустим, в третьем месте нам нужно по какой-то причине создавать свой сервис с определенными параметрами. Это может быть определенный автор, длина шутки, язык и прочее. Что мы будем делать тогда? В случае со статическим методом придется передавать настройки с каждым вызовом, так как класс общий для всех мест. То есть в каждый вызов getJokes() мы будем передавать все уникальные для данного места параметры. Конечно, лучше передать их при создании экземпляра и потом просто вызывать метод getJokes(). Выходит, что второй вариант нам тоже не подойдет: он заставит нас в каждом месте всегда дублировать много кода. Остается только Singleton, у которого снова нужно будет обновить логику, но уже с вариациями. Но как понять, какой именно вариант нам нужен? Если вы подумали, что можно просто создать объект и по ключу брать нужный сервис, то могу вас поздравить: вы только что поняли, как в целом работает Dependency Injection. Но давайте немного углубимся. Чтобы убедиться в необходимости механизма, который поможет нам получать нужные экземпляры, представьте, что JokerService нужны еще два других сервиса, один из которых не обязательный, а второй должен в определенном месте отдавать специальный результат. Это несложно. Как гласит документация, DI — важный паттерн дизайна приложения. Angular имеет собственный фреймворк для зависимостей, который используется в самом Angular для повышения эффективности и модульности. Если говорить в общих понятиях, то Dependency Injection — это мощный механизм, при котором класс получает необходимые зависимости откуда-то извне, а не создает экземпляры самостоятельно. Пусть синтаксис и файлы с расширением html вас не путают. Каждый компонент в Angular — это обычный объект JavaScript, экземпляр класса. Если говорить общими словами: когда вы вставляете компонент в шаблон — создается экземпляр класса компонента. Соответственно, в этот момент можно передать в конструктор нужные зависимости. А теперь рассмотрим пример: В конструкторе компонента мы просто указываем, что нам нужен JokerService. Мы не создаем его сами. Если будет еще пять компонентов, которые его используют, то все они будут обращаться к одному и тому же экземпляру. Все это позволяет нам экономить время, исключить бойлерплейт и писать очень производительные приложения. А теперь предлагаю разобраться с тем случаем, когда нужно получать разные экземпляры сервиса. Для начала взглянем на сам сервис: Когда сервис один на все приложение, будет достаточно этого варианта. Но что делать, если у нас есть, допустим, две реализации JokerService? Или просто по какой-то причине в определенном компоненте нужен свой экземпляр сервиса? Ответ прост: provider. Для удобства дальше я буду называть provider провайдером, а сам процесс подстановки значения в класс — запровайдить. Так вот, мы можем запровайдить сервис разными способами и в разных местах. Начнем с последнего. Всего существует три доступных варианта: Место выбирается в зависимости от ваших потребностей. С местом разобрались, перейдем к самому механизму. Если мы просто указали provideIn: root в сервисе, это будет эквивалентно следующей записи в модуле: Это можно прочитать примерно так: «Если запрашивается JokerService, то отдай экземпляр класса JokerService». Отсюда можно получить определенный экземпляр различными способами: По токену — нужно указать InjectionToken и получать сервис по нему. Обратите внимание, что в примерах ниже в provide можно передать этот же токен: По классу — можно подменить класс. Например, мы будем просить JokerService, а отдавать — JokerHappyService: По значению — можно сразу вернуть нужный экземпляр: По фабрике — можно подменить класс фабрикой, которая будет создавать нужный экземпляр при обращении: Вот и все. То есть для решения примера со специальным экземпляром можно использовать любой из перечисленных выше способов. Выбирайте наиболее подходящий под ваши потребности. Кстати, DI работает не только для сервисов, а вообще для любой сущности, которую вы получаете в конструкторе компонента. Это очень мощный механизм, который следует использовать на полную. Для полного понимания предлагаю рассмотреть упрощенный механизм Dependency Injection в Angular по шагам на примере сервиса: Мы часто слышим в качестве аргумента для использования фреймворков что-то вроде «Фреймворк все сделает за вас — быстрее и эффективнее. Вам не нужно ни о чем думать. Просто управляйте данными». Возможно, это действительно так в отношении очень простого приложения. Но если приходится работать с пользовательским вводом и постоянно оперировать данными, то знать, как работает процесс обнаружения изменений и рендеринга, просто необходимо. В Angular за проверку изменений отвечает механизм Change Detection. В результате различных операций — изменение значения свойства класса, завершение асинхронной операции, ответ на HTTP-запрос и так далее — запускается процесс проверки по всему дереву компонентов. Так как главная цель процесса — понять, как перерендерить компонент, то суть заключается в проверке данных, используемых в шаблонах. Если они разные, то шаблон помечается как «измененный» и будет перерисован. Понять, как Angular следит за свойствами класса и синхронными операциями, довольно просто. Но как он отслеживает асинхронные? За это отвечает библиотека Zone.js, созданная одним из разработчиков Angular. Вот что это такое. Зона сама по себе — это «контекст выполнения», если выражаться грубо — место и состояние, в котором выполняется код. После выполнения асинхронной операции функция обратного вызова (callback) выполняется в той же зоне, где была зарегистрирована. Так Angular узнает, в каком месте произошло изменение и что следует проверить. Zone.js заменяет своими реализациями практически все нативные асинхронные функции и методы. Поэтому она может отследить момент, когда будет вызван callback асинхронной функции. То есть Zone сообщает Angular, когда и где нужно запустить процесс проверки изменений. Мы разобрались, каким образом Angular следит за компонентом и запускает проверку изменений. А теперь представьте, что у вас огромное приложение с десятками компонентов. И на каждый клик, каждую асинхронную операцию, каждый удачно выполненный запрос запускается проверка по всему дереву компонентов. Скорее всего, у такого приложения будут серьезные проблемы с производительностью. Разработчики Angular подумали об этом и дали нам возможность установить стратегию обнаружения изменений, корректный выбор которой может довольно сильно увеличить производительность. Всего на выбор два варианта: Опираясь на свой собственный опыт разработки на Angular, а также на опыт моих коллег, могу сказать наверняка, что лучше всегда указывать стратегию OnPush, за исключением случаев, когда default действительно необходим. Это даст вам несколько преимуществ: Как и в других популярных фреймворках, в Angular используется нисходящий поток данных. Компонент принимает входные параметры, которые помечаются декоратором @Input(). Рассмотрим на примере: Допустим, есть описанный выше компонент, который выводит текст шутки и автора. Проблема такого написания в том, что вы можете случайно или специально мутировать переданный объект. Например, перезаписать текст или автора. Сразу отмечу, что это плохой пример, но он явно показывает, что может произойти. Чтобы защититься от таких ошибок, нужно делать входные параметры доступными только для чтения. Благодаря этому у вас будет понимание, как корректно работать с данными и вызывать CD. Исходя из этого лучший вариант написания класса будет выглядеть примерно так: Описанный подход — не правило, а лишь рекомендация. Существует множество ситуаций, когда такой подход будет неудобен и неэффективен. Со временем вы научитесь понимать, в каком случае можно отказаться от предложенного способа работы с инпутами. Конечно, я могу ошибаться, но складывается ощущение, что ReactiveX и реактивное программирование в целом — это новый тренд. Angular поддался этому тренду (а может, и создал его) и использует RxJS по умолчанию. Базовая логика всего фреймворка работает на данной библиотеке, поэтому очень важно понимать принципы реактивного программирования. Но что такое RxJS? Он объединяет три идеи, которые я раскрою довольно простым языком с некоторыми упущениями: Объединение этих паттернов позволяет нам очень просто описывать сложные с первого взгляда алгоритмы, например: Всего 18 строк со всеми красивыми отступами. А теперь попробуйте переписать этот пример на Vanilla или хотя бы на jQuery. Почти 100% у вас это займет как минимум в два раза больше места и будет не так выразительно. Здесь же вы можете просто идти глазами по строке и читать код как книгу. Понимание, что любые данные можно представить в виде потока, приходит не сразу. Поэтому предлагаю перейти к простой аналогии. Представьте, что поток — это массив данных, отсортированных по времени. Например, в таком варианте: Мы будем считать актуальным последнее значение в массиве. Каждую секунду в массив будет добавляться число. Как мы можем узнать в другом месте приложения, что в массив был добавлен элемент? В обычной ситуации мы вызывали бы какой-нибудь callback и по нему обновляли значение массива, а затем просто брали бы последний элемент. Благодаря реактивному программированию отпадает необходимость не только писать множество новой логики, но и вообще думать о том, чтобы обновить информацию. Это можно сравнить с простым слушателем: Вы можете поставить много EventListener'ов во всем приложении, и они все будут отрабатывать, если вы, конечно, не позаботились об обратном специально. Так же работает и реактивное программирование. В одном месте мы просто создаем поток данных и периодически закидываем туда новые значения, а в другом — подписываемся на этот поток и просто слушаем эти значения. То есть мы всегда узнаем об обновлении и можем это обработать. Теперь давайте посмотрим на реальный пример: Благодаря такой логике при изменении данных в jokes у нас автоматически обновятся данные по количеству непрочитанных шуток и список авторов. Если у вас есть еще пара компонентов, один из которых собирает статистику по количеству прочитанных шуток одного автора, а второй вычисляет среднюю длину шуток, то преимущества становятся очевидными. Рано или поздно разработчик понимает, что если проект — не MVP, то нужно писать тесты. И чем больше тестов будет написано, чем понятнее и подробнее у них описание, тем проще, быстрее и надежнее вносить изменения и реализовывать новый функционал. Вероятно, в Angular это предвидели и дали нам мощный инструмент для тестирования. Многие разработчики сначала пытаются осилить какую-то технологию «с разбега», не вдаваясь в документацию. Так же поступал и я, отчего довольно поздно осознал все возможности тестирования, доступные «из коробки». В Angular можно тестировать что угодно, но если для тестирования обычного класса или сервиса достаточно просто создать экземпляр и начать вызывать методы, то с компонентом ситуация совершенно иная. Как мы уже выяснили, благодаря DI зависимости берутся вне компонента. С одной стороны, это немного усложняет всю систему, с другой — дает нам большие возможности для настройки тестов и проверки множества кейсов. Предлагаю разобраться на примере компонента: Итак, в текущем примере есть три сервиса. Один импортится обычным способом, один — по токену и еще один сервис опционален. Как мы сконфигурируем тестовый модуль? Я покажу сразу готовый вид: TestBed позволяет нам сделать полную имитацию требуемого модуля. В него можно запровайдить любые сервисы, подменить модули, получить экземпляры классов из компонента и многое другое. Теперь, когда у нас есть уже сконфигурированный модуль, перейдем к возможностям. Приложение на Angular состоит из модулей, которые могут включать в себя другие модули, сервисы, директивы и прочее. В тесте нам необходимо, по сути, воссоздать работу модуля. Если в нашем примере мы используем в шаблоне <some-dependency></some-dependency>, это значит, что мы должны импортировать SomeDependencyModule и в тест. А если там есть свои зависимости? Значит, и их тоже нужно импортировать.
Если приложение сложное, таких зависимостей будет масса. Импорт всех зависимостей приведет к тому, что в каждом тесте будет находиться вообще все приложение и будут вызываться все методы. Наверное, нам такое не подходит. Существует как минимум один способ избавиться от нужных зависимостей — просто переписать шаблон. Допустим, у вас есть скриншот-тестирование или интеграционные тесты и нет необходимости тестировать внешний вид компонента. Тогда достаточно просто проверить работу методов. В этом случае можно написать конфигурацию следующим образом: Да, это подойдет не всем. Внутри Тинькофф мы договорились использовать такой подход только в тех случаях, когда нет необходимости проверять отображение компонента. Например, когда ведется только работа с данными или общение со стором. Если есть необходимость проверять, как передаются данные в дочерние компоненты или, например, как обрабатывается пользовательский ввод, то этот вариант не подойдет. Если у вас как раз такой случай — переходим к следующему пункту. Мы уже ознакомились с Injection Token, поэтому предлагаю сразу перейти к делу. В примере выше я уже запровайдил в тест сервис по токену. Если вы пишете не интеграционный тест, то смысла вызывать методы реального сервиса нет, просто сделайте мок. Для этого можно использовать специальные библиотеки вроде ts-mockito, которые существенно облегчат вам жизнь, но это не обязательно. Angular предоставляет массу возможностей «из коробки». Вот и все. Так же можно поступить с любой зависимостью из конструктора. В нашем тестируемом компоненте есть три сервиса. Один инжектится обычным способом, второй — по токену, а третий — опциональный. Выходит, что с помощью различных конфигураций можно проверить все кейсы как минимум в следующих вариациях: Тесты — это ваш самый главный помощник при разработке. Если кейсы будут описывать реальную работу компонента обычным человеческим языком, то часть возможных проблем удастся отловить еще на этом этапе. Самое главное — с тестируемым кодом приятно работать. Мы ознакомились с некоторыми базовыми механизмами Angular, знаний о которых мне не хватало в самом начале моего пути. Чтобы подробно раскрыть каждый механизм, нужна отдельная статья, которые есть в том числе и на «Хабре». В отличие от других современных фреймворков, Angular часто предлагает уже готовые способы реализации какого-либо механизма. Это могут быть HTTP-запросы, роутинг, lazy-loading и прочее. Поэтому я призываю всех прочитать или хотя бы пробежать глазами официальную документацию Angular. Frontend Developer