Знайомтеся з Angular v19! - javascript.org.ua

Протягом останніх двох років ми значно збільшили інвестиції у вдосконалення досвіду розробників (Developer Experience) та продуктивності. У кожному релізі ми послідовно впроваджували покращення, які у поєднанні помножують свій ефект. Позитивна реакція спільноти та зростання активності на наших заходах для розробників (Developer Events) підтверджують, що ми рухаємося у правильному напрямку.

Сьогоднішній реліз приносить низку покращень, які зроблять створення швидких веб-додатків ще простішим та впевненішим.

Основні моменти:

Попередній перегляд для розробників (Developer Preview) інкрементальної гідрації (Incremental Hydration), яка підтримує найвимогливіші сценарії продуктивності.
Можливість керувати, які маршрути рендеряться на клієнті (Client), сервері (Server) або під час білду (Build), а також вирішувати параметри маршруту під час попереднього рендерингу (Prerendering).
Схеми (Schematics), які допомагають залишатися в курсі сучасних найкращих практик: введення (Inputs), виведення (Outputs), запити (Queries), ін’єкційно-орієнтована залежність (Inject-based Dependency Injection) та нова система зборки (Build System).
Стабілізація основних реактивних примітивів (Reactivity Primitives) та введення нових: linkedSignal та resource.
Серія покращень для зручності роботи, які враховують запити функцій з понад 2,700 👍 на GitHub! Це включає компонент для вибору часу (Time Picker Component), видалення невикористаних імпортів, запуск схем через мовний сервіс (Language Service), HMR для стилів (Hot Module Replacement), та багато іншого!

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

Для більш повного списку функцій та покращень у версії 19 продовжуйте читати нижче.

Оптимізація швидкості

Розвиваючи Angular, ми бачимо можливість впроваджувати найкращі практики продуктивності "з коробки", щоб підтримувати ваші сценарії, чутливі до продуктивності. Протягом останніх двох років ми розпочали проєкт із впровадження Angular без зон (Zoneless Angular), зробили серверний рендеринг (Server-Side Rendering) невід'ємною частиною Angular CLI та тісно співпрацювали з Chrome Aurora над гідрацією (Hydration) та директивою зображення (Image Directive).

У версії 19 ми піднімаємо серверний рендеринг Angular на новий рівень, додаючи інкрементальну гідрацію (Incremental Hydration), конфігурацію серверних маршрутів (Server Route Configuration), повторне відтворення подій (Event Replay) за замовчуванням і багато іншого.

Створення великих веб-додатків збільшує обсяг JavaScript, який ми відправляємо користувачеві, що негативно впливає на його досвід. У версії 17 ми зробили надзвичайно простим відкладене завантаження коду (Lazy Load) для клієнтських додатків завдяки відкладеним уявленням (Deferrable Views).

Для серверно-рендерених додатків (Server-Side Rendered Applications) ми впровадили повну гідрацію додатка (Full-App Hydration), яка вимагає всього JavaScript, пов'язаного з конкретною сторінкою, щоб зробити її інтерактивною. Сьогодні ми пропонуємо рішення для сервера, натхнене відкладеними уявленнями (Deferrable Views)!

Вітаємо інкрементальну гідрацію в попередньому перегляді для розробників

Інкрементальна гідрація (Incremental Hydration) дозволяє вам анотувати частини вашого шаблону, використовуючи вже знайомий синтаксис @defer, і вказувати Angular завантажувати та гідрувати їх лише за певних умов або тригерів (Triggers), відкладено.

Демонстрація інкрементальної гідрації

На демо вище показано роботу інкрементальної гідрації для серверно-рендереної сторінки (Server-Side Rendered Page).

Ми додали три візуальні ефекти до коду демо-додатка, щоб краще проілюструвати, що відбувається:

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

Крім того, у демо-додаток (Demo App) додано штучну затримку у 500 мс для кожної операції завантаження, щоб ми могли легко дослідити різні стани.

Зверніть увагу, що на початку все, крім верхньої панелі, виглядає у градаціях сірого. Це означає, що на цьому етапі ми ще не завантажили жоден JavaScript, пов’язаний із цією сторінкою.

Коли користувач взаємодіє з компонентом фільтра (Filter Component) у верхньому лівому куті, Angular завантажує його (візуально це позначено пульсацією), а після цього виконує гідрацію (Hydration), що демонструється фіолетовим підсвічуванням навколо компонента.

