Angular *

В предыдущей статье («Angular Components with Extracted Immutable State») я показал, почему изменение полей компонентов без каких-либо ограничений - это не всегда хорошо, а также представил библиотеку, которая позволяет упорядочить изменения состояния компонентов.

С тех пор я немного изменил её концепцию и упростил использование. На этот раз я сосредоточусь на простом (на первый взгляд) примере того, как eё можно использовать в сценариях, где обычно потребовался бы rxJS.

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

В конце прошлого года на сайте State of JS 2020 было опубликовано исследование о состоянии экосистемы JavaScript в 2020 году с ретроспективой на предыдущие годы развития. Исследование основывалось на многочисленных опросах, в которых суммарно приняли участие более 23 тысяч человек из 137 стран мира.

В августе прошлого года команда инструментов JavaScript/TypeScript выпустила Angular Language Service для пользователей Visual Studio. Этим мы хотели обратиться ко многим пользователям ASP.NET/ASP.NET Core, которые создают свои клиентские проекты с помощью Angular. Хотя это расширение вызвало много хвалебных отзывов, не для всех пользователей оно было таким удобным. Мы хотим, чтобы вы знали, что мы вас услышали и внесли некоторые изменения. Немного подробностей под катом.

В JavaScript мы часто используем сущности, вроде window, navigator, requestAnimationFrame или location. Некоторые из этих объектов существуют испокон веков, некоторые являются частью вечно растущего набора Web API. Возможно вы встречали класс Location или токен DOCUMENT в Angular. Давайте обсудим, для чего они нужны и чему мы можем у них научиться, чтобы сделать наш код чище и более гибким.

Что нужно для перехода от серверного рендеринга к пользовательскому? Чем хорош Angular 2+ и как на него перейти?  В этой статье попытаемся разобраться в данных вопросах и описать процесс миграции от серверных технологий рендеринга, таких, как JSP, к клиентским технологиям рендеринга представлений с использованием Angular.

«Каждый уважающий себя блогер должен написать статью о RBAC. Каждый уважающий себя читатель должен написать в комментарии, что всё равно ничего не понял». С этой фразы началось мое знакомство с RBAC. И я имел прекрасную возможность узнать, что всё так и есть.

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

Angular Universal — это опенсорсный проект, который расширяет функциональность @angular/platform-server. Он делает возможным Server Side Rendering в Angular. В этой статье мы обсудим проблемы и возможные решения, с которыми мы столкнулись при разработке реального приложения с Angular Universal.

В процессе эволюции нашей библиотеки компонентов Taiga UI мы стали замечать, что некоторые компоненты посложнее имеют @Input просто для того, чтобы прокинуть его значение в @Input другого нашего базового компонента внутри себя. Иногда встречается такая вложенность даже в три слоя.

Мы справились с помощью хитрых директив, которые назвали контроллерами. Они полностью решили проблему вложенности и сократили вес библиотеки.

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

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

Итак, собственно проблема: порой у нас в проекте есть много похожих компонентов, с одинаковой логикой, одинаковыми DI, свойствами итд и возникает мысль: а почему бы не вынести все это дело в базовый компонент (точнее директиву) абстрактным классом, а остальные компоненты уже наследовать? На самом деле мысль хорошая, принцип DRY соблюдается, имеем один источник истины, при изменении той самой общей логики не придется прыгать по всем компонентам итд.

Но есть один нюанс: эти злосчастные конструкторы. Нужно в каждом наследуемом компоненте передавать все DI в конструктор родителя.

Как и многие другие Angular-разработчики, я мирился с одним ограничением. Если мы хотим использовать Observable в шаблоне, мы можем взять знакомый всем async-пайп. Но его нельзя применить к @HostBinding. Давным-давно это было возможно по ошибке, но это быстро исправили. Все потому, что хост байндинг относится к родительскому view и в нем этот пайп может быть не подключен. Это довольно желанная фича. Давайте посмотрим, как мы можем ее реализовать, пока нет официального решения.

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

В институте шахматы забылись: карьера-учеба, вот это все. А потом я увлекся снова. Стал ходить в шахматный клуб на Полянке. Играл с дедами — и постоянно им проигрывал, так как плохо знал теорию. Стал проходить курсы, изучать дебютную подготовку. Начал кого-то обыгрывать. И это дико мотивировало.

Мой коллега Роман недавно объявил о выходе нашей новой библиотеки компонентов под Angular Taiga UI. В инструкциях Getting started сказано, что приложение нужно обернуть в некий tui-root. Давайте разберемся, что он делает, узнаем, как и зачем мы используем порталы и что это вообще такое.

Всем привет! Меня зовут Вова, я фронтендер в Тинькофф. Сейчас перед нашей командой стоит задача редизайна функциональности на пересечении нескольких продуктов. Данная ситуация заставила нас задуматься во-первых о DDD, а во-вторых о гибкости наших решений, применяемых при разработке, и достичь этого нам помогли принципы SOLID, а точнее OCP и Dependency Inversion (не путать с Dependency Injection), о чем и хочется дальше поговорить.

Привет!

Саша Инкин и я регулярно пишем на Хабр статьи по Angular. Почти все они основаны на нашем опыте разработки большой библиотеки компонентов.

Эту библиотеку мы развиваем, перерабатываем и дополняем уже несколько лет, а свои идеи проверяем на нескольких десятках проектов Тинькофф Бизнеса и внутренних систем компании. Мы рады сообщить: выложили нашу библиотеку в открытый доступ!

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

В первой, второй и третьей частях мои коллеги рассказали, как и почему мы распиливали монолит. 

Если коротко, то мы создали решение, которое позволило в рамках одной открытой страницы браузера запускать несколько независимых Angular-приложений, шарить между ними данные, управлять роутингом и аутентификацией. Мы научились бороться с утечками памяти и решать конфликты глобальных стилей приложений. Но одна проблема оставалась открытой — каждое приложение несло в своем банде Angular, RxJS, zone.js и т. д. И в этой статье я расскажу, как мы ее решили.

Привет всем, хочу рассказать как добавить code coverage к angular/react проекту. В сети можно отыскать довольно много вариантов как это делать, и со своего опыта должен заметить что иногда с angular это не так просто. Рассмотрим как добавить code coverage к 11 версии angular (если у вас 7/8 … этот пример может не работать, лучше обновиться).

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

Кейс 1: Переключалка (Toggle)

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