Angular v20: Архитектура будущего и современные стандарты разработки

Новая эра архитектуры: Standalone Components и декларативный Control Flow

Добро пожаловать в курс «Angular v20: Архитектура будущего». Мы начинаем наше погружение с фундаментальных изменений, которые полностью переопределили способ написания приложений на Angular. Если вы помните времена, когда каждое приложение начиналось с создания AppModule, а добавление компонента требовало регистрации в трех разных местах — забудьте это как страшный сон. Angular v20 (и предшествующие ему современные версии) ставит во главу угла простоту, производительность и эргономику разработчика.

В этой статье мы разберем два кита современной архитектуры: Standalone Components (автономные компоненты) и новый Built-in Control Flow (встроенный управляющий поток).

Смерть NgModules и рождение Standalone Components

Долгое время Angular считался «сложным» фреймворком именно из-за системы модулей (NgModules). Модули создавали дополнительный слой абстракции между компонентами, который часто запутывал зависимости и усложнял ленивую загрузку (lazy loading).

Что такое Standalone Component?

Standalone Component — это компонент, который не требует объявления в NgModule. Он самодостаточен. Он сам знает, какие зависимости ему нужны для работы (другие компоненты, директивы или пайпы), и объявляет их прямо в своем декораторе.

!Визуальное сравнение старой модульной системы и современной архитектуры автономных компонентов

Как это выглядит в коде?

В современных версиях Angular (начиная с v19 и переходя в v20) все компоненты, генерируемые через CLI, являются standalone по умолчанию. Однако, чтобы понять суть, давайте посмотрим на структуру:

Обратите внимание на ключевые отличия:

Флаг standalone: true: Указывает Angular, что этот компонент не нуждается в модуле (в v20 это поведение по умолчанию, флаг можно опускать, но концепция остается).

Массив imports: Раньше мы импортировали зависимости в модуле. Теперь мы делаем это прямо в компоненте. Если UserProfileComponent использует UserCardComponent в своем шаблоне, он обязан добавить его в imports.

Преимущества нового подхода

Меньше шаблонного кода (Boilerplate): Вам больше не нужно создавать файл .module.ts для каждой фичи. * Упрощенное обучение: Новичкам проще понять связь «компонент А использует компонент Б», чем разбираться в иерархии модулей. * Улучшенный Tree-shaking: Сборщику (bundler) гораздо проще понять, какой код действительно используется, а какой можно выкинуть из финального бандла, так как связи явные и прямые.

Декларативный Control Flow

Второе глобальное изменение касается того, как мы пишем логику внутри HTML-шаблонов. Раньше мы использовали структурные директивы: ngIf, ngFor и *ngSwitch. Они работали, но имели свои недостатки: зависимость от CommonModule, сложность типизации и неочевидный синтаксис для новичков.

Angular v20 стандартизирует новый синтаксис, встроенный прямо в компилятор шаблонов. Он начинается с символа @.

Условный рендеринг: @if

Забудьте о *ngIf. Новый синтаксис интуитивно понятен любому, кто знаком с JavaScript.

Было (Legacy):

Стало (Modern):

Это не просто «сахар». Это конструкция языка шаблонов. Она не требует импорта модулей и работает быстрее.

Циклы: @for

Самое значительное улучшение производительности произошло в циклах. Старый *ngFor часто вызывал проблемы с перерисовкой DOM, если разработчик забывал функцию trackBy.

В новом синтаксисе @for использование трекинга (отслеживания уникальности элементов) стало обязательным. Это гарантирует, что Angular будет перерисовывать только изменившиеся элементы списка, а не весь список целиком.

html @switch (user.status) { @case ('active') { <active-icon /> } @case ('pending') { <pending-icon /> } @default { <unknown-icon /> } } html @defer (on viewport) { <heavy-chart-component /> } @placeholder { <div>Загрузка графика...</div> } @loading { <spinner /> } @error { <div>Не удалось загрузить график</div> } typescript // app.routes.ts export const routes: Routes = [ { path: 'admin', loadComponent: () => import('./admin/admin.component').then(m => m.AdminComponent) } ]; ```

Заключение

