Пока вы догуливаете последние дни каникул, команда Angular, спустя 8 лет, начала работу над поддержкой стрелочных функций прямо в шаблонах!

📌 планируется поддержка только implicit returns, это должно будет предотвратить миграцию сложных функций, содержащих бизнес-логику, в шаблоны

📌 внутри этих функций нельзя будет использовать pipes, но результат работы этих функций можно будет передавать в pipe через конвеер

{{ (a, b) => a + b | currency }}

❓в комментах Manfred Steyer предложил также избавиться от магической переменной $event и добавить возможность использовать явный параметр (click)="(e) => doStuff(e)"

По сути, это всё будет in-place решением для функций-компараторов, например для trackBy, либо же:

<select [compareWith]="(a, b) => a.id === b.id"/>

<mat-autocomplete [displayWith]="option => option.name"/>

<button (click)="someSignal.update(prev => prev + 1)"/>

А что с производительностью?
Заявлено, что если функция ссылается только на свои собственные параметры, то она будет автоматически выноситься в top-level константу и не будет пересоздаваться при каждом Change Detection.
А в случаях, когда функция ссылается на контекстные переменные шаблона – она будет сохранена в текущем View, после чего будет подставляться где необходимо.

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

А что вы думаете об этом?

#angular

NgStream / Чат

Команда Angular добавит контроль за очисткой инжекторов при переходе с одного route на другой.

📌 Когда для маршрута определяются провайдеры (через providers в Route или lazy загрузку модуля), Angular создает для этого маршрута отдельный EnvironmentInjector. И инжекторы никогда не уничтожаются, даже если пользователь перешел на другой route.
В этом состоит основная проблема, что приводит накоплению неиспользуемых инжекторов в памяти, неосвобождаемым подпискам и ресурсам компонентов и, в результате, росту потребления памяти в приложениях. Для современных SPA это критично.

Для пояснения следующего пункта нужно пояснить, кто не знает.

RouteReuseStrategy - стратегия управления жизненным циклом компонентов роутов. Если чуть упростить, то механизм, который позволяет кешировать роуты, а именно инстанс компонента и относящийся к нему DOM, чтобы впоследствии (при повторном обращении к route) достать из кеша.

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

- Сохранять в памяти и переиспользовать компоненты с их состоянием.

📌 При использовании этой стратегии объекты DetachedRouteHandle сохранялись в памяти. Если пользователь больше не возвращался на сохраненный route, компоненты не уничтожались и не отписывались от Observable, что постепенно замедляло работу приложения. В этом состоит вторая проблема.

📌 Обновление вводит механизмы для автоматической и ручной очистки ресурсов. Для этого используется алгоритм "mark and sweep", который выявляет неиспользуемые инжекторы и освобождает ресурсы.
Для автоматической очистки рекомендуется использовать withExperimentalAutoCleanupInjectors().

export const appConfig: ApplicationConfig = {
  providers: [
    provideRouter(routes, withExperimentalAutoCleanupInjectors())
  ]
};

📌 Обновление RouteReuseStrategy
В стратегию добавлены новые методы - shouldDestroyInjector и retrieveStoredRouteHandles, которые дают более тонкий контроль над тем, когда именно нужно очищать ресурсы.

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

МР

#angular

NgStream / Чат

Angular tip

Как вы знаете, в обновленном Style guide, направленном на обеспечение единообразия кода, основное внимание уделяется стандартам именования файлов. Начиная с 21 версии для новых проектов предполагается новый формат.

Функциональные единицы теперь не должны использовать суффикс. Например, для компонента UserProfile файлы должны называться user-profile.ts, user-profile.html и user-profile.scss.

Фишка в том, что добавлен флаг для сохранения текущего подхода.

--file-name-style-guide=2016

В этом случае компоненты, сервисы и другие элементы получат классические суффиксы.

#angular

NgStream / Чат

