Приветствую! Продолжаем разбирать возможности @artstesh/postboy и обсуждать, как сделать ваше приложение проще, а код элегантнее. Сегодня поговорим о том, что такое асинхронные команды и запросы, почему этот механизм так удобен, и как использовать его в реальных приложениях. Как всегда, всё покажу на живых примерах, чтобы можно было сразу применить на практике.
Проблема многих новичков, впервые сталкивающихся с темой подписок, заключается в обилии тем и нюансов, связанных с этим направлением. Тонны статей, дискуссий, документаций на темы, аля «RxJS mergeMap vs switchMap vs concatMap vs exhaustMap» могут вызвать головную боль уже в первые пятнадцать минут. Потому первый мой совет: ограничьте список тем и осваиваемых инструментов до самого минимума, декомпозиция важна везде и всегда — слона надо есть по частям. Так начинающий учиться шахматам сначала разбирает каждую фигуру в отдельности, запоминает возможности и нюансы, постепенно переходя к глобальной стратегии игры. Поэтому давайте смахнем все фигуры с доски и оставим там только пешку.
Тестирование — неотъемлемая часть разработки, особенно если речь идёт о сложных приложениях. Оно позволяет нам быть уверенными в качестве кода и предотвращать неожиданные ошибки. Но важный вопрос, который рано или поздно возникает у каждого разработчика: как балансировать между качественным покрытием тестами и затратами на их написание? И, что ещё более важно, как справляться с рутиной при этом?
Работа с тестовыми данными — проблема, способная выжать все силы у даже самых терпеливых разработчиков. Простые тесты с примитивными параметрами пишутся быстро и легко. Но когда ваш метод оперирует сложными объектами с вложенными структурами, ситуация усложняется многократно. С каждым новым тестом всё больше времени уходит на составление данных, разрушая читаемость и увеличивая объём работы.
Эта история — не про рекламу библиотек или продвижение инструментов. Это мой личный опыт борьбы с типовыми проблемами генерации данных в тестах 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:
