Готовых инструкций, как перейти с React на Angular, в сети практически нет. Зато есть тысячи статей про обратный путь. Пришлось разбираться самому, и вот что из этого вышло.

Проект, который всё решил

Я перешёл в компанию, которая занимается системами контроля за объектами крупного строительства вроде заводов, стадионов и т. д. На площадке сотни камер, дроны, которые облетают периметр и передают видео в реальном времени, геоданные, карты с метками, сценарии автоматического реагирования.

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

Ну и плюсом это была возможность развиваться внутри Centicore Group, освоить относительно новый стек, а не просто делать то же самое на новом месте.

Пришлось перестраивать мышление

Коллега, который уже «совершил переход», предупредил, что первые дни будут странными. Не сложными в смысле «сиди и решай задачи», а именно странными. То есть ты смотришь на код и вообще не понимаешь, что у вас здесь происходит.

Angular — это и другой синтаксис, и другой способ думать о приложении. Когда открываешь компонент в React, видишь функцию, она возвращает JSX, внутри хуки. Логика и шаблон живут в одном месте, всё перед глазами.

Открываешь компонент в Angular — и видишь файлы. Один для шаблона HTML, один для стилей и один TypeScript-класс, который и есть компонент. И эти файлы разговаривают между собой через декораторы, которые висят над классом как загадочные аннотации.

Онбординг у меня был сразу на реальных задачах. Код-ревью от коллег по проекту поначалу было мягким: работает, и ладно. Потом постепенно требования ужесточались — сначала «работает», потом «работает и по-нашему», потом «работает, по-нашему, и объясни, почему именно так».

Теоретически за Angular можно сесть и за 10 дней курсов получить базовое понимание. Но на то, чтобы перестать каждый раз думать «а как это делается в Angular?» и начать просто делать, у меня ушло полтора месяца минимум.

Зачем плодить файлы, если всё и так работает

Самый большой сдвиг в голове — это переход от подхода, где компоненты несут всю нагрузку, к подходу, где архитектура строится на классах и ООП.

В React ты думаешь компонентами — вот кнопка, вот карточка. Каждый кусок интерфейса — это функция, которая принимает пропсы и возвращает разметку. Всё плоское и видно сразу.

В Angular надо больше думать объектами и иерархиями. И это меняет буквально всё.

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

Например, в нашем проекте есть камеры нескольких типов. Базовая стоит, снимает сектор и передаёт видео. Поворотная умеет всё то же самое, плюс может менять угол обзора по команде оператора. Ещё есть камера на дроне: она летает, координаты у неё меняются в реальном времени, и она наследует логику поворотной, но добавляет к ней поведение геолокации.

В React я бы, скорее всего, сделал несколько компонентов с похожей логикой, вынес общее в хук и где-то по дороге потерял бы нить, что откуда берётся. В Angular это решается через наследование классов. Есть базовый класс Camera с общими методами и свойствами. От него наследуется PTZCamera (поворотная), от неё — DroneCamera. Каждый класс добавляет своё, не трогая родительское. Когда нужно исправить что-то в базовой логике — правишь в одном месте, и это расходится по всей иерархии.

Когда я это понял, не прочитал, а именно понял в процессе работы, Angular перестал пугать и начал казаться умно спроектированным инструментом.

Разделение на файлы, которое поначалу раздражало, — HTML отдельно, TypeScript отдельно, — тоже встаёт на место. Когда шаблон большой и сложный, удобно работать с ним как с отдельным документом, не прокручивая мимо трёхсот строк логики. Минус в том, что переключаться между файлами нужно постоянно, и если IDE не настроена хорошо, это превращается в маленький ежедневный раздражитель.

Данные приходят сами

Поначалу сильнее всего пугает в Angular RxJS.

Если коротко, RxJS — это библиотека для работы с асинхронными потоками данных. В React ты запрашиваешь данные и ждёшь ответа, а в Angular подписываешься на поток и реагируешь на каждое изменение.