Angular v20 — это фреймворк, который сбросил лишний вес. Standalone Components убрали необходимость в сложной ментальной модели модулей, а декларативный Control Flow сделал шаблоны чище, безопаснее и производительнее.

В следующих статьях курса мы углубимся в Signals — новую реактивную модель, которая работает в синергии с этими архитектурными изменениями, обеспечивая гранулярное обновление интерфейса без Zone.js.

Реактивность нового поколения: глубокое погружение в Angular Signals и интеграция с RxJS

В предыдущей статье мы рассмотрели, как Standalone Components и новый Control Flow изменили статическую структуру и шаблоны наших приложений. Теперь пришло время заглянуть «под капот» и поговорить о движке, который приводит всё это в движение. Речь пойдет об управлении состоянием и реактивности.

Angular v20 окончательно закрепляет Signals (Сигналы) как стандарт де-факто для хранения локального состояния и синхронизации данных. Если раньше мы полагались на магию Zone.js и мощь (но сложность) RxJS для всего подряд, то теперь у нас есть специализированный примитив, который делает приложения быстрее, а код — понятнее.

Проблема Zone.js и необходимость перемен

Чтобы понять, зачем нам Сигналы, нужно вспомнить, как Angular работал годами. Механизм Zone.js перехватывал асинхронные события (клики, таймеры, HTTP-запросы) и сообщал фреймворку: «Что-то случилось, проверь всё дерево компонентов на изменения».

Этот подход работал надежно, но имел два недостатка:

Производительность: Проверка всего дерева (или больших его частей) затратна, даже если изменилась одна переменная.

Неочевидность: Разработчику трудно понять, что именно вызвало перерисовку.

!Сравнение глобальной проверки изменений Zone.js и точечной реактивности Signals

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

Анатомия Сигнала

Signal — это обертка вокруг значения, которая может уведомлять заинтересованных потребителей (Consumers) об изменении этого значения. Сигналы синхронны. В любой момент времени вы можете получить текущее значение сигнала, не подписываясь на него через .subscribe().

Writable Signals (Записываемые сигналы)

Самый простой тип сигнала. Вы можете менять его значение напрямую.

Обратите внимание: чтение сигнала всегда происходит через вызов функции count(). Это позволяет Angular отследить, где этот сигнал был прочитан, и создать зависимость.

Computed Signals (Вычисляемые сигналы)

Это сигналы, которые зависят от других сигналов. Они являются read-only (только для чтения) и обновляются автоматически, когда меняются их зависимости.

Ключевые особенности computed:

Ленивость (Lazy): Значение не пересчитывается, пока его кто-то не прочитает (например, шаблон).

Мемоизация: Если зависимости не изменились, повторное чтение вернет кэшированное значение без пересчета.

Динамические зависимости: Если внутри computed есть условная логика (if), Angular будет отслеживать только те сигналы, которые участвовали в последнем вычислении.

Effects (Эффекты)

Иногда нам нужно не новое значение, а действие: логирование, запись в localStorage или вызов сторонней библиотеки. Для этого используется effect.

В шаблоне больше не нужен AsyncPipe. Мы просто пишем @for (user of users(); track user.id).

#### toObservable: Из Signal в Observable

Используется, когда изменение состояния должно инициировать сложный асинхронный процесс.

Signal-based Inputs и Queries

В Angular v20 классические декораторы @Input и @Output считаются устаревающими (хотя и поддерживаются). На смену им пришли функции-сигналы.

Новые Inputs

Преимущества:

Типизация: input.required гарантирует, что вы не забудете передать значение.

Реактивность: input — это сигнал. Вы можете использовать его в computed или effect без ngOnChanges.

Model Inputs (Двустороннее связывание)

Для реализации [(value)]="val" теперь используется model().

Когда дочерний компонент вызывает counter.set(5), значение автоматически обновляется и в родителе.

Будущее без Zone.js (Zoneless)

Главная цель внедрения Signals — возможность отключить Zone.js. В Angular v20 вы можете включить экспериментальный режим zoneless.

В этом режиме Angular не патчит браузерные события. Вместо этого, он полагается только на сигналы. Когда вы обновляете сигнал (count.set(1)), Angular получает уведомление и планирует обновление только тех компонентов, которые используют этот сигнал.

