letify - звучит как заклинание, работает как по волшебству ✨

Обновлял зависимости одного из проектов и заметил, что библиотека для интернационализации @ngneat/transloco переехала в новый скоуп @jsverse/transloco. После успешного обновления решил заглянуть на GitHub @jsverse и поискать, что еще у них есть интересного. Так я и наткнулся на героя этого поста — @letify.

Letify CLI помогает оптимизировать шаблоны в Angular приложениях, сканируя файлы и обнаруживая несколько асинхронных подписок на один и тот же поток.

Пример:

<div>{{ observable$ | async }}</div>
<div>{{ observable$ | async }}</div>

observable$ = this.appService.makeSomeAction()
.pipe(
  tap(() => console.log('Side effect logic'))
);

В этом сниппете на поток observable$ создаются две подписки, и побочные эффекты (tap) выполняются дважды. Это может привести к багам и некорректной работе приложения.

🧐 Что делать в таких случаях?

*️⃣использовать директиву *ngIf или control flow синтаксис @if, чтобы подписка происходила один раз;

@if (observable$ | async) {
  ...
}
// или
<ng-container *ngIf="observable$ | async">...</ng-container>

*️⃣ использовать новый синтаксис объявления переменных в шаблоне @let (v18.1 - dev preview, v19 - stable);
*️⃣ если данные используются в разных частях шаблона и их нельзя объединить в одном блоке, поможет оператор shareReplay, который «разделит» поток между всеми подписчиками и вся логика будет выполнена один раз.

observable$ = this.appService.makeSomeAction()
.pipe(
  tap(() => console.log('Side effect logic')),
  shareReplay({ bufferSize: 1, refCount: true })
);

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

▶️ У инструмента два режима работы:
*️⃣analyze — показывает потенциальные проблемы в шаблонах;
*️⃣fix — автоматически добавляет @let и убирает лишние подписки. По завершении выводится сообщение с напоминанием вручную проверить внесенные изменения.

▶️ Форматы отчетов:
*️⃣html — подробный отчет с UI, переключателями и разбивкой по файлам;
*️⃣json — пригоден для интеграций;
*️⃣list — простой список для отображения в терминале.

Какие сценарии использования я вижу, если используем локально для lint-staged, то самый быстрый вариант это вывести list-отчет. Если же встраиваем в CI/CD, то генерируем html и прикладываем его к артефактам пайплайна.

✖️ Минусы:
*️⃣fix-режим работает только с Angular 18+;
*️⃣шаблон должен быть в отдельном файле (запускал для inline шаблонов, ошибок не нашел);
*️⃣закомментированный код пропускается при проверке;
*️⃣конструкции вида data[prop] | async и myMethod(value, ...) | async пока не поддерживаются.

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

P.S. Собрал простую демку для теста - stackblitz

@summon_the_coder

#angular #library

LLM промпты для Angular

В документации Angular совсем недавно появился многообещающий раздел про AI. Внутри гайд по разработке AI-powered приложений с использованием Genkit, Firebase AI Logic и Gemini API, как подружить эти инструменты и ворваться в современный мир вайб разработки. 🔫

А буквально вчера добавили еще один раздел с промптами для LLM, предназначенными для более точной генерации кода (в наличии инструкции для Firebase Studio, Cursor, JetBrains IDE).
⠀
Я ознакомился с базовым промптом и, кажется, это еще и отличный шортлист для мясных разработчиков — в нем собраны актуальные best practices для современных Angular приложений. Пользуемся! И по всей видимости ждем схематик ng generate ai-awesome-component. 😂

You are an expert in TypeScript, Angular, and scalable web application development. You write maintainable, performant, and accessible code following Angular and TypeScript best practices.

## TypeScript Best Practices
- Use strict type checking
- Prefer type inference when the type is obvious
- Avoid the `any` type; use `unknown` when type is uncertain

## Angular Best Practices
- Always use standalone components over NgModules
- Don't use explicit `standalone: true` (it is implied by default)
- Use signals for state management
- Implement lazy loading for feature routes
- Use `NgOptimizedImage` for all static images

## Components
- Keep components small and focused on a single responsibility
- Use `input()` and `output()` functions instead of decorators
- Use `computed()` for derived state
- Set `changeDetection: ChangeDetectionStrategy.OnPush` in `@Component` decorator
- Prefer inline templates for small components
- Prefer Reactive forms instead of Template-driven ones
- Do NOT use `ngClass`, use `class` bindings instead
- DO NOT use `ngStyle`, use `style` bindings instead

## State Management
- Use signals for local component state
- Use `computed()` for derived state
- Keep state transformations pure and predictable

## Templates
- Keep templates simple and avoid complex logic
- Use native control flow (`@if`, `@for`, `@switch`) instead of `*ngIf`, `*ngFor`, `*ngSwitch`
- Use the async pipe to handle observables

## Services
- Design services around a single responsibility
- Use the `providedIn: 'root'` option for singleton services
- Use the `inject()` function instead of constructor injection

@summon_the_coder

#angular #ai #llm

Angular Wiki