Вокруг vibe coding и всевозможных LLM не стихает информационный шум.

📌 Читая заголовки выступлений на митапах и конференциях, по ощущениям, половина о том, как подружиться с ИИ, как внедрить, управлять…, организовать процесс vibe coding…

📌 Вдруг, кто не знает, vibe coding - разработка, где человек, в основном, описывает задачу на естественном языке, а LLM генерирует код. Я решил написать свое отношение к теме vibe coding.

📌 Меня удивляет, что глубоко интегрируя этот процесс, человек не погружается глубоко в суть задачи, отдавая все на откуп ИИ. В итоге получается не всегда эффективное решение, поверхностное, с возможными ошибками. Здесь стоит сказать, что важно уметь с ним общаться, правильно и точно формулировать требования, исходную задачу и требуемый результат. В этом случае, конечно, процент ошибок ниже.

📌 Особенно остро этот вопрос касается джунов. ИИ делает хуже им, предоставляя готовые ответы, которые не позволяют набирать нужный опыт. Чем решение хорошо/плохо? Почему такое решение? Подобный подход подталкивает брать готовое решение и не разбираться в вопросе самостоятельно. А на первых этапах особенно важно походить по граблям и набить шишки.
В общем, я бы сказал, что внедрять джунам AI нужно не бездумно, а подкреплять его нормальными инженерными практиками, помощью коллег.

📌 Сложно спорить, есть очевидные плюсы

- Прототипирование возможных решений. Существенная экономия времени.
- Объемная и рутинная работа. Написать CRUD или что-то аналогичное. Быстро, удобно доставить бизнес-ценность.

📌 Но за эту скорость мы платим тем, что постепенно утрачивается навык самостоятельно решать задачу, навык глубокой отладки. В общем, мы перестаем меньше писать. Это же то, за чем многие пришли в разработку! Наша ценность всегда была в глубоком понимании, а не просто в умении производить код.

Я использую llm для генерации документации, иногда для написания тестов. С правками получается неплохо. Не всегда, правда😅

📌 Вывод в том, что ИИ, на мой взгляд, это усилитель навыков, а не замена разработчика. Как молоток не делает из человека плотника, так и ИИ не делает из новичка senior-разработчика. ИИ требует осознанности, важно оценивать качество сгенерированного кода, а не просто копировать. Соблюдать баланс, еще одна важная часть нашей экспертизы.

А какие ИИ инструменты используете вы в разработке? Добавлю небольшой опрос. Если есть мысли, пишите в комментариях, интересно будет узнать!

NgStream / Чат

TypeScript 6.0. И никаких компромиссов.

Если предыдущие версии старались сохранять максимальную обратную совместимость, то версия 6.0 нацелена на решительное избавление от legacy и установку новых стандартов «по умолчанию».

Что изменится в новой версии?

📌 Strict Mode теперь обязателен. Это не просто изменение одного флага, а глубокая смена логики наследования настроек. Теперь такие критические проверки, как noImplicitAny и strictNullChecks, становятся стандартом. Также по умолчанию будет подразумеваться директива "use strict"
📌 target es5 deprecated. Минимально возможный стандарт теперь ES2015. Отказ от ES5 позволит команде упростить внутреннюю логику. Возможно, ускорит процесс сборки.
📌 Включение параметра noUncheckedSideEffectImports по умолчанию. Позволит улучшить существующие конфиги и выявлять некорректные импорты в IDE.

Значительная часть работы посвящена удалению старых опций для упрощения конфигурации. Помечены deprecated baseUrl, --outFile, а также module resolutions node10 и classic .

Публикация финальной версии намечена на март 2026 года, а план выпуска включает этапы бета-тестирования и релиз-кандидата.

24 февраля 2026 - RC Release.
17 марта 2026 - Final Release.

Эти реформы призваны сделать конфигурацию «по умолчанию» максимально эффективной для защиты от типичных программных ошибок.