Это приводит к: * Уменьшению размера бандла (минус ~100KB Zone.js). * Улучшению производительности при старте приложения. * Более понятным Stack Traces при отладке.

Заключение

Signals — это не просто новый синтаксис, это смена парадигмы. Мы переходим от модели «проверь всё на всякий случай» к модели «обнови только то, что изменилось».

Краткое резюме: * Используйте signal() для локального состояния. * Используйте computed() для производных данных. * Используйте toSignal() для работы с асинхронными источниками (RxJS). * Переходите на input() и model() вместо декораторов.

В следующей части курса мы разберем Server-Side Rendering (SSR) и Hydration, где увидим, как сигналы помогают мгновенно «оживлять» HTML, пришедший с сервера.

Серверный рендеринг и гидратация: стратегии SSR, SSG и Partial Hydration

В предыдущих статьях мы разобрали, как Standalone Components упростили структуру приложений, и как Signals изменили подход к реактивности, сделав её гранулярной. Теперь пришло время объединить эти знания, чтобы понять, как Angular v20 решает одну из самых сложных задач веб-разработки — доставку контента пользователю максимально быстро и эффективно.

Мы поговорим о Server-Side Rendering (SSR), Static Site Generation (SSG) и революционной технологии Partial Hydration (частичная гидратация), которая стала возможной именно благодаря Сигналам и новому Control Flow.

Эволюция рендеринга: от пустого экрана к мгновенному контенту

Чтобы оценить мощь современных инструментов, нужно вспомнить, с чего мы начинали. Классическое SPA (Single Page Application) работает по принципу Client-Side Rendering (CSR).

Проблема CSR

Пользователь заходит на сайт.

Браузер скачивает пустой index.html.

Браузер скачивает огромный JavaScript-бандл.

Браузер выполняет JS, строит DOM-дерево.

Только теперь пользователь видит контент.

Этот процесс создает задержку (Time to First Contentful Paint), которая критична для SEO и удержания пользователей на мобильных устройствах.

Решение: SSR и SSG

Angular предлагает два подхода для решения этой проблемы:

* SSR (Server-Side Rendering): HTML генерируется на сервере (Node.js) для каждого запроса. Идеально для динамических данных (личный кабинет, лента новостей). * SSG (Static Site Generation): HTML генерируется один раз во время сборки (Build time). Идеально для блогов, документации и маркетинговых страниц.

В обоих случаях пользователь получает готовый HTML мгновенно. Но здесь в игру вступает Гидратация.

Что такое Гидратация?

Гидратация (Hydration) — это процесс, при котором клиентский JavaScript «оживляет» статический HTML, пришедший с сервера. Фреймворк привязывает обработчики событий (клики, ввод текста) к уже существующим элементам DOM и восстанавливает состояние приложения.

Эра деструктивной гидратации (прошлое)

До недавнего времени (до Angular v16) гидратация работала грубо. Angular получал HTML с сервера, но не мог его переиспользовать. Он удалял весь DOM и создавал его заново с нуля. Это вызывало: * Мерцание экрана. * Двойную нагрузку на браузер.

Non-Destructive Hydration (современный стандарт)

Начиная с v16 и окончательно закрепившись в v20, Angular использует недеструктивную гидратацию. Фреймворк видит существующий DOM, сверяет его со своей внутренней структурой и просто «подключается» к нему, не перерисовывая пиксели. Это происходит мгновенно и незаметно для глаза.

Partial Hydration: Святой Грааль производительности

Самое важное нововведение Angular v20 — это Partial Hydration (Частичная гидратация).

Представьте страницу интернет-магазина. На ней есть:

Шапка и подвал (статичные ссылки).

Описание товара (статичный текст).

Галерея изображений (интерактивная).

Кнопка «Купить» (интерактивная).

Блок отзывов (загружается по скроллу).

Зачем нам загружать JavaScript для шапки, подвала и текста, если они не меняются? Раньше мы были обязаны гидратировать всю страницу целиком. Теперь — нет.

!Слева: Полная гидратация загружает JS для всей страницы. Справа: Частичная гидратация оживляет только интерактивные зоны.

Как это работает?

Partial Hydration опирается на блок @defer, который мы изучили в первой статье. Angular анализирует шаблон и понимает: «Этот кусок кода находится внутри @defer, значит, его не нужно загружать и гидратировать сразу».

В Angular v20, благодаря Signals, этот процесс стал еще умнее. Поскольку сигналы точно знают, где используются данные, Angular может пропускать гидратацию компонентов, которые не имеют интерактивности и реактивных зависимостей, даже без явного использования @defer.

Event Replay: Ни один клик не потерян

Одна из частых проблем SSR: пользователь видит кнопку, нажимает на неё, но ничего не происходит, потому что JavaScript еще не загрузился (гидратация не завершена).

Angular v20 решает это с помощью технологии Event Replay (Воспроизведение событий).

В HTML, который отдает сервер, встроен крошечный скрипт.

Этот скрипт «слушает» события на корневом уровне.

Если пользователь кликает по кнопке до гидратации, скрипт запоминает этот клик.

Как только Angular загружается, он «проигрывает» записанные события.

Результат: пользователь чувствует, что приложение работает мгновенно, хотя на самом деле JS подгрузился на секунду позже.

Настройка в коде

В современном Angular (Standalone API) настройка SSR и гидратации происходит в файле app.config.ts. Вам больше не нужно править сложные модули.

Функция provideClientHydration сообщает Angular, что приложение будет запущено поверх серверного HTML. Флаги withEventReplay и withIncrementalHydration активируют продвинутые возможности v20.

Стратегии рендеринга: что выбрать?

Теперь, когда у нас есть весь арсенал, давайте структурируем выбор стратегии.

| Стратегия | Описание | Когда использовать | | :--- | :--- | :--- | | CSR (Client-Side) | Рендеринг только в браузере. | Админ-панели, закрытые приложения, где SEO не важно. | | SSR (Server-Side) | Рендеринг на сервере при каждом запросе. | Новостные порталы, соцсети, персонализированная выдача. | | SSG (Static Generation) | Рендеринг при сборке (Build). | Блоги, лендинги, документация, страницы «О нас». | | Hybrid | Комбинация SSR и SSG. | Интернет-магазин: каталог — SSG, корзина — CSR/SSR. |

Angular v20 позволяет смешивать эти стратегии. Вы можете настроить роутер так, чтобы одни страницы пре-рендерились (SSG), а другие рендерились на лету (SSR).

Влияние на Core Web Vitals

Внедрение SSR и Partial Hydration напрямую влияет на метрики, по которым Google оценивает ваш сайт:

LCP (Largest Contentful Paint): Улучшается, так как пользователь сразу видит готовую картинку, не ожидая JS.

CLS (Cumulative Layout Shift): Улучшается, так как HTML структура стабильна и не «прыгает» при загрузке данных.

INP (Interaction to Next Paint): Улучшается благодаря Partial Hydration и Event Replay — браузер не блокируется гигантским скриптом гидратации.

Заключение

Angular v20 превращает SSR из «сложной опции для экспертов» в стандарт по умолчанию. Благодаря синергии Standalone Components (модульность), Signals (точное знание зависимостей) и Partial Hydration (загрузка только нужного), мы можем создавать приложения, которые загружаются мгновенно, как статические сайты, но обладают всей интерактивностью мощных SPA.

В следующей, заключительной части курса, мы рассмотрим инструменты сборки Esbuild и Vite, а также продвинутые техники оптимизации бандлов, чтобы закрепить успех нашей архитектуры.

Оптимизация производительности: Deferrable Views, Esbuild и ускорение загрузки приложений

Мы подошли к четвертой части нашего курса «Angular v20: Архитектура будущего». В предыдущих статьях мы построили надежный фундамент: перешли на Standalone Components, внедрили гранулярную реактивность с Signals и настроили мгновенную доставку контента через SSR и Partial Hydration.

Однако, даже самая архитектурно правильная система может страдать от большого размера бандла (bundle size) и медленной загрузки ресурсов. В современном вебе каждая миллисекунда задержки стоит вам пользователей. Angular v20 предоставляет мощнейший набор инструментов для борьбы за производительность: от встроенного в шаблон отложенного рендеринга до сверхбыстрой системы сборки.

