Привет, Хабр!
Сегодня мы рассмотрим, как работает Injector в Angular, зачем нужны декораторы @Optional, @SkipSelf, @Host, и чем отличаются провайдеры на уровне root, модуля и компонента.
В классическом исполнении, списки включают в себя все элементы из коллекции. Другими словами, те элементы, которые не видны пользователю (находятся за пределами вьюпорта) все равно присутствуют в DOM дереве. А теперь представим, если список состоит допустим из 1 000 000 элементов, как это повлияет на производительность и ресурсоемкось? Ответ очевиден, пропорционально объёму коллекции будет расти ресурсопотребление и снижаться общая производительность.
Но к счастью для нас есть методы и алгоритмы позволяющие существенно ускорить работу таких «исполинских» списков.
Всем привет! Сегодня хочу разобрать кейс, с которым сталкивается почти каждый Angular-разработчик на существующем проекте.
Часто в компонентах можно встретить такой код:
Всем привет! 👋 Меня зовут Мансур, я фронтенд-разработчик в payme — в одном из крупнейших финтех-сервисов в Узбекистане, через который ежедневно проходят миллионы транзакций. Помимо основной функции, мы активно развиваем дополнительное направление Lifestyle-сервисов внутри мобильного приложения. В этом посте хочу поделиться практическим опытом внедрения WebView: расскажу, как мы используем его в продуктах payme avia и payme tickets, почему выбрали именно такой подход, какие преимущества он даёт, и с какими ограничениями приходится мириться на практике.
Если вы не сталкивались с WebView раньше — это такой способ внедрить веб-страницу прямо внутрь мобильного приложения. И да, звучит как костыль, но на деле — мощный инструмент, если знать, как с ним обращаться.
Сегодня почти каждый веб-проект использует иконки. Это отличный инструмент визуальной коммуникации, который помогает акцентировать внимание на элементах интерфейса. Существует хорошая статья о том, почему стоит использовать иконки — "Icons in Web Design". Но эта статья отвечает на другой вопрос — как их использовать?
С хорошей отказоустойчивостью интерфейс остаётся стабильным и понятным, пользователь получает предсказуемый и комфортный опыт, а сбои отдельных компонентов не приводят к сбоям всей системы.
Хорошая отказоустойчивость начинается с мышления.
Важно не просто латать ошибки по мере их появления, а комплексно подходить к решению — формировать правильное понимание, разрабатывать устойчивые подходы и строить систему, способную адекватно реагировать на возможные сбои.
Принципы описанные ниже в большинстве своем универсальные и подойдут к большому количеству сфер, даже вне области информационных технологий. Но моя основная опора будет на сферу веб-разработки
В этой статье я хочу поделиться опытом, который накопил за годы работы с юнит-тестами в 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, избежать распространённых ошибок и стать разработчиком, который не только умеет создавать интересный код, но и делает его надёжным, оптимизированным и удобным для любых условий эксплуатации.
Dependency Injection (или DI) — концепция, которая настолько естественно вплелась в повседневную практику программирования, что, кажется, её игнорирование можно смело записать в список смертных грехов наравне с отсутствием контроля версии. Но почему же DI стал столь важным?
DI — это один из ключевых принципов, позволяющих создавать гибкие и сопровождаемые приложения. Философия подхода заключается в том, чтобы избавить код от ненужных деталей, которые связывают логические компоненты приложения слишком плотно. Компоненты перестают быть зависимыми от конкретных реализаций других частей системы — они лишь говорят, что им требуется, а DI предоставляет необходимые зависимости.
Теперь о цели: DI — это вовсе не про навык освоения модной технологии, а про универсальный архитектурный инструмент, понятие которого пересекается в совершенно разных экосистемах. Изучение DI в нескольких языках и средах помогает не просто улучшить понимание самой концепции, но и значительно расширяет взгляд на проектирование систем, приходит понимание, что, несмотря на разницу в синтаксисе, фундаментальные идеи стремятся к одним и тем же архитектурным целям.
Кому будет полезна эта статья? Если вы давно уже подружились с .NET с его IServiceCollection, но всегда хотели разобраться, что из себя представляют Angular Injectors, — добро пожаловать. И наоборот, если вы пишете код в TypeScript, но слово "Transient" у вас вызывает только вопросы, — прошу к прочтению. Мы разберемся, как похожие концепции адаптируются в двух разных мирах и почему их изучение в обеих экосистемах позволит вам лучше проектировать свои приложения.
В современных Angular-приложениях сигналы предоставляют мощный способ управления реактивными потоками данных. Однако по мере роста сложности приложений становится всё более важным поддерживать чистоту функций, которые взаимодействуют с сигналами. Реактивная чистота гарантирует, что функции не создают нежелательных побочных эффектов, регистрируя новых производителей в реактивном графе.
Bootstrap предоставляет базовую структуру, но её нужно адаптировать под ваш дизайн, чтобы избежать хаоса в стилях. Настройка даже простой кнопки требует системного подхода — с чётким пониманием уровней кастомизации и архитектуры проекта. В этой статье пошагово показано, как изменить кнопку Primary с помощью SCSS-переменных и дополнительных стилей, сохраняя чистоту и согласованность дизайн-системы.
Когда вы в последний раз чувствовали себя настоящим экспертом в разработке? Лично я — где-то в тот момент, когда впервые написал программу, которая завершилась без ошибок. Программирование — это как бесконечный ремонт дома, в котором ты уже живёшь. Ещё вчера тебе казалось, что новая крыша будет решением всех проблем. А сегодня оказалось, что появились окна с автоподогревом, и без них дом вообще не дом. И, конечно, все соседи уже поставили такие.
