Angular *

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-разработчик на существующем проекте.

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

Всем привет! 👋 Меня зовут Мансур, я фронтенд-разработчик в payme — в одном из крупнейших финтех-сервисов в Узбекистане, через который ежедневно проходят миллионы транзакций. Помимо основной функции, мы активно развиваем дополнительное направление Lifestyle-сервисов внутри мобильного приложения. В этом посте хочу поделиться практическим опытом внедрения WebView: расскажу, как мы используем его в продуктах payme avia и payme tickets, почему выбрали именно такой подход, какие преимущества он даёт, и с какими ограничениями приходится мириться на практике. 

Если вы не сталкивались с WebView раньше — это такой способ внедрить веб-страницу прямо внутрь мобильного приложения. И да, звучит как костыль, но на деле — мощный инструмент, если знать, как с ним обращаться.

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

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

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

Хорошая отказоустойчивость начинается с мышления.

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

Принципы описанные ниже в большинстве своем универсальные и подойдут к большому количеству сфер, даже вне области информационных технологий. Но моя основная опора будет на сферу веб-разработки

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

- Почему важно писать юнит-тесты
- Зачем мокать зависимости и каковы плюсы и минусы
- Что такое SIFERS и почему это важно
- Что такое Angular Testing Library (ATL)
- Как тестировать с помощью SIFERS
- Как получать элементы DOM и генерировать события
- Что такое jest-auto-spies и observer-spy

Важность надежной обработки запросов в оффлайн-режиме невозможно переоценить, особенно для приложений, которые должны функционировать и в отсутствии интернет-соединения. Workbox - это мощный инструмент для управления Service Worker в браузерах, он как раз призван решать подобную задачу при помощи соответствующего плагина, но поддержка Background Sync API не универсальна. В этой статье я покажу, как расширить Workbox, чтобы Background Sync корректно работал даже на платформе iOS/Safari.

Angular 20 — это мощное обновление, которое делает разработку веб-приложений быстрее, удобнее и современнее. Новые возможности шаблонов, стабильные сигналы, поддержка zoneless режима и интеграция с AI позволяют создавать высокопроизводительные приложения с минимальными усилиями. В этой статье разберём ключевые нововведения Angular 20 и покажем, как их использовать в ваших проектах.

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

Предлагаю нестандартный подход к изучению темы. Возьмем непопулярную точку зрения: мой многолетний опыт разработки огромной коллекции библиотек с компонентами под Angular — продукт под названием Taiga UI. В статье мы опустим многие заезженные фичи каждой мажорной версии Angular и сфокусируемся на кажущихся мелочах, которые стали значимыми шагами в истории развития нашего семейства библиотек. Я постараюсь на время статьи дать примерить шкуру разработчика Angular UI Kit!

Во фронтенд-разработке довольно быстро возникает вопрос: как всё оформить удобно, красиво и единообразно? Сначала всё кажется очевидным – документация показывает, как создать базовый building block, компонент, а дальше чередуй ими и жонглируй, как душе угодно. Более того, можно сильно сэкономить время, используя готовые UI-библиотеки, в которые уже вложены десятки человеко-часов. Но, по мере поступления всё новых задач, порой встают вопросы, которые в какой-то момент побуждают к написанию своего собственного UI Kit.

Сначала это может показаться сложным, муторным, ещё и нужно довольно хорошо разбираться в используемом техстеке. У Angular, например, есть репутация громоздкого фреймворка: не самая очевидная документация, не особо широкое сообщество и меньшая популярность по сравнению с React. На деле всё не так страшно. Angular активно изменяется и улучшается, притом, как и раньше, предоставляя всё необходимое для построения реактивных web-приложений.

Я считаю, что разработка собственной библиотеки компонентов на Angular – это не подвиг, совершённый «вопреки», но вполне разумный инженерный выбор, если подойти к этой задаче последовательно.

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

В этой статье мы пошагово разбираем настройку компонента Alert через SCSS-переменные и структуру дизайн-системы. Вы увидите, как централизованно управлять стилями и при этом не потерять гибкость. Такой подход экономит время и облегчает жизнь команде разработчиков.

Представьте: вы — инженер-программист из 60-х. Ваш код — это дикие прерии, где goto прыгает через функции как ковбой через барную стойку, а память — ваше личное ранчо. Вас внезапно переносят в 2023 год. Вас окружают фразы вроде «SOLID», «иммутабельность», «реактивные потоки». Вы пытаетесь написать пару строк на Python, но слышите: «Стоп. Мутировать переменные? В 2023-то? Это же грех!».

Что случилось с нашей свободой?

За последние 70 лет программирование из искусства постепенно превращалось в ремесло со своими жёсткими требованиями и правилами. Мы больше не взламываем реальность — мы строим мосты по ГОСТу.

Вы уже встречались с этими "веселыми" историями, когда разработчик заканчивает работу над задачей, она проходит тестирование, отправляется в прод, а там встречается неожиданным отказом какого-нибудь мелкого метода api и укладывает всё приложение так, что пользователи наблюдают только белый экран?

Я в своё время познакомился с ними чересчур близко... И, честно сказать, потоки RxJs прекрасные учителя - тебе не захочется снова повторять их уроки. Чему же они нас учат? В первую очередь тому, что не стоит доверять внешним источникам; вы не контролируете ни соединение с сервером, ни api-сервис, а значит не имеете никаких оснований слепо доверять им и ожидать безотказной работы.

Введение: Архитектурное дежавю

Вы когда-нибудь замечали, как цифровой мир движется по спирали? В 2018 году я, размахивая Dockerfile и Helm-чартами, внедрял микросервисы на C# с RabbitMQ — всё ради священной цели «низкой связанности». А через три года, переключившись на Angular, с ужасом осознал: фронтенд-компоненты общались через цепочки Input/Output, словно это 2005-й, а мы пишем WinForms.

Это как собрать космический корабль, но управлять им через телеграф. На бэкенде мы гордо декларируем event-driven architecture, а на фронтенде компоненты перешёптываются через пропсы, будто подростки на школьной дискотеке. Ирония? Чем сложнее становились наши системы, тем больше они напоминали те самые монолиты, от которых мы бежали в мире backend.

На протяжении первой, второй и третьей статей мы прошли вместе довольно увлекательный путь: от первого знакомства с Observables, где разобрались с основами реактивного подхода, через освоение операторов, которые позволили нам эффективно преобразовывать и фильтровать данные, до комбинирования потоков, открывшего возможности для синхронизации данных из нескольких источников. Мы постепенно превращали RxJS из интересного инструмента для экспериментов в мощный инструмент для реальных задач.

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

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

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