В этой статье мы разберем, как заставить ваше приложение «летать», используя Deferrable Views, новый билдер на базе Esbuild и оптимизацию изображений.

Deferrable Views: Революция в ленивой загрузке

Долгое время ленивая загрузка (Lazy Loading) в Angular была неразрывно связана с маршрутизацией (Router). Вы могли загрузить лениво целую страницу, но загрузить лениво отдельный компонент внутри страницы было нетривиальной задачей, требующей динамических импортов и ручного управления состоянием загрузки.

С появлением Deferrable Views (откладываемые представления) эта сложность исчезла. Теперь ленивая загрузка — это часть синтаксиса шаблона.

Синтаксис @defer

Блок @defer позволяет вам декларативно указать часть шаблона, которая не должна загружаться сразу. Angular автоматически выделит компоненты внутри этого блока в отдельный JavaScript-файл (чанк) и загрузит его только тогда, когда сработает определенный триггер.

!Жизненный цикл откладываемого представления: от заглушки до контента

Базовая структура выглядит так:

Разберем ключевые блоки:

@defer: Основной блок. Контент внутри него (в данном случае <heavy-chart-component />) не попадет в основной бандл приложения.

@placeholder: То, что пользователь видит до начала загрузки. Это критически важно для предотвращения сдвигов макета (CLS — Cumulative Layout Shift). Параметр minimum гарантирует, что заглушка не исчезнет слишком быстро, предотвращая мерцание.

@loading: То, что пользователь видит во время загрузки чанка по сети. Параметр after позволяет не показывать спиннер, если загрузка произошла мгновенно (например, из кэша).

@error: Отображается, если сеть недоступна или скрипт не удалось загрузить.

Магия триггеров

Самое мощное в @defer — это триггеры. Они определяют, когда начинать загрузку. В Angular v20 доступен широкий набор встроенных триггеров:

* on idle: (По умолчанию) Загрузка начнется, когда браузер будет простаивать (используется requestIdleCallback). Идеально для некритичного контента ниже первого экрана. * on viewport: Загрузка начнется, когда плейсхолдер попадет в видимую область экрана. Лучший выбор для длинных лент и списков. * on interaction: Загрузка начнется при взаимодействии (клик, фокус) с плейсхолдером. Например, загрузка тяжелого редактора текста только при клике на поле ввода. * on hover: Загрузка при наведении мыши. * on immediate: Загрузка начнется сразу после того, как отрендерится основной шаблон (но асинхронно, не блокируя UI). * on timer(5s): Загрузка через заданное время.

Вы также можете комбинировать триггеры или использовать свои условия:

Prefetching (Предзагрузка)

Иногда мы хотим загрузить код заранее, но отобразить его только по действию пользователя. Для этого используется prefetch.

В этом примере код <heavy-modal /> начнет скачиваться, когда пользователь наведет мышь на кнопку (prefetch on hover). Но сам компонент отобразится и инициализируется только при клике (on interaction). Это создает ощущение мгновенной работы интерфейса.

Esbuild и Vite: Новое сердце Angular CLI

Если @defer оптимизирует работу приложения в браузере (Runtime), то переход на Esbuild оптимизирует жизнь разработчика (Build time).

Долгое время Angular использовал Webpack. Это надежный, но медленный инструмент. В Angular v20 стандартом стал новый application builder, основанный на двух технологиях:

Esbuild: Сборщик, написанный на языке Go. Он компилирует код в 10-50 раз быстрее, чем инструменты на JS, благодаря параллелизму и нативному коду.

Vite: Используется в режиме разработки (ng serve). Vite обеспечивает мгновенный запуск дев-сервера и HMR (Hot Module Replacement). Когда вы меняете стиль или компонент, изменения применяются в браузере мгновенно без перезагрузки страницы.

Как убедиться, что вы используете новый билдер?

Загляните в angular.json. В секции architect -> build -> builder должно быть указано:

Если там написано browser, вы используете устаревший Webpack-билдер. Переход на application не только ускорит сборку, но и автоматически включит поддержку SSR (если нужно) и улучшенную оптимизацию CSS.

Преимущества для производительности

