Angular *

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

Если пару лет назад шли вопросы о том, какой фреймворк выбрать, то сейчас все задаются вопросом: “Как оттуда выбраться”.  Давайте разберемся с тем как это произошло, и что стоит делать, чтобы не попасть в жернова фронтенд фреймворка.

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

Сверстать собственный индикатор загрузки — одна из самых простых задач, с которой может столкнуться веб-разработчик. Для получения рабочего решения пригодятся базовые знания HTML и CSS, а JS будет нужен лишь для управления процентом выполненной задачи.

Однако эта простота обманчива. Интернет наполнен множеством решений, в которых индикатор загрузки анатомически состоит из кучи вложенных друг в друга div-контейнеров, приправленных щепоткой CSS. Не нужно так! В мире грустит один котенок, когда вы игнорируете семантику верстки и забываете про доступность (a11y).

В этой статье я расскажу, как мы в проекте Taiga UI подошли к написанию собственных Angular-компонентов ProgressBar и ProgressCircle.

Как ранее было отмечено в предыдущем посте концепция рабочего каталога Angular закономерно эволюционировала до поддержки полноценных workspace - проверенный и понятный способ управления сложностью при масштабировании процесса разработки (Visual Studio Solution , SBT Multi-Project builds , Gradle Multi-Project Builds , RushJS , Lerna и др. ).

Для каждого, кто практически сталкивался с Angular проектом средней руки, не будет секретом, что angular.json может легко содержать тысячи строк убористого JSON, с невероятным, даже нарочито избыточным количеством дублирующейся информации. Проблема отнюдь не новая и дающая о себе знать при eмасштабировании процесса разработки сложного продукта. Компактность и человеко-читаемость формата явно не была в приоритетах, и как-бы намекает, что человеку тут и нечего делать. Из этого и будем исходить.

Добрый день.

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

Если вы ведете разработку на Angular, уверен не раз встречались с ситуацией, когда применение стилей к селектору не давали ни какого эффекта. Часто это решают выносом стилей в глобальные, применение селектора ::ng-deep или что еще хуже полным отключением инкапсуляции без понимания механизма его работы. В то время как Angular дает мощный механизм по работе с разделением и инкапсуляцией стилей.

Собственно об этом механизме и сценариях его использования поговорим. Но сначала взглянем на классический способ работы со стилями.

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

Когда я интегрировал свое Angular-караоке с YouTube, мне попался официальный YouTube-компонент из Angular Material. В README прилагалась инструкция для подключения. Почти каждая строка в ней примере сомнительна. Давайте разберемся, как сделать лучше и применить имеющиеся инструменты для ленивой подгрузки библиотеки.

Мы привыкли слышать, что Angular это фреймворк, который решает массу задач из коробки: свой cli, встроенная сборка приложений, автоматическая миграция на новые версии с помощью schematic, работа с http, DI, реактивные формы, работа с состоянием - все это удобные инструменты для разработчика. Обычно я сравниваю его с коробкой автомат, сел и сосредоточенно поехал по дороге, без отвлечений на коробку передач.

Но в мире веба мы всегда должны думать о пользователях. И один из разделов, который заботиться о них называется веб доступность (Accessibility, A11y в англоязычной среде). И тут Angular позаботился о нас и дал мощнейших инструмент из коробки под названием CDK a11y. Предлагаю ознакомится с концепцией доступности и изучить применение этого инструмента в Angular.

Любой более менее опытный фронтендер, работающий с Angular, умеет пользоваться роутером. Тут путь. Здесь компонент. Не забудь положить router-outlet в темплейт в нужном месте и вуаля.

И это покрывает 95% всех кейсов любого приложения. Остальное можно подпереть костылями. Одни из них хрупки, как китайский фарфор. Другие вполне себе претендуют на решение, достойное самого ядра приложения.

Давайте представим не такой уж редкий случай: онлайн магазин, выбрали покупки, посмотрели корзину, приступаем к оформлению.

И тут дизайнер поменял наркотики: все формы оформления заказа отрисованы в диалоговом окне. На вопрос “Зачем?” получаем отсутствующий взгляд и глупое хихиканье. Заказчик не добавляет позитива и соглашается во всем с дизайнером.

По мотивам вопросов из предыдущей статьи мы решили написать вторую часть и рассказать, что удалось сделать еще.