Как правильно писать на Angular? Как сделать функционал Х 'in angular way'? Какие best practices есть во фреймворке? Это только маленькая часть вопросов, которые возникают у разработчиков во время изучения и работы с фреймворком. Ответить на все сразу сложно, слишком объемным и сложным получится ответ. Нужно умудриться рассказать про typescript, реактивность (RxJS и сигналы), DI, работу с DOM, формы и много еще о чем. Я даже подумывал выпускать небольшие заметки на канале, чтобы покрыть эти вопросы. Но интернет это бездна, в которой есть вообще все и проведя исследование, я обнаружил целую вики для Angular!

🔗 Angular Tips

Эта вики посвящена новым версиям фреймворка (пока можно переключаться между 19 и 20) и описывает не только хорошие, но и плохие практики, что на мой взгляд тоже крайне важно. У каждой практики есть 3 индикатора:

🟢do - крайняя степень рекомендации, желательно следовать (но разумеется финальный выбор всегда за разработчиком и все мы понимаем, что из-за разных факторов код может иметь отклонения даже от самых строгих практик);
🟡consider- стоит обратить внимание, было бы неплохо так делать;
🟣avoid - так не делаем, руки прочь от клавиатуры.

Кроме того, у каждой рекомендации есть дополнительные блоки: «Why» и «Tip». Первый объясняет, почему стоит делать так или иначе, а второй содержит небольшие подсказки и дает контекст для применения.

И что приятно — все это красиво визуализировано: присутствуют понятные иконки (Good/Bad), примеры кода и поясняющие комментарии. Многие разделы (например, типизация, структура проекта, работа с библиотеками, HTTP-клиент и др.) по сути являются фреймворк-агностичными и применимы и в других технологиях.

Так что минус десять очков Гриффиндору! Ой, то есть порогу входа в Angular. Все-таки с такими ресурсами изучать фреймворк становится куда проще.

🔗 Angular Tips

@summon_the_coder | chat$.subscribe()

#angular #learning #tips

Angular ESLint больше не страшно

Как же я люблю статические анализаторы кода и результат их работы: порядок в коде, форматирование, отсортированные импорты, единообразие в порядке ключей объектов (да, и такое люблю!) и много чего еще.
Но как же я не люблю все это настраивать. Да, конфиги более-менее повторяются, но все равно приходится что-то допиливать руками.
А с новым flat-конфигом ESLint я до сих пор не подружился — использовал настройку по наитию, и пока все работает. Меня очень спасает ESLint Config Inspector, но умеет работать только с flat-конфигами. В общем, настройка проекта для меня — это всегда маленькая паника. 😳

Для страдающих, хороший стартовый ESLint шаблон: NG Best Practices: Prettier & ESLint

Для Angular есть отдельный пакет angular-eslint, который предоставляет специфичные для фреймворка правила — отдельно для шаблонов и для TypeScript-компонентов.
В Nx уже есть базовая преднастройка angular-eslint с рекомендованными правилами. Но и здесь иногда нужно, или даже приходится, подкрутить гайки: добавить или убрать какое-то правило. И тогда приходится лезть в репозиторий angular-eslint и внимательно читать, что за что отвечает и какие настройки есть. Максимально фрустрирующе! ☔️

Господи, мои молитвы были услышаны — ребята из Angular Courses выпустили новый инструмент: GUI для настройки ESLint под Angular.
Правила разбиты на группы: общие, компоненты, Typescript, RxJS и т.д. Можно выбрать нужные чекбоксы или просто нажать кнопку «Сделать все по красоте» aka «Выбрать все».
Для каждого правила есть сниппеты кода, показывающие, как оно работает. А еще — значок, указывающий, что правило рекомендовано официальным style guide’ом.
На выходе можно экспортировать конфиг в виде markdown-файла с примерами кода (например, чтобы вставить в вики проекта) или сразу как готовый .eslint.config.js.

Все, вот так просто! 🕺
Конфигуратор пока еще в альфа версии, будем следить за обновлениями. Пожалуй, мой самый любимый инструмент среди разрастающегося тулинга Angular. Хотелось бы все настраивать таким образом, но пока это мечты.

🌟 Настроить Angular ESLint

@summon_the_coder | chat$.subscribe()

#angular #eslint #bestpractice

Angular 21 - Http клиент поселился в root

Мы молились и прочитали все молитвы дважды, попутно стерев все колени, и наконец-то в 21 версии Angular не нужно будет из коробки провайдить HttpClient в настройках приложения. Клиент будет использовать root-инжектор по умолчанию и попадать в бандл, когда нам это нужно: при inject(HttpClient) или использовании httpResource. Ручное добавление провайдера останется для случаев, когда нужно что-то настроить: переключить на fetch, докинуть интерцептор и т.д.
Никогда не понимал этой особенности с ручным провайдером для клиента, иными словами где вы видели фронтенд без запросов к серверу?

🔘 Подсмотрел новость здесь.
🔘 Закрытый pull request с фичей.
🔘 Полюбоваться кодом клиента с root-инжектором.

@summon_the_coder | chat$.subscribe()

#angular #httpclient

Бумеры на месте?

