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

Скоро в тур?

Нейросети сейчас съедают все наше внимание: куда ни глянь - везде новости, прорывы, новые высоты. В IT это уже стало обыденностью, и именно в нашей сфере, кажется, наибольший процент пользователей.
ИИ стал нашим напарником, протезом для интеллектуальной работы. Появилось даже целое явление - вайбкодинг.
Но использование ИИ давно вышло за рамки «напиши оптимальную функцию» и уже вливается в совершенно другие сферы.

И вот я решил провести эксперимент - «повайбкодить» там, где у меня мало опыта. Хотелось поймать то самое ощущение: написал что-то в чат - и оно магическим образом заработало. Честно говоря, в программировании этой магии почти нет, потому что ты понимаешь, что именно тебе отдал ИИ, или хотя бы можешь разобраться.
Выбор пал на музыку. Почему? Ну потому что если бы не IT, то наверняка ушел бы в музыку. Она для меня наибольший источник восхищения, вдохновения и эмоций.

Исходные данные: базово разбираюсь в музыке (по внешнему виду можно подумать, что с 7 лет рублюсь в шведской металкор-группе), в школе ходил в музыкалку, дома всегда есть пара гитар (иногда попадают в руки, хотелось бы чаще). Музыкальной насмотренности хватает, слушаю постоянно и много. Но вот шанс самому что-то написать практически нулевой. И это как раз и нужно для эффекта эксперимента.
Из инструментов выбрал Suno. Чаще всего видел его в инфополе, поэтому выбор очевиден. Аккаунт зарегистрирован, поехали!

И вот наступает магический момент вайбкодинга: вводишь текст в пару окошек и оно работает. Вау!
Около трех часов ушло на прощупывание работы ИИ: как он обрабатывает текст будущей песни, как работать с жанрами, деталями и т.д. Потратил все стартовые токены и решил оформить премиум-подписку, чтобы открыть полноценный редактор и больше возможностей.
С жанром определиться оказалось на удивление просто. Самым удачным оказался rap. Думаю, тут как с React: ИИ лучше работает с тем, чего больше в датасетах. А rap сейчас один из самых популярных жанров.

Идея есть, жанр выбран - идем в ChatGPT складывать слова. Сразу отмел «серьезные» тексты вроде «я тебя любил, а ты ушла», поэтому выбрал концепцию: сделать шутку про фронтенд. Накидал идей, но уперся в проблему: ChatGPT — очень слабый автор, не умеет рифмовать и хитро упаковывать смыслы. Пришлось брать все в свои руки.
На текст ушло два вечера. Не работать мне гострайтером с такими темпами. Вышло ужасно, но эксперимент же и все шутки ради.
После загрузки текста я понял, что нарушен ритмический рисунок, и ИИ начинает «фигачить» мимо. Пришлось дорабатывать. Полдня ушло на выравнивание текста.

Самая сложная часть - объяснить ИИ, что именно я хочу на выходе. Сначала пробовал длинными промптами - результат был неплохой, но сырой. Потом подсмотрел, что можно прямо в тексте указывать подсказки: где громче, где с надрывом, где акцент на слог, где проигрыш и т.д. Добавил это и стало получаться реально хорошо. Удачные варианты можно брать как основу и дорабатывать уже в редакторе, даже выгружая в DAW.

Итог трех дней с Suno:
🔘 Потрясающе провел время всего за 1000 рублей подписки. Почувствовал на себе вайбкодинг
🔘 Из одного текста сделал аж две версии трека - на мой взгляд, отличный результат

Что не получилось?
Научить использовать свой голос. Делал все по гайду: загружал референсы, напевал в микрофон. Но в финале голос был уже не совсем мой. Если бы получилось, было бы вообще отпад.

В целом — всем советую попробовать ИИ в «чужой» сфере. Эмоции реально непередаваемые.
Ну и, конечно, прикладываю треки на заценку. Пишите, какой зашел больше. А если никакой, тоже пишите, вместе посмеемся. 🕺 🎧

@summon_the_coder | chat$.subscribe()

#frontend #music #ai

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

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

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

@summon_the_coder | chat$.subscribe()

#angular #react #deferrableviews

хе-хе, да это же была просто шутка 🥲🥲🥲