На повестке дня:

• Роутинг хостового приложения (React/Vue Routing внутри Angular)

• Полноценные адаптеры для работы удаленных плагинов

• Использование сервисных модулей в рантайме

В этом руководстве я объясню необходимые шаги для интеграции веб-компонентов в Angular.

До HolyJS осталось меньше месяца — пора поведать Хабру, какие именно доклады там будут. Под катом их описания, а тут отметим пару вещей:

— В этот раз шире обычного раскрыта тема производительности. Когда React.memo не ускорит, а замедлит? Почему Solid.JS такой быстрый? Что нужно знать JS-разработчику в современном многоядерном мире?

— Помимо докладов, в программе есть несколько воркшопов, так что будет не только теория со слайдами, но и практическая деятельность.

Описания мы разделили по тематическим блокам, но это деление не строгое, некоторые доклады можно причислить к разным блокам сразу.

Недавно Бхарат Рави опубликовал статью о директиве самосохраняющегося select-элемента на InDepth. Это интересная концепция изолирования логики в директиве, что в целом идея хорошая.

Однако в этом случае у меня есть сомнения, которые я хочу подсветить. Я предлагаю свою версию компонента, исправляющую эти моменты. Начнем с того, что назовем проблемы текущего решения.

При разработке бизнес-логики приложений нужно продумать действия с множествами – с пересечением, разницей массивов или двойной разницей. Недостатки в этом алгоритме могут привести к рискам. Например, если вам нужно в реальном времени обработать объем данных, превышающий определенную границу, система может «тормозить» – до минуты и даже больше. Такие ситуации требуют лишнего расхода ресурсов, отталкивают пользователей и вызывают другие проблемы.

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

Чтобы использовать Angular CLI на полную, разработчики должны знать, что такое схематики. Например, команды ng add, ng update и ng generate используют схематики для добавления, обновления и настройки библиотек и кодогенерации в приложениях. Во время выполнения схематика вы получаете доступ к файловой системе и можете мутировать исходный код приложения так, как вам нужно. «Но, чтобы мутировать код, нужно работать с AST, а это сложно», — возможно, скажете вы, и будете правы!

В этой статье расскажу, как мы пытаемся упростить работу с AST и сделать написание схематиков обыденным. А еще покажу, что так же просто можно работать с AST не только в Angular-проектах, а практически в любом проекте на JavaScript/TypeScript.

В Angular есть два режима change detection: Default и OnPush. В этой статье мы разберем, как можно спокойно использовать OnPush всегда без лишнего труда и почему стоит начать это делать.

Разработка на canvas с контекстом 2D обычно не предполагает никаких сложностей. Для начала необходимо изучить пару десятков встроенных методов WEB API CanvasRenderingContext2D, прочитать рекомендации по оптимизации, вспомнить школьный курс геометрии. И на этих базовых вещах можно уже строить неплохие приложения на canvas.

Как один из вариантов начала разработки на canvas: из примитивов фигур строят элементы, затем их объединяют в функцию, эти функции складывают в готовый элемент, объединяют их в слой, ну и в конце уже отдают в функцию рендера. Все еще звучит довольно неплохо и с этим можно даже жить, если использовать чистые функции, и придерживаться везде этого подхода. Но не всегда этого удается, всегда есть соблазн выхватить что-либо из контекста. Для примера приведу код из source-map-vizualization замечательный инструмент, сделанный на canvas. Только чтобы понять весь код и привнести какие либо исправления, я думаю придется посидеть не один час.

Вам когда-нибудь хотелось отобразить состояние загрузки, пока ngIf ждет ответа от async-пайпа? Или, может, вы мечтали передать в ngFor шаблон для пустого массива? Возможно, вы бросили это, потому что вам не хотелось реализовывать базовую логику этих директив самому. На самом деле в этом нет нужды! Один и тот же селектор может подцепить несколько директив, что позволяет расширить функциональность встроенных директив дополнительной логикой.

Несколько месяцев назад я написал статью «Как мы делаем базовые компоненты в Taiga UI более гибкими: концепция контроллеров компонента в Angular». Я рассказал о том, как мы добавляем гибкости и избавляемся от дублирования кода с помощью DI. Пришло время продолжить статью.

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