Подробнее здесь. Typescript Iteration Plan.

#typescript

NgStream / Чат

Команда Angular в последнем релизе все же представила новый вид селекторов. Точнее, selectorless подход. Эта функциональность не просто перешла в stable режим, но и была установлена как режим по умолчанию.

Суть подхода в обращении к классу компонента напрямую, минуя использование строковых селекторов, которые задаются в свойстве selector.

На мой взгляд, изменение вида селекторов - весьма спорное нововведение по нескольким причинам.

🛠 Несоответствие стандарту HTML. Как я понимаю, selectorless раньше не внедряли специально для следования стандарту. Спецификация определяет void-элементы (например, <img>, <br>), которые не могут иметь содержимого и не требуют закрывающего тега (но в конце ставят /> , например: <img />). Поэтому формально для соответствия стандарту HTML именно Angular берет на себя задачу превращения этих инструкций в валидные DOM элементы с открывающими и закрывающими тегами. Однако, если вы попытаетесь использовать такой синтаксис напрямую в html файле без предварительной компиляции (например, через innerHTML в браузере), парсер браузера может интерпретировать это неверно, так как по стандарту HTML пользовательские элементы (custom elements) обязательно должны иметь закрывающий тег и не могут быть void-элементами.

🛠 Медленная адаптация в enterprise. Многие пользователи Angular это крупные компании и обычно изменения внедряются постепенно. Поскольку плюсы не видны (по крайней мере пока что), то просто так переписывать код не очень разумно.

🛠 Сложнее поиск компонента в дереве селекторов в devtools и в коде, если использовать имя компонента.

🛠 Самое интересное, зачем текущий html-like синтаксис превращать в JSX? (кто не знает, в Angular не html, а чуть другой формат) Мы привыкаем ко всему, но это определенно делает Angular непривычным и никаких причин для внедрения, кроме "modern Angular code", я не нашел в тексте МР.

#angular

NgStream / Чат

Корректирующая обратная связь

В работе и личной жизни мы часто сталкиваемся с необходимостью давать обратную связь. Однако неправильно сформулированная критика может вызвать конфликт, обиду или демотивировать человека. Как сделать общение продуктивным, а критику - полезной?

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

Рассмотрим пару примеров.
❌ «Ты всегда срываешь сроки!» // Обвинение
✅ «Я заметил, что последние два дедлайна были пропущены. Давай разберёмся, что мешает уложиться в сроки?» // Конструктивный подход.

Конструктивное общение — это навык, который можно развить. Его основы:
🔸 Уважение к собеседнику.
🔸 Конкретика в замечаниях.
🔸 Готовность помочь исправить ошибки.

В разработке это особенно критично, потому что мы работаем со сложными системами, где причина проблемы редко лежит на поверхности.

Есть несколько причин давать корректирующую обратную связь.

📌 Ощущение безопасности. Когда критика не носит личный характер и направлена на решение задачи, люди перестают бояться ошибаться и скрывать проблемы. Поможет раньше задавать вопросы, адекватно оценивать риски.
📌 Формирование ответственности. Когда человек понимает реальное влияние своих действий на продукт, команду и клиентов, он начинает мыслить системно.
📌 Мотивация специалистов. Талантливые люди ценят рост, а отсутствие обратной связи - сигнал о стагнации и безразличии.

Получается, что это такой же инструмент инженерной культуры, как Code Review или тестирование. Если его правильно применять, это будет двигателем роста и для сотрудника, и для процессов команды, и для продукта в целом.

Если тема понравится, напишу отдельный пост и расскажу о фреймворке, который можно применять для корректирующей обратной связи.

#нетехзаметки

NgStream / Чат

На прошлой неделе релизнули 21.2

📌 Одно из нововведений - Exhaustiveness checking для @switch control flow! В этом случае требуется указание @case для каждого значения в типе. Проще говоря, появилась возможность добавить @default never;