Згодом ми продовжуємо взаємодію зі сторінкою і поступово виконуємо гідрацію решти компонентів.

Навіть без штучної затримки Angular буде завантажувати і гідрувати компонент асинхронно (Asynchronously), що означає необхідність повторного відтворення події користувача (Replay User Event). Для цієї функціональності ми використовуємо відтворення подій (Event Replay), яке було впроваджено у версії Angular 18 і використовується в Google Search.

Оновившись до Angular v19, ви зможете спробувати нову інкрементальну гідрацію (Incremental Hydration) у будь-якому додатку, який уже використовує SSR (Server-Side Rendering) та повну гідрацію додатка (Full Application Hydration). У вашому клієнтському завантаженні (Client Bootstrap) потрібно вказати:

import { provideClientHydration, withIncrementalHydration } from '@angular/platform-browser';  

// ...


provideClientHydration(withIncrementalHydration());

Щоб застосувати інкрементальну гідрацію (Incremental Hydration) до частини вашого шаблону, використовуйте:

@defer (гідрувати при потраплянні у вікно перегляду) {  
 \  
}

Коли ваш додаток завантажується, Angular не завантажить і не гідрує компонент кошика покупок (Shopping-Cart Component) до того моменту, поки він не потрапить у вікно перегляду (Viewport). Детальніше про інкрементальну гідрацію ви можете прочитати в документації.

Ми вдячні всім, хто поділився своїми думками в RFC по інкрементальній гідрації та нашим бета-тестерам. Дякуємо, що допомагаєте покращити Angular!

Повторне відтворення подій увімкнене за замовчуванням

Звичайною проблемою в серверно-рендерених додатках (Server-Side Rendered Apps) у будь-якому фреймворку є проміжок часу між подією користувача (User Event) та завантаженням і виконанням браузером коду, що відповідає за обробку цієї події.

Ми вже торкались цієї теми в розділі про інкрементальну гідрацію (Incremental Hydration).

Минулого травня ми поділилися бібліотекою відправки подій (Event Dispatch Library), яка вирішує цей випадок використання. Відправка подій (Event Dispatch) захоплює події під час початкового завантаження сторінки і відтворює їх, коли код, відповідальний за обробку цих подій, стає доступним. Відправка подій — це та сама бібліотека, яку команда Wiz розробила для Google Search, і вона була перевірена мільярдами користувачів протягом останніх десяти років.

Ви можете увімкнути функцію повторного відтворення подій (Event Replay) в Angular, налаштувавши ваш постачальник гідрації (Hydration Provider):

 // Для нових проєктів Angular CLI за замовчуванням генеруватиме цей код  
 bootstrapApplication(App, {  
   providers: [  
     provideClientHydration(withEventReplay())  
   ]  
 });

Результат буде схожий на візуалізацію в gif нижче.

Коли браузер вперше рендерить додаток, він ще не завантажив жодного JavaScript, що ми візуалізуємо, використовуючи сірий колір для інтерфейсу користувача (UI). Ви можете побачити, що за цей час користувач кілька разів натискає кнопку "Додати до кошика" (Add to Cart). У фоновому режимі відправка подій (Event Dispatch) записує всі ці події. Коли JavaScript, відповідальний за обробку подій натискання (Click Events), завантажується, відправка подій відтворює ці події, що відображається в кількості товарів у кошику покупок (Shopping Cart):

Демонстрація повторного відтворення подій (Event Replay)

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

Сьогодні ми переводимо повторне відтворення подій (Event Replay) на стабільний рівень і вмикаємо його за замовчуванням для всіх нових додатків, які використовують серверний рендеринг (Server-Side Rendering)!

Режим рендерингу на рівні маршруту (Route-level Render Mode)

Коли ви вмикаєте серверний рендеринг у вашому додатку, за замовчуванням Angular буде виконувати серверний рендеринг для всіх параметризованих маршрутів (Parametrized Routes) у вашому додатку та попередньо рендерити всі маршрути без параметрів.

У версії 19 ми надаємо новий інтерфейс під назвою ServerRoute, який дозволяє вам налаштувати, чи мають окремі маршрути бути серверно-рендереними, попередньо рендереними або рендеритися на клієнті:

export const serverRouteConfig: ServerRoute[] = [  
 { path: '/login', mode: RenderMode.Server },  
 { path: '/dashboard', mode: RenderMode.Client },  
 { path: '/\*\*', mode: RenderMode.Prerender },  
];

У наведеному прикладі ми вказуємо, що хочемо, щоб Angular рендерив маршрут login на сервері (Server), маршрут dashboard на клієнті (Client), а всі інші маршрути попередньо рендерив (Prerender).

Конфігурація серверних маршрутів (Server Route Config) — це новий конфігураційний файл, але він об'єднує ваші існуючі оголошення маршрутів (Route Declarations) з використанням гло́бів (Globs), тому вам не потрібно дублювати маршрути.

Раніше не було ергономічного способу вирішення параметрів маршруту під час попереднього рендерингу (Prerender Time). З конфігурацією серверних маршрутів це тепер здійснюється безшовно:

export const routeConfig: ServerRoute = [{  
 path: '/product/:id',  
 mode: 'prerender',  
 async getPrerenderPaths() {  
 const dataService = inject(ProductService);  
 const ids = await dataService.getIds(); // ["1", "2", "3"]  
 return ids.map(id => ({ id })); // `id` використовується замість `:id` в шляху маршруту.


},  
}];

Оскільки Angular виконує `getPrerenderPaths` в контексті ін'єкції (Injection Context), ви можете використовувати `inject`, щоб повторно використовувати вашу бізнес-логіку для вирішення параметрів.

Ця функція наразі знаходиться в попередньому перегляді для розробників (Developer Preview)! Детальніше про режими рендерингу на рівні маршруту ви можете прочитати в нашій [документації](https://angular.dev/guide/hybrid-rendering).

## Серверний рендеринг з Zoneless Angular

У версії 18 ми впровадили експериментальну підтримку Zoneless, яка дозволяє Angular працювати без залежності від zone.js. Історично zone.js був критично важливим компонентом в історії серверного рендерингу (Server-Side Rendering) Angular, сповіщаючи серверний стек, коли фреймворк завершив рендеринг і розмітка сторінки була готова.

Ми визначили, що основними причинами затримок в додатках є очікуючі запити та навігація. Ми впровадили примітив (Primitive), який використовує Angular `HttpClient` та `Router`, щоб затримати відправку сторінки користувачеві до того, як додаток буде готовий.


Ви можете експериментувати з обома цими пакетами та Zoneless у версії 19 вже сьогодні!

Крім того, ми надаємо оператор RxJS, який дозволяє сповістити серверний стек, що Angular ще не завершив рендеринг:

subscription
.asObservable()
.pipe(
pendingUntilEvent(injector),
catchError(() => EMPTY),
)
.subscribe();
```

Коли subscription видасть нове значення, ми зробимо додаток стабільним, і серверний стек передасть рендерену розмітку на клієнт.

Досвід розробника

Ми зосереджені на тому, щоб дозволити вам будувати швидкі додатки з самого початку. Не менш важливим ми вважаємо забезпечення ефективного процесу розробки цих додатків.

Сьогодні ми маємо кілька захоплюючих покращень, якими не можемо дочекатися поділитися з вами!

Миттєве редагування/оновлення з гарячою заміною модулів

Angular v19 підтримує гарячу заміну модулів (Hot Module Replacement, HMR) для стилів "з коробки" та надає експериментальну підтримку для HMR шаблонів за флагом!

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

Наше нове рішення HMR компілюватиме лише той стиль або шаблон, який ви змінили, надсилатиме результат у браузер і патчитиме ваш додаток без оновлення сторінки та втрати стану.

Таким чином, ви отримаєте швидший цикл обробки та незмінний робочий процес.

Гаряча заміна модулів стилів в Angular CLI

Гаряча заміна модулів для стилів увімкнена за замовчуванням у версії v19! Щоб спробувати HMR для шаблонів, використовуйте:

NG_HMR_TEMPLATES=1 ng serve

Щоб вимкнути цю функцію, вкажіть "hmr": false як параметр сервера для розробки, або альтернативно використовуйте:

ng serve --no-hmr

Standalone за замовчуванням увімкнено

Ми представили автономні компоненти (standalone components) більше двох років тому в версії v14. За результатами останнього опитування серед розробників, понад 90% сказали, що використовують цю функцію.

В рамках версії v19 ми надаємо схему, яка буде виконуватися під час ng update і автоматично видаляти властивість метаданих standalone для всіх ваших автономних директив, компонентів і пайпів, а також встановлювати standalone в значення false для всіх неавтономних абстракцій.

Для більш детальної інформації ознайомтесь з нашим посібником по оновленню на update.angular.dev. Дякуємо Matthieu Riegler за цей внесок!

Строге забезпечення автономності

Щоб допомогти вам забезпечити використання сучасних API у вашому проєкті, ми розробили флаг компілятора, який викидатиме помилку, якщо виявить компонент, директиву або пайп, які не є автономними.

Щоб увімкнути це у ваших проєктах, налаштуйте tsconfig.json:

{  
 "angularCompilerOptions": {  
 "strictStandalone": true  
 }  
}

Стан інструментів тестування

З моменту введення експериментальної підтримки Jest та Web Test Runner в Angular CLI, ми продовжували оцінювати цю область та збирати відгуки від розробників.

У сфері юніт-тестування ми віримо в реальне тестування в браузері, щоб забезпечити однакове середовище для тестування та продакшн середовища. Для того, щоб підтримати розробників, які переходять на новий будівельник на основі esbuild, в v19 ми вводимо підтримку попереднього перегляду для Karma, щоб використовувати application будівельник, встановивши параметр builderMode.

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

Оскільки Karma знімається з підтримки, в першій половині 2025 року ми продовжимо оцінювати існуючі тестові запускатори, щоб обрати нашу основну рекомендацію, з якою будемо рухатися далі. Слідкуйте за нашими оголошеннями та опитуваннями на блозі та X.

Безпека з самого початку

Ми співпрацювали з командою безпеки в Google над функцією для попереднього перегляду для автоматичної генерації хешованої Суворої політики безпеки контенту (Strict Content Security Policy) на основі скриптів у index.html.

Використовуючи хешовану CSP, браузер додаватиме хеш кожного вбудованого скрипта до політики CSP. Кожен скрипт матиме унікальний хеш, пов'язаний з ним.

Це запобіжить виконанню зловмисного скрипта на вашій сторінці, оскільки для того, щоб браузер виконав скрипт, його хеш має бути присутнім у CSP.

Наразі autoCSP доступний у попередньому перегляді як опція для включення. Щоб використовувати його у своїх додатках, налаштуйте будівельник додатків, встановивши властивість autoCSP на true у розділі security вашого проекту в файлі angular.json.

Еволюція реактивності

Ключовою темою для Angular за останні два роки було вдосконалення нашої системи реактивності.

У версії 19 ми раді поділитися кількома новими безкоштовними API та стабілізацією деяких основних API реактивності, які ми ввели в попередніх версіях, таких як input, output та view queries.

Стабілізація input, output і view queries

Протягом минулого року ми спостерігали, як розробники використовують нові API для input, output і view query, і тепер ми переводимо їх у стабільний статус! Щоб спростити впровадження цих нових API, ми розробили схеми, які автоматично трансформують ваші існуючі input, output і view queries:

ng generate @angular/core:signal-input-migration  
ng generate @angular/core:signal-queries-migration  
ng generate @angular/core:output-migration

Зверніть увагу, що signal inputs є лише для читання на відміну від традиційних input, тому вам може знадобитися вручну мігрувати частини вашого додатку, якщо ви встановлюєте значення для input.

Щоб виконати всі ці міграції одночасно, ви можете використати спільний псевдонім:

ng generate @angular/core:signals

Детальніше про input, output та view queries читайте в нашій документації.

Оновлення вашого коду через сервіс мови

Щоб полегшити оновлення вашого коду до останніх API, ми інтегрували схеми з мовним сервісом Angular.

Інтеграція мовного сервісу з схемами

Коли ви оновите мовний сервіс Angular і ваш проєкт до версії 19, ви зможете безпосередньо оновити ваші input, queries та інші елементи до останніх API прямо з вашого редактора коду!

Введення зв'язаних сигналів

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

Часто в інтерфейсах користувача є потреба в змінному стані, який одночасно відслідковує деякий вищий рівень стану. Наприклад, інтерфейс для вибору має стан «поточний вибір», який змінюється, коли користувач робить вибір, але також повинен скидатись, якщо змінюється список доступних опцій. Новий примітив linkedSignal створює записуваний сигнал, який захоплює цей тип залежності:

const options = signal(['apple', 'banana', 'fig']);  

// Вибір за замовчуванням — це перша опція, але його можна змінити.  
const choice = linkedSignal(() => options()[0]);  
console.log(choice()); // apple  

choice.set('fig');  
console.log(choice()); // fig  

// Коли список опцій змінюється, вибір скидається на нове значення за замовчуванням.  
options.set(['peach', 'kiwi']);  
console.log(choice()); // peach

linkedSignal чітко виражає взаємозв'язок між options і choice, без необхідності використовувати effect (ефект).

Нова API має 2 форми: спрощену (представлену тут) та розширену, де розробник має доступ до попередніх значень options і choice. Вона також має розширену версію, яка дозволяє виконувати більш складну логіку, наприклад, зберігати вибір користувача, поки він існує в новому списку опцій.

Ця нова API є експериментальною, тому обов'язково спробуйте і дайте нам знати, що ви про це думаєте!

Представлення ресурсу

До цього часу сигнали в Angular фокусувались на синхронних даних: зберігання стану в сигналах, обчислені значення, входи, запити тощо. В Angular v19 ми робимо перші кроки до інтеграції сигналів з асинхронними операціями, представляючи нову експериментальну API resource(). Ресурс — це асинхронна залежність, яка бере участь у графі сигналів. Ви можете уявити ресурс як такий, що складається з трьох частин:

Функція запиту, яка виражає точний запит, що має бути зроблений у термінах сигналів.

Наприклад, ресурс user може обчислювати запит, який залежить від параметра ID користувача в поточному маршруті.

Завантажувач, який виконує асинхронну операцію, коли запит змінюється, і зрештою повертає нове значення.
Результуючий екземпляр Resource, який надає сигнали, що передають як значення (коли воно доступне), так і поточний статус ресурсу (завантаження, вирішено, помилка тощо).

@Component(...)  
export class UserProfile {  
 userId = input\();  

 userService = inject(UserService);  

 user = resource({  
 request: this.userId,  
 loader: async ({request: id}) =\> await userService.getUser(id),  
 });  
}

Ми надаємо resource() як незалежну, експериментальну API сьогодні для тестування API та отримання раннього зворотного зв'язку від розробників.

З часом ми очікуємо поступово інтегрувати підтримку ресурсів глибше в Angular (наприклад, у маршрутизатор як форму резолвера) як ключову частину асинхронної роботи в застосунках.

Оскільки багато застосунків Angular сьогодні використовують RxJS для отримання даних, ми також додали rxResource до @angular/core/rxjs-interop, який створює ресурс з завантажувача на основі Observable.

Стан API ефектів

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

Як основний примітив в нових API для реактивності, ми хочемо приділити достатньо часу, щоб переконатися, що семантика effect правильно відображає всі необхідні випадки.

Ми збережемо цей API в розробницькому прев'ю, щоб залишити можливість для змін, якщо ми виявимо випадки використання, які ще не врахували.

Стан Zoneless

Шість місяців тому ми ввели експериментальну підтримку zoneless в Angular. З того часу ми активно працюємо над API та покращуємо їх — додали підтримку серверного рендерингу та покращили досвід тестування. Ми також співпрацювали з командою Google Fonts, щоб зробити їх додаток zoneless і оцінити досвід розробників. Результати та легкість переходу на zoneless перевершили наші очікування, але є ще кілька моментів, які ми хочемо доопрацювати, перш ніж перевести цей API в розробницьке прев'ю.

У 2025 році ми продовжимо вдосконалювати zoneless.

Тим часом, не забудьте спробувати у вашому завантаженні додатка та поділіться своїм досвідом! Найпростіший спосіб створити проект без зон — використати Angular CLI:

ng new [project-name] --experimental-zoneless

Дякуємо Анджело Парціале за цей внесок у спільноту contribution!

У вже існуючих додатках ви можете використовувати експериментальний провайдер zoneless:

bootstrapApplication(App, {  
 providers: [  
 provideExperimentalZonelessChangeDetection()  
 ]  
});

Далі переконайтеся, що ви видалили zone.js з розділу polyfills у вашому файлі angular.json.

Розвиток Angular Material та CDK

Раніше цього року ми стабілізували Material 3, що робить наші матеріальні компоненти більш налаштовуваними завдяки потужному API для темінгу на основі Sass, яке підтримується дизайнерськими токенами.

У версії 19 ми впроваджуємо покращення в API темінгу, спрощуючи налаштування ваших компонентів!

Покращений API темінгу

З Material 3 ми дозволили вам створювати кастомні теми, використовуючи специфічні міксини для компонентів:

@use '@angular/material' as mat;  

@include mat.core();  

$light-theme: mat.define-theme((  
 color: (  
 primary: mat.$violet-palette,  
 tertiary: mat.$orange-palette,  
 theme-type: light  
 ),  
 typography: Roboto,  
 density: 0  
 ));  

html {  
 // За замовчуванням застосовуємо світлу тему  
 @include mat.core-theme($light-theme);  
 @include mat.button-theme($light-theme);  
 @include mat.card-theme($light-theme);  
 // і ще 27...  
 ...  
}

З цим надзвичайно налаштовуваним API ви часто стикаєтесь з дублюванням коду для окремих компонентів.

Щоб спростити створення кастомних тем, у версії 19 ми впровадили більш виразний API, який дозволяє оголошувати кастомну тему за допомогою одного міксина — mat.theme:

@use '@angular/material' as mat;  

html {  
 @include mat.theme((  
 color: (  
 primary: mat.$violet-palette,  
 tertiary: mat.$orange-palette,  
 theme-type: light  
 ),  
 typography: Roboto,  
 density: 0  
 ));  
}

Перезапис стилів компонентів

Щоб налаштувати стилі окремих компонентів, ви можете використовувати новий API для перезапису, який ми надаємо в Sass:

@include mat.sidenav-overrides(  
 (  
 'content-background-color': purple,  
 'container-divider-color': orange,  
 )  
);

У наведеному фрагменті коду буде перезаписано фон вмісту та колір роздільника вмісту на purple та orange відповідно, при цьому збережуться початкові значення для інших токенів дизайну, враховуючи налаштовану тему вашого додатку.

Двовимірне перетягування

Для того, щоб зробити Angular CDK більш потужним, ми розробили підтримку двовимірного перетягування та впуску в CDK, що стало популярним запитом із 311 👍 на GitHub.

Ось швидкий фрагмент коду, як можна використовувати цю функціональність CDK:

\
    ...\>    @for (item of mixedTodo; track item) {    \
    {{item}}    \\    \    }

І результат буде виглядати ось так:

Демо перетягування та впуску з комбінованою орієнтацією
Дізнайтеся більше в документації.

Підтримка перестановки вкладок

Інший запит, який ми реалізували недавно — це підтримка перестановки вкладок за допомогою Angular CDK (24 👍).

Завдяки цій функціональності ви можете легко зробити вкладки перетягуваними, що команда Google Cloud Console одразу впровадила в BigQuery за допомогою Angular та CDK:

Перетягувані вкладки в BigQuery

Новий компонент вибору часу

Один з найпопулярніших запитів, що зібрав більше ніж 1.3k 👍 на GitHub, був створення компонента вибору часу для Angular Material.

Ми не реалізували це одразу, оскільки не було чітких специфікацій для цього, але враховуючи попит, ми створили дизайн, який відповідає вашим вимогам та стандартам доступності, і випустили його у v19!

Основне використання компонента вибору часу

Ви можете використовувати його у своїх додатках Angular вже сьогодні! Дізнайтеся більше в документації.

І це ще не все!

Окрім значних покращень, які ми випустили в основних темах: продуктивність, реактивність, досвід розробника та автономні компоненти, ми також додали низку поліпшень для підвищення зручності розробки Angular-додатків!

Повідомлення про невикористовувані імпорти в автономних компонентах

Повідомлення про невикористовувані імпорти в автономних компонентах було одним з найбільш запитуваних функціоналів, зібравши понад 150 👍!

Починаючи з v19, Angular CLI буде повідомляти про невикористовувані імпорти, подібно до gif нижче:

Крім того, Angular мова сервісу підсвічуватиме такі невикористовувані імпорти і надасть функціональність для автоматичного їх видалення безпосередньо в IDE чи текстовому редакторі.

Щоб вимкнути цю перевірку, можна оновити ваш angular.json:

{  
 "angularCompilerOptions": {  
 "extendedDiagnostics": {  
 "checks": {  
 "unusedStandaloneImports": "suppress"  
 }  
 }  
 }  
}

Оголошення змінних середовища через командний рядок

Найбільш запитувана функція в репозиторії Angular CLI, зібравши понад 350 👍, це можливість передавати змінні середовища під час побудови.

Починаючи з v19, ви можете використовувати прапорець --define для досягнення цього:

ng build --define "apiKey='$API\_KEY'"

declare const apiKey: string;  

await fetch(`/api/data?apiKey=${apiKey}`);

Локальні змінні в шаблонах

Протягом багатьох років ми отримували сотні запитів на додавання синтаксису для оголошення локальних змінних (443 👍) у шаблонах.

Протягом багатьох років, на жаль, у нас не було оптимального синтаксичного конструкта для цього.

З новим блоковим синтаксисом для вбудованих операторів керування та відкладених подань ми розробили рішення, яке задовольняє потреби розробників у оголошенні локальних змінних шаблону. Ми випустили цю функцію в developer preview як частину Angular v18.1. Після того, як ми спостерігали за тим, як розробники використовують цей новий синтаксис, ми тепер переводимо його на стабільний рівень!

Це елегантно працює з посиланнями на шаблон і з асинхронним пайпом:

Щоб забезпечити використання ваших додатків найновіших API та кращих практик, ми випустили кілька поліпшень:

Зміна значення за замовчуванням для standalone на true, що спрощує метадані всіх ваших самостійних компонентів (standalone components), директив і пайпів. Це міграція, яку CLI автоматично виконає при оновленні вашого проєкту.
Додатковий схематик для перетворення інжекції залежностей, заснованої на конструкторах, на виклики функцій інжекції за допомогою команди ng generate @angular/core:inject-migration.
Додатковий схематик для переведення ваших жадібно завантажуваних маршрутів на лінійні маршрути (lazy routes).
Дякуємо Enea Jahollari за цей внесок у спільноту contribution!
Додатковий схематик для перетворення ваших входів (inputs), запитів (queries) та виходів (outputs), що використовують декоратори, на найновіші API: ng generate @angular/core:signal-input-migration, ng generate @angular/core:signal-queries-migration, ng generate @angular/core:output-migration.
Підтримка нового API для кластеризації в @angular/google-maps! Оригінальний запит функціональності можна знайти на GitHub (26 👍).
Видалено побудовник Protractor для відкриття шляху до підтримуваних інструментів для e2e тестування.
І міграція за бажанням, яка перенесе ваш проєкт на побудовник додатків, що використовує esbuild та vite.

Велика подяка спільноті Angular

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

Ваші відгуки, пакети з відкритим кодом та активна участь у зустрічах і конференціях допомагають нам кожного дня робити Angular кращим. Знання, якими ви ділитесь на таких платформах, як StackOverflow, Discord, Reddit, Telegram та інших, надають можливість розробникам по всьому світу.

Ми запрошуємо вас приєднатися до цієї яскравої спільноти, онлайн або локально. Лише цього року десять конференцій Angular відбулися по всьому світу, в таких країнах, як Бельгія, Німеччина, Індія, Ізраїль, Італія, Кенія, Македонія, Польща, Сербія, США.
Ці заходи — чудова можливість для зустрічей з іншими розробниками, ознайомлення з останніми новинами та обміну досвідом.

Якщо ви організовували конференцію Angular, яка не потрапила до нашого списку, будь ласка, дайте нам знати за адресою [email protected], щоб ми могли поширити інформацію.

Ми також хочемо подякувати всім 247 контриб'юторам між нашими двома останніми основними випусками, які допомогли нам у формуванні версії v19.

Продовжуймо вчитися, розвиватися та створювати дивовижні речі з Angular!

Вперед до 2025!

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

Кілька основних тем, які постійно виникають, — це модернізація досвіду авторства в Angular та перегляд наших рекомендацій щодо юніт-тестування. Ми плануємо провести ґрунтовне дослідження в цій сфері на початку наступного року та поділитися результатами з вами, щоб зібрати відгуки перед прийняттям будь-яких рішень. Тим часом ми продовжимо вдосконалювати наші API реактивності, вносити поступові покращення в досвід розробника (DX) на всіх рівнях і покращувати продуктивність Angular, щоб ви могли впевнено створювати веб-додатки!

Дякуємо, що допомагаєте нам формувати Angular, і вперед до 2025 року! 🚀

Перекладено з: Meet Angular v19