Всем привет. Сегодня я расскажу, как мой пулл-реквест замерджили в 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)
Часто в исходниках приходится видеть примерно такой код:
Если вы используете Angular и библиотеку RxJS, здесь вы узнаете все способы, которые вам могут понадобиться, чтобы подписываться на уведомления от объектов Observable и отписываться от них!
Мы используем RxJS во всех приложениях Angular, которые пишем. RxJS оказывает значительное влияние на поток данных в наших приложениях, их производительность и многое другое.
Чтобы избежать утечек памяти, важно вовремя отписываться от уведомлений, выпускаемых объектами Observable. В этой статье описано большинство доступных способов, с помощью которых в компонентах Angular можно отписываться от уведомлений, выпускаемых объектами Observable.
Начнем с создания демонстрационного сервиса (DummyService), которой поможет нам отслеживать устанавливаемые подписки.
Что вы знаете о Schedulers в RxJS? Они скрывают от разработчиков работу с контекстом выполнения Observable. Как те эльфы-домовики из Гарри Поттера, которые выполняют всю черную работу в Хогвартсе, а о них никто даже и не слышал. Давайте исправим это и узнаем о них чуть больше.
Когда я впервые услышал про compliant-механизмы, был весьма впечатлен. Хоть они и окружают нас в повседневности — в виде застежек рюкзака, кнопок мыши или колпачков от шампуней, — мы редко задумываемся о концепции таких устройств.
Если говорить кратко, в compliant-механизме для обеспечения его технических характеристик используют деформацию. В то время как в традиционной технике (rigid body) гибкость зачастую является негативным качеством материала, сompliant-механизмы используют ее для передачи силы и движения в нужном направлении, вместо соединений из нескольких подвижных деталей.
Я разрабатываю несколько Angular-библиотек, поэтому люблю делать простые и легко переиспользуемые решения для разработчиков. Недавно один из подписчиков в Твиттере спросил меня, как сделать компонент, который выводил бы его данные в виде иерархического дерева — tree view.
Я люблю подобные задачи, потому что они дают возможность покрыть много различных юзкейсов с минимальным количеством логики внутри. В этой статье опишу, как я размышляю, когда решаю подобные задачи.
Дисклеймер: эта статья-туториал рассчитана на аудиторию изучающих Angular. Если вы понимаете, как сделать рекурсивный тип, рекурсивный компонент и преобразовать в нем данные, переданные функцией-обработчиком, можете ее пропустить.
