Когда я говорю, что перешёл с React на Angular обычно в ответ у коллег слишком много вопросов и ни одного ответа. Если открыть типичные статьи, там везде предлагают React, Next.js и React Native. Про переход с Angular на React вы наверняка уже читали и смотрели много гайдов, а вот обратный путь почти никто не описывал.

Мне пришлось разбираться самому, когда я пришёл на новый проект, где на этапе знакомства с системой я понял: сделать её на React технически можно, но нужно постоянно собирать структуру с нуля. Angular с его сложной архитектурой, сервисами и строгой типизацией казался оптимальным решением для такого масштаба.

Теоретически получить базовое понимание фреймворка можно за десять дней курсов, но у меня ушло минимум полтора месяца, чтобы перестать мысленно переводить конструкции React на Angular и начать просто писать код.

Главный сдвиг в голове при переходе с React — смена подхода, где компоненты несут всю нагрузку, на архитектуру, построенную на классах и ООП. В React привыкаешь думать компонентами: каждый кусок интерфейса представляет собой функцию, которая принимает пропсы и возвращает разметку. Вся логика и JSX-шаблон живут в одном файле, всё плоское и перед глазами. В Angular приходится перестраиваться и думать объектами и иерархиями.

Разделение на файлы поначалу вызывает раздражение. Вместо одного файла здесь сразу три: отдельный HTML-шаблон, стили и TypeScript-класс компонента, взаимодействующие через декораторы. Если нужно сделать маленький компонент-иконку для рендеринга SVG, Angular всё равно потребует три файла. Инлайн-шаблоны сделать можно, но это считается плохой практикой. Переключение между файлами поначалу отвлекает, но когда шаблон становится большим и сложным, работать с ним как с отдельным документом оказывается удобно.

Проект в Angular организуется по строгой структуре: сначала выделяются библиотеки (libs), внутри них — фичи (features), и только внутри фич живут компоненты. В React всё обычно проще и ограничивается папками с компонентами, которые используют друг друга.

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

Архитектура строится вокруг базовых классов с общими методами и свойствами, от которых наследуются конкретные сущности. Если создать базовый класс Animal, дочерние классы Cat, Duck или Elephant получат его функциональность и добавят собственные уникальные атрибуты, не затрагивая родительский код. Когда нужно исправить или обновить базовую логику, нужно только внести изменения в одном месте, и они автоматически разойдутся по всей иерархии.

Больше всего при переходе на Angular пугает RxJS. В React мы привыкли явно запрашивать данные и ждать ответа, а здесь приходится подписываться на поток и реагировать на каждое его изменение. Данные идут сами и непрерывно, а главная задача разработчика — правильно их направить: отфильтровать лишнее, объединить несколько потоков в один и вовремя отписаться, чтобы избежать утечек памяти.

В реальном коде это выглядит как цепочка операторов, модифицирующих данные до их попадания в компонент. Проблема в том, что в RxJS около 50 операторов, и для нормальной работы нужно сходу знать хотя бы 10-15 из них, без этого читать чужой код не получится.

На адаптацию уходит время: сначала приходишь в документацию за каждым оператором, а затем вырабатывается инстинкт. Начинаешь сразу видеть, где применить switchMap, а где добавить takeUntilDestroyed для автоматической очистки ресурсов. Это похоже на изучение иностранного языка — сначала переводишь каждое слово, а потом начинаешь думать на нем.

Когда от стадии “отрицания” переходишь к “принятию” подхода, начинаешь замечать вещи, за которые Angular хочется любить. Первое, что бросается в глаза после React, — работа с формами. В React каждый раз приходится выбирать между React Hook Form, Formik и другими решениями, разбираясь в новой библиотеке на каждом проекте. В Angular работы с формами встроена в сам фреймворк: есть задокументированные Template-driven и Reactive Forms. Реактивные формы позволяют прописать объект FormGroup и всю валидацию прямо в TypeScript. В сложных конструкторах с вложенной логикой и зависимыми полями это полностью закрывает задачи без поиска сторонних пакетов на npm.

Следом привыкаешь к CLI, который буквально не даёт сделать что-то неправильно. Для нового компонента достаточно выполнить ng generate component auth-form — инструмент сам создаст файлы и зарегистрирует компонент в модуле. Точно так же одной командой генерируются сервисы и модули с маршрутизацией. Инструмент выполняет рутину по единственному правильному шаблону, который при необходимости можно настроить под проект.

Приятно удивляет и декоратор @HostBinding. Если в React для добавления CSS-класса по условию приходится писать логику в JSX или выносить её в отдельную функцию, то в Angular достаточно повесить одну строчку над свойством класса. Класс сам появляется или исчезает на хост-элементе в зависимости от значения, не создавая лишнего шума в шаблоне.

Самая противная проблема в Angular — циклические зависимости. Это ситуация, когда Сервис А зависит от Сервиса Б, а Сервис Б где-то дальше по цепочке ссылается на Сервис А. Фреймворк далеко не всегда ясно указывает на место ошибки: приложение может просто упасть при старте или вывести в консоль сбой, указывающий совсем не на ту причину.

На поиск подобного бага можно легко убить полдня, если перебирать компоненты вручную. В React такие проблемы возникают реже — там меньше неявных связей, а ошибка обычно располагается ближе к источнику. В Angular нужно учиться думать деревьями и графами.

Для выхода из этой ситуации есть инструмент Nx и команда nx dep-graph (или nx graph). Она визуализирует интерактивную карту проекта прямо в браузере, рисуя дерево связей между всеми библиотеками. Если в проекте появился закольцованный цикл, команда автоматически подсвечивает его красным цветом.

Angular точно не подходит на роль первого фреймворка для новичка. Это логичный следующий шаг, если хочется развиваться в сторону фуллстека или бэкенда: Java и Go тоже используют классы, объекты и dependency injection как стандартную практику. Год работы с Angular помогает легче понимать паттерны того же Spring Boot, потому что основные концепции уже отработаны на фронтенде.

Если задача — быстро собрать MVP, стартап, лендинг или небольшое приложение, объективно проще взять React. Там меньше формальностей и ниже порог входа на старте. Когда же предстоит развивать сложную долгоживущую систему с крупной командой, Angular оказывается практичнее: через год любой новый разработчик сразу поймёт структуру без дополнительных объяснений.

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

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

Да, поначалу три файла на один маленький компонент и десятки операторов RxJS откровенно бесят и кажутся какой-то лютой бюрократией. Но когда дискомфорт уходит, а в проекте появляется куча людей, ты просто перестаёшь тратить время на споры о структуре папок, выборе стейт-менеджера или библиотек для форм. Код становится прозрачным и понятным по умолчанию.

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