Для тех , кто не знал, это называется "проверка на полноту", помогает убедиться при жонглировании набором значений, что задействованы все элементы Union type. Я стараюсь использовать в TS такую конструкцию для обеспечения дополнительной безопасности.
А сейчас добавлется еще один важный пункт - логика на UI теперь отражает модель данных.

// если пропустили/забыли добавить значение, компилятор вернет ошибку. В данном случае, если не указать 'reject' в @case, то получим ошибку.
type Status = 'draft' | 'review' | 'success' | 'reject';
status: Status = 'draft';

@switch (status) {
  @case ('draft') {...}
  @case ('review') {...}
  @case ('success') {...}
  @default never
}

📌 Стрелочные функции в шаблонах. Об этом уже написано в канале, не буду повторяться. Скажу, что конструкция избыточна и только размывает логику между шаблоном и классом. Шаблон все же предназначен для рендеринга, а не описания логики. А тут еще и поддержку оператора instanceof запилили. В шаблоне!
Есть нюанс. Вы не можете использовать стрелочную функцию в качестве обработчика события для вызова метода. Попытка написать (click)="() => doSomething()" приведет к ошибке на этапе компиляции (Template Type-Check error). Это ограничение связано с тем, как Angular оптимизирует привязку событий, и попытка «обернуть» вызов метода в стрелочную функцию внутри шаблона нарушает этот механизм.

📌 SignalFormControl. Здесь интереснее. Это инструмент для плавной миграции между реактивными и сигнальными формами. Позволяет применять правила, как это сделано в сигнальных формах, пример ниже. В шаблонах менять ничего не придется. Об изменениях касательно форм напишу отдельно=)

password: new SignalFormControl('', p => {
    required(p);
    minLength(p, 6);
  })

📌 Явность вместо неявности. С 22 версии OnPush стратегия по умолчанию для новых компонентов. А ChangeDetectionStrategy.Eager теперь является способом явно заявить, что компонент требует устаревшего «прожорливого» поведения. Это переименование необходимо для работы миграций. После обновления до 22, Angular CLI автоматически заменит отсутствие стратегии или Default на Eager.

📌 Интеграция с Prettier
Angular CLI теперь имеет встроенную интеграцию. При создании нового проекта .prettierrc добавляется «из коробки». Для больших команд это критически важное улучшение DX.

А вы уже мигрируете свои проекты на OnPush и сигналы или ожидаете принудительного перехода в v22?

Описание обновления.

#angular

NgStream / Чат

Обновления Signal Forms API

Еще одним полезным дополнением в 21.2 является новая утилита transformedValue для синхронизации значения с моделью.

Основные возможности
📌 Двусторонняя трансформация: функция parse (преобразование ввода → модель) и format (модель → отображение)
📌 Автоматическая обработка ошибок: Ошибки парсинга автоматически пробрасываются в родительскую форму. Ни на что не похоже?:)
📌 Гибкий механизм валидации: Функция parse может возвращать как успешный результат с value, так и массив errors
📌 Интеграция со встроенными валидаторами: Возможность возвращать стандартные ошибки валидации (например, min для отрицательных значений)
Пример использования: Пользователь вводит "20m" или "1h", а в модели данные хранятся в минутах. При неверном формате ввода форма получает соответствующую ошибку для отображения в UI.

Еще один инструмент - директива FormRoot , которая делает отправку форм полностью декларативной. Вместо навешивания на форму (submit)=submit($event) и директивы novalidate (которая отключает встроенные проверки браузера при проверке форм) используем FomRoot, которая связывает сигнал формы с шаблоном.

Обработку submit предлагается делать в специальном cb submission внутри сигнала form. Теперь не шаблон управляет отправкой, а сама форма определяет логику.

protected readonly form = form(this.credentials, {
  submission: {
    action: async () => await this.svc.save(this.credentials()),
    onInvalid: () => this.invalidSubmission.set(true),
    ignoreValidators: 'none'
  }
});

