Angular *

Фронтенд-разработка в последние годы стала сложнее. Одностраничные приложения живут часами, пользователи открывают вкладки и оставляют их работать, данные приходят с серверов постоянно. В этом хаосе часто кажется, что главное — чтобы компонент рендерился, а Observable выдавал данные.

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

Для Angular‑разработчика это важно, потому что:

В данной статье будет предоставлена детальная информация по реализации высокопроизводительного вьюпорта мессенджера на Angular, который обеспечит высокую и плавную скорость работы и низкое потребление ресурсов с применением инструмента виртуализированных списков ng-virtual-list. А также представлен порт на React.

Всем привет! Меня зовут Александр Битько, я фронтенд-разработчик в ПСБ. Сегодня поговорим об одной из частых болей в работе с микрофронтенд-архитектурой — поиске баланса между независимостью микрофронтов и согласованным UI. Когда независимые микрофронты используют разные подходы к стилям (CSS-фреймворки, методологии вроде BEM или CSS-in-JS, глобальные стили), возникают конфликты с визуальной несогласованностью в приложении. Красная кнопка вдруг становится зелёной, шрифты начинают прыгать и так далее. 

Что с этим делать? В этой статье я расскажу о конфликтах стилей: какими они бывают, как с ними бороться и какие стратегии лучше подходят для приложений в разных случаях. И приведу примеры, как это работает на Angular и на React с использованием наиболее популярных библиотек Angular Matherial и MUI. Поехали.

ControlValueAccessor - это то, что отделяет профессиональную дизайн‑систему от набора костылей. Но как грамотно связать его с состоянием контрола (invalid, touched), не создав циклических зависимостей? Эта статья - не просто «ещё один туториал». Это пошаговое руководство по созданию универсального инпута на современном стеке: Signals, OnPush и безопасный инжект NgControl. Разбираем раз и навсегда.

Полная реализация push-уведомлений в PWA без сторонних сервисов

Разбираем архитектуру: Service Worker, Push API, VAPID ключи и Notifications API. Показываем, как настроить PWA для работы на всех платформах, включая iOS.

В статье:
• Теория всех компонентов системы
• Готовый код Service Worker и клиентской части
• Backend на Express с отправкой уведомлений
• Настройка PWA для iOS 16.4+
• Детекция платформы и предложение установки

Все работает из коробки! 🎯

Привет, Хабр! Меня зовут Игорь Поляков, работаю веб-программистом технологических приложений ВЕРТИКАЛЬ. В данной статье расскажу о стратегии обнаружения изменений в Angular с учетом обновлений фреймворка версии 17 и выше. Если вас беспокоит вопрос производительности и вы желаете разрабатывать оптимизированные приложения, добро пожаловать! 🚀

Как многие знают, Angular сделал большой шаг к тому, чтобы улучшить опыт использования AI. Но эта попытка затерялась на фоне куда более серьезных фичей, которые приковали к себе всё внимание коммьюнити (я имею в виду signals и zoneless). Тем не менее, на мой взгляд, Angular задал интересный тренд в мире фреймворков, который не стоит обходить стороной. Я попробовал воспользоваться новыми возможностями данного фреймворка в области использования AI, и в этой небольшой статье хотел бы поделиться своим опытом и первыми впечатлениями

Представьте, что вы делаете сайт-визитку или интернет-магазин на Angular. У вас есть главная страница, страница «О нас» и страница с товарами. Логично, что при клике на ссылки пользователь должен переходить между этими страницами

В классических сайтах это решается просто: при каждом клике браузер запрашивает у сервера новую HTML-страницу. Но в современных SPA (Single Page Applications) всё работает иначе — приложение загружается один раз, а дальше мы просто подменяем содержимое внутри него

Именно за это отвечает Angular Router.

Привет, Хабр! Я Антон Марченко, разработчик в Т-Банке. Поделюсь интересной задачей по работе с потоками на RxJS, которую мы однажды решали. Представьте платформу внутренних продуктов и сервисов, на которой реализован поиск по статьям и постам. Нам предстояло внедрить на сайт несколько внешних поисков: по пользователям, ссылкам и исходникам. А еще предусмотреть скелетоны и обработку ошибок и заложить возможность добавлять новые внешние источники поиска динамически, не дорабатывая каждый раз пользовательский интерфейс.

Пожалуй, самые неприятные баги – те, что воспроизводятся один раз из ста. Их не пощупать, не продебажить и даже не проверить результат.

Так и тут. Прилетает мне баг от тестировщика с описанием:

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

Естественно, у меня ни разу не воспроизвелось. Ну и как с этим работать?

Дальше расскажу о, возможно, самом странном баге в моей карьере.

Angular долгое время ассоциировался с RxJS. Даже слишком: многие разработчики ощущали, что без Observable ничего не работает. Но вот в Angular 17 появляются Signals — синхронная реактивность прямо из коробки. В 17+ — они становятся мейнстримом. Возникает вопрос: а что делать с RxJS? Выбрасывать?

Signals и RxJS — не конкуренты, а два мощных инструмента для решения разных задач. И если их правильно сочетать, можно построить удобную, масштабируемую и эффективную архитектуру.

Как инкрементальная гидратация в Angular помогает сделать приложения действительно быстрыми