* Меньший размер бандла: Esbuild эффективнее удаляет неиспользуемый код (Tree-shaking). * Быстрый CI/CD: Время сборки на серверах интеграции сокращается в разы, что экономит деньги и время команды. * Улучшенная отладка: Vite предоставляет более понятные сообщения об ошибках.

Оптимизация изображений с NgOptimizedImage

Изображения часто составляют большую часть веса страницы и являются главной причиной плохих показателей LCP (Largest Contentful Paint) и CLS (Cumulative Layout Shift).

Обычный тег <img> в браузере работает неоптимально: он загружает картинку сразу, даже если она далеко внизу, и может вызывать сдвиги макета при загрузке.

Angular v20 предлагает директиву NgOptimizedImage, которая решает эти проблемы автоматически.

Как использовать

Импортируйте NgOptimizedImage в компонент (или добавьте в imports для standalone).

Замените src на ngSrc.

Что делает эта директива?

Автоматический Lazy Loading: Все картинки без атрибута priority загружаются лениво (когда приближаются к области просмотра).

Приоритезация LCP: Если вы добавите атрибут priority к главному изображению (например, баннеру), Angular добавит специальные теги preload в <head>, чтобы браузер начал качать эту картинку раньше всего остального.

Предотвращение CLS: Директива требует указывать width и height. Это гарантирует, что браузер зарезервирует место под картинку до её загрузки, и контент не будет «прыгать».

Автоматический srcset: Если вы используете CDN (Image Loader), директива сама сгенерирует ссылки на разные размеры картинки (1x, 2x, мобильные версии), чтобы пользователь не качал 4K изображение на телефон.

Бюджеты производительности (Performance Budgets)

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

В файле angular.json вы можете задать лимиты:

Если начальный бандл превысит 1 МБ, сборка упадет с ошибкой. Это отличная практика для командной разработки, не позволяющая производительности деградировать незаметно.

Заключение

Angular v20 предоставляет разработчику полный контроль над производительностью:

Deferrable Views позволяют дробить приложение на мелкие части и загружать их только по требованию, используя интуитивный синтаксис @defer.

Связка Esbuild + Vite обеспечивает молниеносную сборку и комфортную разработку.

NgOptimizedImage берет на себя сложную работу по доставке медиа-контента, улучшая метрики Core Web Vitals.

Используя эти инструменты вместе с Signals и SSR, вы создаете приложения, которые не просто работают, а доставляют удовольствие пользователям своей отзывчивостью.

На этом наш курс «Angular v20: Архитектура будущего» завершен. Мы прошли путь от базовых концепций Standalone до продвинутых техник оптимизации. Теперь у вас есть все знания, чтобы строить современные, быстрые и масштабируемые веб-приложения мирового уровня.

Продвинутая экосистема: типизированные формы, маршрутизация и современные подходы к тестированию

Мы подошли к финальной части нашего курса «Angular v20: Архитектура будущего». Мы уже научились создавать молниеносные приложения с помощью Standalone Components, управлять состоянием через Signals и оптимизировать доставку контента посредством SSR и Deferrable Views.

Однако профессиональная разработка — это не только скорость рендеринга. Это надежность ввода данных, удобство навигации и уверенность в том, что код работает корректно. В этой статье мы разберем три столпа, которые делают Angular-приложения по-настоящему промышленными: Strict Typed Forms (Строго типизированные формы), Modern Router Features (Современные возможности маршрутизации) и Next-Gen Testing (Тестирование нового поколения).

Строгая типизация форм: конец эпохи any

Долгое время формы в Angular были «черным ящиком» для TypeScript. Когда вы создавали FormGroup, все значения внутри трактовались как any. Это приводило к глупым ошибкам: вы могли попытаться вызвать метод .toUpperCase() у числового поля, и компилятор молчал, пока приложение не падало в браузере.

В современной экосистеме Angular формы полностью типизированы. Это означает, что структура вашей формы известна на этапе написания кода.

Как это выглядит?

Рассмотрим пример формы регистрации. Теперь мы явно указываем типы для каждого контрола.

!Визуализация преимущества строгой типизации: хаос типов any против упорядоченной структуры Typed Forms

NonNullableFormBuilder

Частая проблема форм — значение null. По умолчанию, если вы сбросите контрол (reset()), он станет null. Но часто нам нужно, чтобы строка сбрасывалась в пустую строку ''.