Кстати, .reset() по-прежнему сбрасывает только состояния touched и dirty. Для сброса значения формы указывать напрямую initial значение модели. В этом случае, сбросится значение формы и сигнал, содержащий модель данных.

Описание обновления.

#angular

NgStream / Чат

Вышел Vite 8.0

Главным нововведением стал переход на Rolldown, высокопроизводительный bundler на базе Rust, который заменяет связку из esbuild и Rollup для достижения кратного прироста скорости сборки.

Долгое время Vite балансировал между esbuild для сборки в режиме разработки и мощным Rollup для оптимизированных бандлов в production.

Rolldown был спроектирован для того, чтобы объединить нативную производительность (уровня esbuild) с богатой экосистемой плагинов Rollup. Теперь и разработка, и prod сборка используют одни и те же механизмы парсинга и разрешения модулей, что гарантирует идентичность поведения кода.

В экспериментальном режиме Full Bundle Mode обещают какие-то фантастические цифры:
- Старт сервера в 3 раза быстрее.
- Полные перезагрузки страниц на 40% быстрее.
- Снижение количества сетевых запросов в 10 раз.

Теперь цепочка «инструмент сборки (Vite) - бандлер (Rolldown) - компилятор (Oxc)» работает как единое целое с глубокой AST-интеграцией.

Команда предлагает специальный Migration guide, обещая плавный переход без значительных изменений в конфигах.

Более подробно можно ознакомиться по ссылке.

#angular

NgStream / Чат

На просторах интернета нашел статью о глубоком погружении и использовании Claude Code на примере Angular и решил скинуть. Мне показалось, что описано подробно и будет полезно для тех, кто сейчас разбирается в процессе.

📌 Здесь и о настройке первого проекта, пояснениях документации, Angular MCP, режимах планирования, интеграции с Git и плагинами. И даже с пайплайнами CI.

📌 Главная проблема LLM - устаревание знаний, а Angular развивается довольно быстро (Signals, Resource API), поэтому ответы могут быть некорректными. Но есть Model Context Protocol (MCP), который позволяет Claude подключаться к актуальной документации Angular CLI напрямую.

📌 Еще одна проблема - это высокая автономность, и ошибки AI могут быть фатальными. Решением является изоляция. Для этого предлагается использовать Docker Sandbox. Запуск через claude --docker изолирует агента в microVM.
Неплохая фраза, которую нашел в статье и которая описывает текущее состояние:

ваша задача - быть «пилотом», который задает курс и проверяет качество.

📌 А на прошлой неделе еще появилась новость, что Anthropic признали угрозой национальной безопасности и приказали федеральным агентствам прекратить использовать Claude. Bloomberg.

#angular

NgStream / Чат

Обновление Angular roadmap

Команда выделяет основные направления:

📌 Самое громкое изменение - повышение приоритета «Improve the AI experience for developers». Angular не просто «надеется», что LLM напишут хороший код, а системно оптимизирует свои инструкции, документацию и внутренние API, чтобы модели, вроде Gemini, выдавали качественный результат. Для оценки прогресса используется собственная инфраструктура тестирования - Web Codegen Scorer.

📌 Эволюция реактивности и Signals. Сигналы становятся центральной частью архитектуры Angular, проникая во все ключевые пакеты.

-Signal Forms. В планах обеспечение бесшовной миграции с Reactive Forms.
- Асинхронная реактивность. Внедрение примитивов resource и httpResource для обработки асинхронных потоков данных как сигналов.
- В разработке создание оберток на базе сигналов для Router и других модулей.
- Повышение производительности. Переход на zoneless и использование стратегии обнаружения изменений OnPush по умолчанию.

📌 Улучшение DX. Здесь, как я понял, команда отметила, что завершена работа над запланированными изменениями. И ничего не было написано о новых. Angular переходит на сторону популярных инструментов экосистемы.

