Angular *

Асинхронное управление событиями в Angular-приложениях — одна из основных задач при разработке, особенно если приложение активно взаимодействует с динамическими данными или имеет сложную архитектуру. Зачастую для решения этой задачи разработчики используют подписки и/или промежуточные сервисы. Несмотря на популярность этих подходов, они могут приводить к избыточным зависимостям, высокому уровню связности и сложному коду.

Библиотека @artstesh/postboy предоставляет альтернативный взгляд на эту проблему: она позволяет избавиться промежуточных сервисов и использовать асинхронные события простым и лаконичным способом.

RxJS (Reactive Extensions for JavaScript) — мощный инструмент для работы с асинхронными потоками данных, который используется во многих современных веб-приложениях. Хотя RxJS предоставляет богатую коллекцию операторов, иногда для решения специфических задач бывает необходимо писать свои собственные. Это позволяет избежать дублирования кода и повысить читаемость программы.

Создание своих операторов RxJS может показаться сложным, особенно для тех, кто только начал использовать библиотеку. Однако, фундаментальные принципы их разработки понятны, если погрузиться в механику работы RxJS. В этой статье мы углубимся в то, как создавать собственные pipeable и creation operators, а также рассмотрим практические примеры их применения.

Я и сам до конца не знаю, является ли заголовок статьи кликбейтом или нет. Разберёмся в комментариях. Только давайте по-честному! Согласен с тезисами — напиши, что статья огонь, поставь лайк и всё такое. Не согласен — аргументируй, а не просто: «бред»! Есть что добавить (идеи, фишечки) — добро пожаловать в комментарии.

Привет, меня зовут Андрей Шпилевский, и в этой статье я расскажу, почему я делаю тестовое лучше большинства, а также дам советы, как проходить этот этап быстро и максимально эффективно. Тема достаточно большая, поэтому будет разбита на 3 части. Это первая и начну ее я, пожалуй, не с советов: ‘Делай так, спина болеть не будет’, а с лирического вступления, которое, на самом деле, важнее, чем какие-либо пункты.

Я разработал небольшое фулстек-приложение в качестве примера REST + WebSockets бойлерплейта на NestJS и Angular. В приложении используется PostgreSQL для хранения данных, Redis для кэширования и Minio для работы с файлами. Изначально целевой средой для развертывания был Kubernetes, но для ускорения разработки и тестирования MVP я решил использовать бесплатные облачные сервисы: Supabase для инфраструктуры и Vercel для деплоя бэкенда и фронтенда.

Если вы разрабатывали приложения на Angular, то наверняка сталкивались с ситуацией, когда множество компонентов требуют тесного взаимодействия друг с другом. Количество @Input, @Output, Services и Subjects растет с каждым коммитом и требует все больших усилий для сохранения качества кода...

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

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

Многие, конечно, знают, что в Angular-сообществе принято трепетно следить за подписками на Observable, потому что это чревато утечками памяти. Но не все видели эти утечки в глаза и не встречались с их последствиями. Давайте смоделируем простую ситуацию по следам утечки, с которой недавно столкнулся я (первый раз).

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

Не найдя ни одной статьи на русском на это тему - родилась эта :-)

Я разобрал официальную дорожную карту Angular и их стратегию на ближайшие годы. Впереди ускорение, упрощение, новая реактивность и стабильная (возможно) жизнь без zone.js. Давай разбираться, что нас ждёт!

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

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

Библиотека Log4ts вдохновлена идеями Log4J и обеспечивает логирование в программах, написанных на  TypeScript.
Далее в этой статье я расскажу о том, как её установить, использовать и конфигурировать.

А в конце я опишу коротенько другие мои библиотеки, которые тоже не должны были бы существовать.

Привет! Я Даниил, занимаюсь разработкой на Angular в T-Банке и хочу поделиться с вами опытом использования фикстур в Playwright. Я решил поговорить об этом, потому что вместе с ростом функциональности проектов растут и сложности при тестировании, а фикстуры предоставляют удобный способ избавиться от дублирующегося кода и сложных моков.

Эта статья посвящена основам: зачем нужны фикстуры, чем они отличаются друг от друга и какую пользу приносят при тестировании веб-приложений. Мы подробно разберем устройство фикстур, посмотрим, как их создавать и грамотно внедрять в тесты. А еще рассмотрим практические примеры, которые помогут с легкостью применить полученные знания на реальном проекте. Поехали!