Для этого используется NonNullableFormBuilder (или опция nonNullable: true).

Это избавляет нас от бесконечных проверок if (value !== null) в коде.

Маршрутизация: Component Input Binding

Роутер Angular всегда был мощным, но работа с параметрами URL часто требовала много шаблонного кода (boilerplate). Вспомните, как мы делали это раньше:

Импортировали ActivatedRoute.

Подписывались на params или queryParams.

Вручную извлекали данные и присваивали их переменным.

Не забывали отписываться (или использовать AsyncPipe).

В Angular v20 стандартом является Component Input Binding (Привязка данных роутера к инпутам компонента). Роутер теперь умеет передавать параметры URL, query-параметры и данные resolve напрямую во входные свойства (@Input) компонента.

Настройка

Сначала нужно включить эту функцию в конфигурации приложения (app.config.ts):

Использование в компоненте

Представьте маршрут product/:id.

Это делает компоненты чище и независимее от самого роутера. Такой компонент легче тестировать: вы просто передаете ему id как обычный Input, не создавая моков для ActivatedRoute.

View Transitions API

Еще одна современная фишка — интеграция с нативным View Transitions API браузера. Это позволяет создавать плавные анимации перехода между страницами без сложных библиотек анимации.

Достаточно добавить withViewTransitions() в провайдер роутера, и Angular будет автоматически делать «снэпшот» старой страницы и плавно перетекать в новую. Браузер сам интерполирует состояние DOM-элементов.

Тестирование нового поколения

Тестирование в Angular долгое время ассоциировалось с болью: медленный Karma, сложная настройка TestBed и хрупкие тесты, которые ломаются при малейшем изменении верстки.

Современный подход решает эти проблемы с помощью двух инструментов: Component Test Harnesses и новых раннеров (Web Test Runner / Jest / Vitest).

Component Test Harnesses (Обвязки)

Это концепция, пришедшая из Angular Material, но теперь доступная для всех. Harness — это класс-посредник, который позволяет тесту взаимодействовать с компонентом через API, а не через CSS-селекторы.

Проблема старого подхода:

Если вы переименуете класс .submit-btn или замените <button> на <a>, тест упадет, хотя логика не изменилась.

Решение с Harness:

Вы создаете Harness для своих переиспользуемых компонентов. Если верстка компонента меняется, вы правите только его Harness, а сотни тестов, использующих этот компонент, остаются зелеными.

!Harness как защитный слой между тестом и реализацией DOM

Отказ от Karma

Karma, верой и правдой служившая нам годами, официально объявлена устаревшей (deprecated). Angular v20 предлагает использовать современные, быстрые раннеры.

В angular.json теперь можно настроить билдер на базе Web Test Runner или Jest (экспериментальная поддержка). Это дает: * Более быстрый запуск тестов. * Лучшую интеграцию с современными IDE. * Меньшее потребление памяти.

Тестирование Signals

С приходом Signals изменился и подход к тестированию реактивности. Поскольку эффекты (effect()) выполняются асинхронно, в тестах иногда нужно принудительно «проталкивать» изменения.

Для этого TestBed предоставляет метод flushEffects().

Заключение курса

Поздравляем! Вы прошли путь от основ новой архитектуры до продвинутых техник оптимизации и тестирования.

Давайте оглянемся назад на то, что составляет Angular v20:

Standalone Components: Модульность без модулей. Простая и понятная структура.

Signals: Реактивность, которая понятна человеку и эффективна для машины. Отказ от Zone.js в перспективе.

Control Flow: Встроенный синтаксис @if, @for, @defer для чистых шаблонов.

SSR & Hydration: Мгновенная загрузка и SEO из коробки с частичной гидратацией.

Esbuild & Vite: Сверхбыстрая сборка.

Ecosystem: Типизированные формы, удобный роутинг и стабильные тесты.

Angular прошел долгий путь трансформации. Из «тяжелого энтерпрайз-фреймворка» он превратился в современный, быстрый и гибкий инструмент, который одинаково хорош и для маленького стартапа, и для банковской системы.

Будущее уже здесь. И теперь у вас есть все инструменты, чтобы строить его.