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

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