- Vitest (Experimental, v20). Современная и быстрая альтернатива Karma/Jasmine становится частью официального тулинга.
- Стабильный HMR (v20). Горячая перезагрузка шаблонов и стилей наконец-то получила статус Stable, что делает цикл «правка-результат» практически мгновенным.

Ссылка на МР с обновлением.

#angular

NgStream / Чат

Сигналы становятся центральной частью Angular, вытесняя старые механизмы управления состоянием и запросами к шаблону. Некоторые (если не многие) проекты сейчас в состоянии перехода на новые сигнальные API.

Просто взять и заменить все декораторы на функции в пятницу вечером - плохая идея. Но мы можем запретить появление новых декораторов в новом коде.
И я недавно увидел, что есть правила ESLint, которые могут помочь с миграцией, и решил поделиться.

Для миграции нам понадобятся два ключевых инструмента ESLint (с плагином @angular-eslint) и schematics, которые были представлены вместе с выходом нового API.

📌 Мы можем использовать правило prefer-signals. Оно помечает использование @Input как ошибку, предлагая заменить на input. Аналогично для других legacy декораторов.

📌 Что с [(ngModel)] ? Мы знаем, что можно заменить на сигнал model(), который упрощает реализацию двустороннего связывания (two-way data binding). Выглядит следующим образом: value = model.required<string>();

Здесь нам помогает правило prefer-signal-model. Поскольку сигналы не должны переназначаться, правила ESLint предлагают автоматически добавлять модификатор readonly к объявлению свойств.

В общем, с использованием правил линтера немного проще мигрировать большие enterprise проекты на новый API, писать код чище, современнее и безопаснее. Успешной миграции!

#angular

NgStream / Чат

Все же представлен экспериментальный компилятор Angular от OXC

VoidZero заявляют:
- об ускорении билда в 20 раз за счет переноса логики обработки и преобразования шаблонов на сторону Rust и интеграции с экосистемой Oxc и Vite.
- в 6 раз быстрее, чем Angular CLI и в 20 раз быстрее, чем Webpack.
- vitejs plugin с полной поддержкой HMR.

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

Из интересного - компилятор написан на Rust! И разработан с использованием искусственного интеллекта. Пишут, что инженеры использовали Claude и Codex. Агенты проанализировали проект Oxc и определили, как использовать его компоненты (Parser, Semantic, Transformer) для замены функционала TypeScript. Были внедрены высокопроизводительные паттерны Rust, такие как arena memory allocation и применение существующих SIMD crates.

Oxc Angular Compiler не планируют поддерживать в дальнейшем, поскольку задача была удостовериться в возможностях AI, его эффективности и переносе Angular single-file компиляции на Rust.

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

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

Ссылка на статью с подробностями.

#angular

NgStream / Чат

Недавно были новости о том, что OnPush сделают стратегией по умолчанию. И вот, MR с этими изменениями влит. Нововведение ожидается с 22 версии. Напомню, что с v21 новые проекты создаются по умолчанию в Zoneless режиме.

Что это дает?

Меньше "шума" в классах, можно убрать явное указание использования стратегии для каждого компонента.
Пожалуй, постепенно придем к тому, что компоненты будут максимально чистые, свойства декораторов будут содержать только template и styles.
Ведь указание селекторов могут убрать с переходом на selectorless подход (к сожалению), а указание standalone: true аналогично покажется излишним, поскольку подавляющее количество компонентов, так или иначе уже создаются вне модулей (NgModule, если кто помнит).

Что изменено?

📌 Если стратегия не указана, значит выбран OnPush.

📌 Если нужно оставить предыдущее поведение, то нужно вручную указать Eager. Это новый алиас для Default стратегии. Сейчас, если не указана стратегия, значит выбран Default.

Впрочем, при переходе на версию 22 миграция будет сделана автоматически.