В конце 2024 года команда Angular открыла RFC для обсуждения обновленного стайлгайда. Один из пунктов предлагает отказаться от суффиксов в названиях файлов и классов. То есть вместо привычных .component, .service, .pipe, .directive рекомендовано использовать осмысленные имена файлов. А в классах убрать «Component/Service/Directive» и писать просто App, Home и т. п. Идея команды - сконцентрироваться на «говорящих» именах, условный user.service.ts действительно не дает полного понимания того, что именно делает класс (и да, отчасти это правда).
Предложение ожидаемо вызвало недоумение у разработчиков, которые много лет работают с Angular и привыкли к устоявшимся соглашениям.

Я сам недавно вплотную столкнулся с новым неймингом: стартовал пару боевых проектов и сделал несколько учебных демок на Angular 20. Первые впечатления - даже немного радостно: имена короче, standalone-компоненты можно создавать без участия CLI, сделал button.ts, и готово. Раньше, конечно, тоже можно было, но «соглашение — есть соглашение».

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

1️⃣ внутри модуля/фичи выделять слайсы (читай директории) и тонко работать с импортами, чтобы избегать коллизий имен (прощай flat структура)

2️⃣ вносить в имя файла роль/назначение сущности, чтобы оно было по-настоящему осмысленным (прямо по заветам RFC)

С первым пунктом вопросов нет, это обычный рабочий флоу во многих современных проектах. Со вторым же пунктом пришлось повозиться и заглушить привычки, чтобы начать писать именно нормальный нейминг, а не скатываться в привычные *.service.ts файлы.

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

{
   "@schematics/angular:component": { "type": "component" },
   "@schematics/angular:directive": { "type": "directive" },
   "@schematics/angular:service": { "type": "service" },
   "@schematics/angular:guard": { "typeSeparator": "." },
   "@schematics/angular:interceptor": { "typeSeparator": "." },
   "@schematics/angular:module": { "typeSeparator": "." },
   "@schematics/angular:pipe": { "typeSeparator": "." },
   "@schematics/angular:resolver": { "typeSeparator": "." }
}

Ну а для совсем ленивых, ну то есть для всех разработчиков (хе-хе), есть пакет с забавным названием ngx-boomer, который добавляет настройки для схематиков автоматически. Запускаем без установки через npx и сидим кряхтим, что раньше было лучше! Ведь было же!?

🌟 вернуть все как было

@summon_the_coder | chat$.subscribe()

#angular #styleguide #schematics

Находчивое напряжение или Остроумный саспенс (перевод by AI)

На gitnation.com вышел доклад Minko Gechev, техлида в Google, где он сравнивает подходы к отложенной загрузке, префетчингу и гидрации компонентов в Angular (Deferrable Views) и React (Suspense).
Главная мысль — не существует «хороших» или «плохих» технологий — есть те, что быстрее, удобнее и дешевле решают именно вашу задачу, нужно найти подходящий компромисс. Поэтому не стоит строго «играть» за одну команду, пробуйте больше инструментов и подходов, чтобы находить лучшее решение под конкретный контекст. Особенно актуальна эта мысль в эру ИИ, когда технологии можно щупать без каких либо проблем.
Ну а где код получился декларативнее и понятнее, спойлерить не буду. 👋

▶️ смотреть доклад "Resourceful Suspense"

@summon_the_coder | chat$.subscribe()

#angular #react #deferrableviews

🚨 Alert! 20 (двадцать!) дней до митапа

Осень, как обычно, богата на различные мероприятия — конференции, митапы, сходки. А еще есть основная работа, работа в эдтехе, сторонние проекты, чуть-чуть менторства. И во всем этом круговороте нужно еще и пожить успеть, и про себя не забывать.
Но одно предстоящее мероприятие — самое-самое. И именно подготовка к нему забирает почти все силы и время. Сделать интересный, технически дотошный и просто нескучный доклад это целая наука (кто бы знал да). Для большинства спикеров это будет «самый первый раз», поэтому мы вмногером практически каждую неделю делаем прогоны, делимся мнениями и стараемся конструктивно предлагать улучшения.

Немного приоткрою завесу над своим докладом — «Сигналы в Angular». Из названия не совсем понятно, а что там еще можно рассказать про сигналы? Кажется, все уже и так все знают. Тем более, название пока в статусе черновика, но, чувствую, таким оно и доедет до митапа. 🙈
Моя главная цель — донести до слушателей идею о том, что сигналы — это не просто очередная модная игрушка для разработчиков, а сдвиг устоявшихся парадигм, новый способ мыслить о данных. Я расскажу, с чего все начиналось, к чему пришло, какие бонусы и какие трейд-оффы мы получили. Будет очень интерестинг!
Если сомнения еще одолевают, а 21 ноября в календаре является свободным слотом и намекает на какую-нибудь активность, то выход есть: Centi Conf.

Буду рад всех видеть и пообщаться лично! ❤️

🌟 купить билет и поднять уровень в одиночку знаний

P.S. А еще 20 ноября будет мероприятие (возможно и сразу релиз) про 21 версию angular. Так что на митапе можно будет обсудить наисвежайшие новости.

@summon_the_coder | chat$.subscribe()

#angular #meetup #centiconf