Текущее руководство по стилю было создано ещё в 2016 году, когда только появился переработанный Angular v2.0. Как пишет Джереми Эльбурн (разработчик Angular с 2012 года и технический руководитель проекта), многое изменилось, пора изменить и принятый стиль разработки, поэтому предложен RFC:

Перевод статьи с официального сайта документации Angular

Довольно часто нужно создавать компоненты, которые служат в качестве контейнера для различного типа контета. Например, вы хотите создать камстомный компонент карточку (CustomCard):

В этой статье я расскажу о добавлении нового поля workUntilDate с типом timestamp(6) в таблицу Webhook базы данных Webhook.

На стороне фронтенда (в Angular-приложении) для этого поля будет реализован удобный календарь с возможностью выбора времени.

Пользователи смогут задавать дату и время в своей временной зоне, тогда как бэкенд (NestJS-приложение) будет сохранять введённые данные в базе данных в формате UTC+0.

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

Вы создали новое Angular‑приложение, подключили популярный CSS‑фреймворк, но вместо ожидаемого вау‑эффекта столкнулись с проблемами: стили выглядят не так, как хотелось, валидация форм работает странно, а некоторые элементы вообще не реагируют на изменения состояния. Знакомо? Это типичная ситуация, когда CSS‑фреймворки интегрируются без учета особенностей Angular.

Эта статья поможет вам разобраться, почему возникают такие трудности, и покажет, как правильно интегрировать CSS‑фреймворки в Angular. Мы рассмотрим ключевые проблемы, разберем их решения и реализуем стильное, реактивное поле ввода с применением лучших практик Angular.

В Angular 15 появилась новая фича, которой не уделяют должного внимания, — Directive Composition API. Она добавляет hostDirectives: [...] в декоратор @Component/@Directive. В этом массиве можно перечислить standalone-директивы, которые хотим автоматически навесить на компонент или директиву. Это позволяет очень удобно декомпозировать логику и открывает много дверей для новых подходов к разработке.

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

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

Всем привет! На связи руководители Frontend‑практики ГК Юзтех. В этой статье мы подводим итоги 2024 года и делимся нашими прогнозами на 2025 год. Приводим мнение трех экспертов по ключевым трендам фронтенд‑разработки и фреймворков, которые будут актуальными в следующем году.

В этой статье я хотел бы поделиться своим опытом по внедрению поддержки временных зон в фулстек-приложение, построенное на NestJS и Angular. Мы узнаем, как сохранить настройки таймзоны пользователя в базе данных и правильно использовать их при взаимодействии с сервером через REST и веб-сокеты.

Закладки — самое ужасное изобретение человечества... Ну ладно, возможно, я немного утрирую, не самое, а только лишь одно из самых.

Закладки в браузере, список статей для прочтения в Pocket, закладки в популярных блогах типа Хабра и прочие списки из разряда "прочитать позже". Если у вас эти списки пусты или регулярно очищаются, вам не понять нашей печали.

Вроде бы полезная идея — закладки, но для многих она очень быстро превращается в бесполезную, бессмысленную свалку, в которую ты по привычке докидываешь всё новые и новые статьи, которые обязательно пригодятся или которые ты непременно должен прочесть (когда-нибудь в следующей жизни).

Это, можно сказать, болезнь. А какой первый шаг на пути к выздоровлению? Правильно, сознаться самому себе, что ты болен и что тебе нужна помощь. Пора признать и осознать тот факт, что всё или подавляющее большинство из того, что попадает в твои закладки, теряется там навсегда, и ты никогда к ним не вернёшься.

Предлагаю сегодня обсудить эту проблему и её возможные истоки. А в конце статьи я предложу тебе немного неожиданный, необычный и нестандартный подход к ее решению. Этот подход определенно поможет тебе избавиться от "закладочной зависимости" и гарантирует, что больше у тебя не будет сотен бессмысленных закладок.

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

В этой статье исследуем директиву ActiveZone — подход, который мы использовали в библиотеке компонентов Taiga UI. Она полагается на два моих любимых инструмента Angular: Dependency Injection и RxJS. Нам понадобится глубокое понимание нативных событий DOM. Как бы ни был далек Angular от чистого JavaScript и DOM, он все равно полагается на старые добрые Web API, поэтому важно качать свои знания и в области ванильного frontend.