Angular *

Тестирование — неотъемлемая часть разработки, особенно если речь идёт о сложных приложениях. Оно позволяет нам быть уверенными в качестве кода и предотвращать неожиданные ошибки. Но важный вопрос, который рано или поздно возникает у каждого разработчика: как балансировать между качественным покрытием тестами и затратами на их написание? И, что ещё более важно, как справляться с рутиной при этом?

Работа с тестовыми данными — проблема, способная выжать все силы у даже самых терпеливых разработчиков. Простые тесты с примитивными параметрами пишутся быстро и легко. Но когда ваш метод оперирует сложными объектами с вложенными структурами, ситуация усложняется многократно. С каждым новым тестом всё больше времени уходит на составление данных, разрушая читаемость и увеличивая объём работы.

Эта история — не про рекламу библиотек или продвижение инструментов. Это мой личный опыт борьбы с типовыми проблемами генерации данных в тестах TypeScript. Я решил поделиться тем, с какими сложностями я столкнулся, как привычные подходы из других языков не сработали и к каким решениям в итоге удалось прийти и, возможно, найти новый взгляд на проблему от сообщества.

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

Чем мы займемся? План на сегодня такой:

• Разберем, чем может быть полезна маркерная доска для личного пользования, саморазвития, изучения иностранных языков и пр.;

• Реализуем виртуальную доску, которая будет "мозолить" нам глаза и не даст забыть о важном;

• Разберем некоторые технические подробности реализации, а заодно уличим хваленые ведущие LLM в обмане;

• Вспомним детство — порисуем на холсте.

Всем привет, с вами Максим Иванов, и сегодня мы поговорим о некоторых улучшениях, которые появились в последней версии Angular 19, вышедшей в ноябре 2024. Публикация довольно запоздалая с этой точки зрения, но мы сегодня постараемся рассмотреть некоторые нововведения более детально. Как и всегда ребята из Google дарят нам что-то новое, что сделает наши приложения еще более быстрыми и эффективными. И в этом нам помогут модерновые реактивные примитивы, инкрементальная гидратация и многое другое.

Всем привет! Меня зовут Илья Чубко, я технический архитектор K2Тех.

В этой статье я подробно опишу процесс создания SIP-клиента на Angular с использованием SIP.js, настройку сервера Asterisk на CentOS 9, обеспечение защищённого соединения через TLS и настройку WebRTC для совершения звонков.

Чтобы эффективно использовать сигналы Angular Signals, вам нужно понимать концепцию «реактивного контекста» и то, как работает отслеживание зависимостей. В этой статье я объясню обе эти вещи и покажу, как избежать некоторых связанных с ними ошибок.

Angular предоставляет мощный механизм Dependency Injection (DI), который делает приложения модульными и тестируемыми. В этой статье мы рассмотрим базовые механизмы работы DI-контейнера Angular, разберем иерархию инжекторов, ключевые роли @Injectable и @Optional, а также рассмотрим создание кастомных провайдеров и их применение в сложных проектах.

Асинхронное управление событиями в 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.

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