Если вы когда-либо запускали SSR в Angular, вы наверняка сталкивались с этим парадоксом: страница вроде бы загружается молниеносно, но ощущается медленной. Контент есть, кнопки на месте — а кликаешь по ним, и в ответ тишина. Почему? Потому что браузер всё ещё «оживляет» интерфейс — запускает JavaScript, подключает обработчики, восстанавливает состояние. Это и есть гидратация, и в классическом исполнении она не так уж и быстра.

Пустые состояния (Empty States) — это незаметные, но критически важные элементы интерфейса. Что видит пользователь, когда список задач пуст, поиск не дал результатов или дашборд ещё не содержит данных? Пустой экран? Бесполезный спиннер? Или продуманное сообщение, которое помогает сориентироваться?

С появлением декларативного управления потоками (declarative control flow) в Angular обработка пустых состояний стала проще и элегантнее. Одна из ключевых возможностей — директива @empty, которая делает код чище, а интерфейс — дружелюбнее.

Давайте разберёмся, как это работает.

Dependency Injection (DI) один из столпов, на которых держится фреймворк Angular. Каждый разработчик, так или иначе, сталкивается с ним с первого дня: запрашивает сервисы в конструкторе, добавляет providedIn: 'root' и видит, как «магия» работает. Но именно в этом и кроется ловушка.

Для многих DI так и остается на уровне «магии» удобного механизма, который просто работает. Однако поверхностное понимание этого мощнейшего инструмента неизбежно приводит к архитектурным компромиссам: неочевидным утечкам памяти, сложностям в тестировании, созданию неявных связей между компонентами и, в конечном счете, к коду, который трудно поддерживать и масштабировать.

Эта статья не очередной пересказ официальной документации. Это глубокое погружение в архитектуру и философию Dependency Injection в Angular. Наша цель демистифицировать «магию» и превратить ее в предсказуемый, управляемый и мощный инженерный инструмент в вашем арсенале.

Мы пройдем путь от фундаментальных принципов инверсии контроля (IoC) до тонкостей иерархического инжектора. Мы разберем на атомы все стратегии предоставления зависимостей, научимся управлять их жизненным циклом и областью видимости. Мы изучим продвинутые паттерны с использованием InjectionToken и multi-провайдеров и поймем, как современная функция inject() меняет подход к композиции логики.

Привет! Я Незар, фронтенд-разработчик Т-Банка в одном из продуктов Т-Бизнеса. Наша команда использует Angular, и мы следим за всеми изменениями, которые с ним происходят.

В статье разберу, как Angular эволюционировал от Zone.js к Zoneless-приложениям с современным реактивным подходом Signal API и почему это стало ключевым шагом для повышения производительности и упрощения реактивного программирования. 

На примерах и замерах производительности посмотрим, как переход к Zoneless-подходу с Signal API позволяет сократить избыточные перерисовки, ускорить отклик приложения и сделать код значительно чище и предсказуемее. Сделаем Angular-приложения быстрее и проще, добро пожаловать под кат!

Всем привет, меня зовут Максим Иванов. В основном я пишу обзоры и русифицирую статьи для начинающих разработчиков. Я очень люблю Angular и иногда рассказывать что-то о нем. Если вы только начинаете свой путь в изучении этого фреймворка, надеюсь эта статья будет вам полезной. Cегодня мы с вами поговорим о том, что такое пайпы (pipes), как они устроены и что не так с одним из самых популярных и доступных из коробки пайпов, таких как async. Желаю приятного прочтения и хорошего настроения. Поехали!

В Angular любое изменение в компоненте, которое отображается на экране, является результатом работы механизма отслеживания изменений (Change Detection, CD). За этим процессом стоит Zone.js, который можно представить в роли дирижера, сообщающего компонентам о необходимости обновить DOM.

Zone.js не запускает CD сам. Он лишь создает контекст, в котором Angular потом может его запустить. Его задача только уведомлять Angular о завершении асинхронных операций, после чего Angular решает, нужно ли проверять изменения.

Чтобы понять важность такого подхода, нужно учитывать особенности JavaScript. В JavaScript асинхронные операции, такие как setTimeout или fetch, разрывают стек вызовов. Это значит, что callback-функция, выполняемая после завершения асинхронной операции, не имеет информации о контексте, в котором она была вызвана. Для фреймворка, который отслеживает изменения, это создает определенные трудности: как узнать, что асинхронная операция завершилась и, возможно, изменила данные?

Привет, Хабр!

Сегодня мы рассмотрим, как работает Injector в Angular, зачем нужны декораторы @Optional, @SkipSelf, @Host, и чем отличаются провайдеры на уровне root, модуля и компонента.

В классическом исполнении, списки включают в себя все элементы из коллекции. Другими словами, те элементы, которые не видны пользователю (находятся за пределами вьюпорта) все равно присутствуют в DOM дереве. А теперь представим, если список состоит допустим из 1 000 000 элементов, как это повлияет на производительность и ресурсоемкось? Ответ очевиден, пропорционально объёму коллекции будет расти ресурсопотребление и снижаться общая производительность.

Но к счастью для нас есть методы и алгоритмы позволяющие существенно ускорить работу таких «исполинских» списков.

Всем привет! Сегодня хочу разобрать кейс, с которым сталкивается почти каждый Angular-разработчик на существующем проекте.

Часто в компонентах можно встретить такой код: