Angular

Усе вирішено — свідомо

Почати проєкт на React означає обрати маршрутизатор, шар даних, бібліотеку форм, підхід до стилів і збірку ще до першої фічі. Почати проєкт на Angular означає виконати одну команду й отримати все це — обране, інтегроване й версійоване разом. Чи звучить це як полегшення, чи як клітка — і є чесною перевіркою, чи пасує вам цей фреймворк.

Наслідок, що важить у роках, а не тижнях, — однорідність. Дві бази на Angular, написані різними командами, суттєво схожі, бо фреймворк ухвалив у них ті самі рішення. Інженер, що переходить між ними, швидко стає продуктивним, а посібник з оновлення від команди Angular стосується саме вашого проєкту, а не гіпотетичного: CLI постачає автоматичні міграції, що переписують ваш код під кожну мажорну версію, — і це справді незвична відповідальність для фреймворку.

Впровадження залежностей — це хребет

Компонент не створює те, що йому потрібно; він оголошує потребу, а фреймворк надає екземпляр. На практиці це означає, що клас просить HttpClient чи UserService у конструкторі й отримує його, не знаючи, звідки той узявся й хто ще ним користується.

Виграш — у підміні. Тест замінює справжній HTTP-клієнт підробкою зміною одного провайдера, а не патчем імпорту модуля. Компоненту, що пише в лог через впроваджений логер, можна дати інший у іншому середовищі. А оскільки інжектор ієрархічний, сервіс, наданий у корені, є синглтоном на весь застосунок, а наданий на компоненті — створюється заново для кожного екземпляра цього компонента й знищується разом із ним. Саме так віджету дають власний ізольований стан, не вигадуючи механізму областей.

Ціна — опосередкованість. Читаючи компонент, ви бачите, від чого він залежить, але не бачите, яка реалізація прийде, і щоб це відстежити, треба розуміти ієрархію інжекторів над ним. Це той самий компроміс, що й у будь-якому DI-контейнері: він вартий того, коли підміна справді використовується, і дорогий, коли ні. Сервіс, впроваджений в одному місці й ніде не замінений, не дав вам нічого і зробив код на один стрибок важчим для читання.

Як фреймворк знаходить, що робити

Angular має вирішувати, коли перевіряти шаблон компонента проти його даних. Історично він відповідав на це через zone.js — бібліотеку, що патчить кожен асинхронний браузерний API: таймери, слухачі подій, XHR, — щоб фреймворк отримував сповіщення щоразу, коли будь-що завершується. За цим сповіщенням Angular обходить усе дерево компонентів і переобчислює кожен вираз у шаблонах.

Варто уточнити, чому це не настільки марнотратно, як звучить. Angular компілює шаблони заздалегідь, тож перевірка виразу є порівнянням властивостей, а не інтерпретацією, і тисячі таких перевірок швидкі. Проблемою це стає в масштабі та в специфічних формах: велике дерево, шаблон, що викликає функцію на кожній перевірці, або подія, яка сипле безперервно, як скрол чи рух миші.

Перша відповідь — OnPush, і схема показує, що він дає. Компонент, позначений OnPush, перевіряється заново лише коли один із його входів змінюється за посиланням, коли всередині нього стається подія або коли емітить observable, який він рендерить через async pipe. Усе інше пропускається разом із піддеревом. Це перетворює ціну з «розміру застосунку» на «глибину шляху до зміни» — але лише якщо входи замінюють, а не змінюють на місці, і тому OnPush та незмінні оновлення завжди приходять разом.

Сигнали — знати замість перевіряти

Сигнали знімають це питання зовсім. Сигнал — це значення, що запам’ятовує, хто його прочитав, точно як реактивність у Vue: computed() виводиться з інших сигналів і перераховується лише коли ті змінюються, а шаблон, що читає сигнал, реєструє себе споживачем саме цього значення. Коли сигнал задають, Angular не має нічого перевіряти — він знає, які шаблони від нього залежать.

Практичний наслідок: zone.js стає необов’язковим. Zoneless-застосунок на Angular везе менше JavaScript, більше не патчить асинхронні API браузера й робить строго менше роботи на кожну взаємодію. Для нового коду порада проста: беріть сигнали для стану компонента, computed для всього похідного від нього, а effect сприймайте так само, як React сприймає useEffect, — як запасний вихід для синхронізації із зовнішнім світом, а не як місце для логіки.