Интересно, что создатели RxJS явно вдохновлялись сантехникой. Все термины и операторы здесь работают в логике системы водоснабжения. Есть потоки (streams), трубы (pipes), разветвления и краны.

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

Проблема в том, что этих операторов в RxJS около пятидесяти. И чтобы начать нормально работать, нужно знать минимум десять-пятнадцать из них сразу. Потому что код коллег уже написан с ними, и надо его читать и понимать.

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

За что я влюбился

Когда дискомфорт от нового постепенно уходит, то привыкаешь и замечаешь вещи, за которые начинаешь любить Angular.

Первое, что бросилось в глаза, — формы. В React работа с формами — это всегда сначала выбор: React Hook Form, React Final Form, Formik, что-то ещё. У каждой команды своё решение, и каждый раз приходишь в новый проект и разбираешься заново.

В Angular формы встроены в фреймворк и никуда не деваются. Есть два подхода — Template-driven и Reactive Forms, — оба задокументированы и стандартны. Реактивные особенно хороши: создаёшь объект FormGroup, прописываешь валидацию прямо в TypeScript, и форма сама отслеживает своё состояние. В нашем конструкторе сценариев формы бывают огромными, с вложенной логикой и зависимыми полями — и всё это решается средствами фреймворка, без поиска нужного пакета на npm.

Следом привыкаешь к CLI и понимаешь, что он не просто ускоряет работу, а буквально не даёт сделать что-то неправильно. Хочешь новый компонент — пишешь ng generate component camera-panel, и сразу появляются все файлы, компонент регистрируется в модуле, всё связано. Сервис — ng generate service camera-stream. Целый модуль с маршрутизацией — одна команда. То есть вероятность сгенерировать компонент «не по-ангуляровски» физически сводится к минимуму. Инструмент делает всё за тебя по единственному правильному шаблону, который ещё и можно настроить под свой проект (например, добавить префикс именования селекторов компонентов).

И есть совсем маленькая вещь, которая тем не менее каждый раз приятно удивляет, — декоратор @HostBinding. В React, чтобы добавить CSS-класс к элементу в зависимости от состояния, пишешь логику в JSX, возможно, отдельную функцию, передаёшь через props. В Angular вешаешь одну строчку над свойством класса — и класс сам появляется или исчезает на хост-элементе в зависимости от значения. Никаких лишних функций и шума в шаблоне. Можно открыть код через три месяца и сразу понять контекст.

Обратная сторона

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

И Angular не всегда достаточно ясно указывает на эту зависимость. Он просто падает или ведёт себя непредсказуемо. Или вообще выводит в консоль ошибку, которая указывает куда угодно, только не на настоящую причину.

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

Оказалось, что в Nx есть встроенная команда nx dep-graph. Она открывает в браузере интерактивную карту всего твоего проекта. Там буквально нарисовано дерево: все либы, все связи между ними стрелочками. И если есть «цикл», он подсвечивается красным. Без этого инструмента найти такую ошибку в огромном проекте практически невозможно.

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

Дебаг в Angular вообще требует другого подхода. Нужно уметь думать деревьями, и с непривычки это занимает время.

И ещё одна «особенность», которую уже затрагивал выше, — минимум три файла там, где в React хватило бы одного. Например, маленький компонент-иконка, который просто рендерит SVG, — это три файла в Angular. Можно, конечно, сделать инлайн-шаблон и обойтись одним, но это считается плохой практикой, и на код-ревью об этом напомнят. Поначалу это ощущается как бюрократия, но потом привыкаешь, и это уже просто порядок.

Тем, кто думает попробовать

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

Angular обучает этим паттернам на знакомой территории фронтенда. Поработав год на Angular, открываешь Spring Boot и чувствуешь: «О, это же примерно то же самое, только на Java» (я несколько упрощаю, но суть именно такая).

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

По материалам — я начинал с курсов Ивана Чернякова. Они на русском, довольно практические и, главное, не пытаются объяснить весь Angular за выходные. Потом перешёл к официальной документации Angular, особенно важен раздел Overview. Но его надо читать прям вдумчиво и медленно, потому что там каждый абзац помогает понять концепцию.