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

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

Статья написана по опыту разработки фронтовых библиотек и с советами вокруг JS-экосистемы, но часть идей будет полезна и для других направлений.

Я всегда старался выносить в опенсорс все, что может быть полезно людям вне моей компании. Помимо стремления не только брать от сообщества, но и отдавать, это приносит ряд бенефитов для самой компании.

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

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

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

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

В этой статье я хотел бы показать несколько типовых кейсов для ng-content при разработке многократно используемых компонентов. А еще — рассказать о преимуществах, которые они могут нам дать.

После длительного перерыва Angular Moscow Meetup наконец вернулся, да еще и в новом гибридном формате! 28 апреля мы собрали в офисе почти 100 человек и еще столько же людей следили за происходящим в прямой трансляции. Мероприятие длилось больше двух часов, мы послушали два доклада и круглый стол с экспертами, среди которых аж три GDE по Angular.

Зрители тоже были полноценными участниками митапа: мы зачитывали их вопросы спикерам, отвечали на комментарии и провели розыгрыш подарков. Кажется, наш эксперимент получился удачным! А в этой статье я расскажу, какие доклады у нас были, дам ссылки на них и фотографии с самого ивента.

CDK — базовый пакет библиотеки компонентов Taiga UI. Он не имеет никакой привязки к визуальной составляющей библиотеки, а скорее служит набором полезных инструментов для упрощения создания Angular-приложений.

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

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

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

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

Привет!

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

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

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

Я разрабатываю несколько Angular-библиотек, поэтому люблю делать простые и легко переиспользуемые решения для разработчиков. Недавно один из подписчиков в Твиттере спросил меня, как сделать компонент, который выводил бы его данные в виде иерархического дерева — tree view. 

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

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

Мы используем TypeScript, потому что это делает разработку безопаснее и быстрее.

Но, на мой взгляд, TypeScript из коробки содержит слишком много послаблений. Они помогают сэкономить немного времени JavaScript-разработчикам при переходе на TS, но съедают очень много времени в долгосрочной перспективе.

Я собрал ряд настроек и принципов для более строгого использования TypeScript. К ним нужно привыкнуть один раз — и они сэкономят массу времени в будущем.

Вот вы сделали что-то новое и крутое, приходит мысль — выложить в опенсорс и опубликовать в npm.

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

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

На самом деле всё это может занять у вас меньше часа. Без знаний DevOps и совершенно бесплатно.