RxJS: де допомагає, а де шкодить

RxJS моделює значення, що приходить багато разів, — потік — і дає оператори, щоб ці потоки перетворювати, поєднувати, затримувати й скасовувати. Angular використовує його для HTTP-відповідей, подій маршрутизатора та змін значень форм, тож ви зустрінете його незалежно від того, чи шукали.

Свою складність він справді виправдовує в координації в часі: пошук із підказками, що робить debounce вводу, скасовує попередній запит при новому натисканні, ігнорує відповіді, що прийшли не по порядку, і повторює спробу при збої. Це чотири оператори й приблизно шість рядків, а написати таке руками — це тридцять рядків із багом у скасуванні. Ніщо інше у фронтенд-інструментарії не робить цього так само добре.

Шкодить він тоді, коли його беруть для значення, яке буває по одному за раз. BehaviorSubject із поточним користувачем — це потік з одного елемента, загорнутий у механізм, розрахований на багато, і кожен споживач тепер має підписуватися, відписуватися й обробляти початковий стан. Для такої форми краще пасують сигнали, і ці двоє співіснують свідомо: сигнали для стану, RxJS для подій у часі, з помічниками для перетворення між ними.

Angular проти React

Вибір рідко буває технічним. Angular пасує організації з багатьма командами, довгоживучими продуктами й плинністю кадрів, де мати одну відповідь на питання цінніше, ніж мати найкращу відповідь на кожне. React пасує команді, яка хоче зібрати власний стек і здатна нести відповідальність за його підтримку. Обидва будують ті самі застосунки; різниця в тому, хто ухвалює рішення і хто з ними живе.

Як це виявляється в реальній поставці

Репутація Angular як важкого стосується переважно перших двох тижнів. Навантаження понять справді зсунуте на початок — DI, декоратори, модулі чи standalone-імпорти, RxJS, виявлення змін, — і розробник, що працював лише з React, буде повільнішим два тижні. Купує це те, що п’ятий рік схожий на перший: фреймворк оновлює сам себе міграціями, структура однакова між командами, а розробник, що приходить у восьмирічну базу на Angular, знаходить конвенції, які вже знає.

Єдине, що варто перевірити перед упровадженням сьогодні, — який саме Angular вчить ваша команда. Існує чимало матеріалів про NgModules, виявлення змін на зонах і стан на BehaviorSubject — підхід робочий, але фреймворк від нього пішов. Почати проєкт у старому стилі у 2026 році означає написати код, про який буде наступний посібник із міграції.

Де він вироджується

• Підписки без відписки тримають живими знищені компоненти і їхній DOM.
• Виклики функцій у шаблонах перезапускаються на кожному проході виявлення змін, а не при зміні даних.
• OnPush разом зі зміною входів на місці: компонент не оновлюється й виглядає випадково зламаним.
• RxJS для одиничних значень загортає змінну в механізм підписок.
• Вкладені підписки замість switchMap повертають ті перегони, які оператор і мав прибрати.
• Сервіси в корені, що тримають стан одного екрана, переживають навігацію й протікають між його відвідуваннями.
• Новий код у стилі NgModule і зон — це предмет наступної міграції.

Коли це застосовувати

Пов’язані сторінки

• РозробкаReactReact — це бібліотека для опису того, як має виглядати інтерфейс за поточного стану, з тим, щоб хтось інший з’ясував, як довести до цього DOM. Модель уміщається в рядок — інтерфейс є функцією стану, — і майже всі складнощі з React походять із її порушення: нечистої роботи під час рендеру або стану, що лежить там, де не може бути джерелом правди.
• РозробкаVueVue — це фреймворк, побудований навколо системи реактивності, яка стежить за тим, що читає ваш код. Ви не оголошуєте залежностей і не кажете, що змінилося: читання значення під час рендеру реєструє цей рендер як залежний, а запис значення перезапускає рівно цих залежних. Більшість того, що вирізняє Vue на практиці, випливає з цього одного механізму.
• РозробкаJavaScriptJavaScript — це мова, яку виконує кожен браузер, і та, яку більшість вчить із синтаксису й ніколи — із семантики. Майже все, що здається в ній довільним, випливає з одного факту: ваш код виконується в одному потоці з одним стеком викликів, а все асинхронне — це черга, що чекає, доки стек спорожніє. На цій сторінці — цикл подій, посилання, замикання, модулі й те, де обробка помилок в асинхронному коді тихо провалюється.