#angular

NgStream / Чат

Angular продолжает "эволюцию" и в этот раз опубликован МР, где предлагают отказаться от "устаревшего" и, показавшегося избыточным, декоратора @Injectable. И добавить новый @Service.

В чем разница?

📌 @Service по умолчанию providedIn: 'root'. Можно вручную установить на нём параметр autoProvided: false и указать сервис в массиве providers: [] в нужном месте.
📌 @Service не поддерживает constructor-based injection, указание зависимостей возможно только через inject().
📌 @Service не поддерживает useClass, useValue и тд, только factory.

Лично я не вижу значительных преимуществ от предлагаемых изменений. Кроме большого количества материалов и AI базы знаний, которые станут устаревшими (о чем, кстати, пишут в комментариях), пострадает интуитивно понятное Angular API. Еще остается непонятным, что указывать при провайдинге на уровень платформы? Для такой более точечной настройки DI, скорее всего, оставят старый добрый Injectable. Но опять же, возникает больше чем один способ сделать одну вещь. И это отличается от привычной философии Angular.

Есть противоположная точка зрения. Якобы, вариант ниже смотрится менее понятным и с большим количеством бойлерплейта.

@Injectable({ providedIn: 'root' })
export class BookStore {}
// Предлагаемая версия
@Service
export class BookStore {}

Представленные изменения еще на этапе дискуссии и разработчики ждут обратной связи от сообщества. Вы можете выразить свою точку зрения, написав комментарии в опубликованном МР.

Ну и здесь в чате можете не стесняться:)

#angular

NgStream / Чат

В марте Temporal API перешел в статус Stage 4 (что означает добавление в стандарт) в TC39 и официально включен в спецификацию ECMAScript. Это эпохальное событие для JS.

На момент публикации заметки - на MDN статус Widely available. Не поддерживается в Safari.
Temporal предлагает строгое соблюдение формата ISO, удобную работу с часовыми поясами, корректную индексацию месяцев и иммутабельность объектов, позволяющих избежать случайных ошибок при математических операциях с датами.

Подробно о минусах встроенного Date писать не буду, мы все и так об этом знаем.

📌 Для чего уже можно применять?
- Простые даты. Создание, манипуляции без вычитания единицы из месяцев.
- Операции - добавление дней, месяцев или часов возвращает новый объект.
- Явная и предсказуемая работа с часовыми поясами.
- Форматирование - встроенное форматирование с учетом локализации.

📌 На мой взгляд, это шаг в сторону отказа от библиотек. Или выбор одной из них, поскольку есть вероятность, что внутри они будут переходить на новое API для простоты, уменьшения количества костылей и оптимизаций.

📌 Завершение стандартизации означает, что Date станет историческим артефактом и останется только для обратной совместимости. Можно будет сказать: "а я еще Date использовал".

#js

NgStream / Чат

Команда Angular добавит функционал debounce для асинхронной валидации форм.

📌 По факту, это параметр в функции validateAsync и validateHttp . Аналогично debounce из RxJS он позволяет сократить количество запросов при проверке данных. В рамках изменений был внедрен новый тип данных DebounceTimer, который унифицирует настройку времени ожидания. Теперь выполнение проверок может быть отложено на заданное количество миллисекунд или до завершения работы конкретной функции.

В общем, приятное дополнение для Forms.

🎉 Кроме того, с версии Angular 22 Resource API (resource, rxResource, httpResource) перейдет в статус stable!

#angular

NgStream / Чат

Довольно позитивная новость, о которой забыл написать в канале.

На апрельском Q&A Angular community сообщили об изменении roadmap. В частности, о приостановке внедрения selectorless подхода для компонентов. Приоритетом стала стабильность синтаксиса для корректной генерации кода AI инструментами, т.к. они эффективны, когда используется консистентный и хорошо изученный синтаксис.

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

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

#angular

NgStream