Комментарии 16
Было бы интересно увидеть открытый вариант (open source) Вашей библиотеки. Тогда было бы больше, что обсуждать.
Суть не в библиотеке, а в подходе ;)
Мы рассматриваем возможность опенсорса библиотеки.
А эта статья задумывалась больше как описание подхода — так можно работать и над библиотекой UI-компонентов, и над библиотекой других сущностей, которые шарятся между проектами.
Кстати, насчет кода… мои коллеги делились некоторыми наработками, сделанными во время работы над библиотекой. Возможно вам будет интересно:
А эта статья задумывалась больше как описание подхода — так можно работать и над библиотекой UI-компонентов, и над библиотекой других сущностей, которые шарятся между проектами.
Кстати, насчет кода… мои коллеги делились некоторыми наработками, сделанными во время работы над библиотекой. Возможно вам будет интересно:
- ControlValueAccessor и contenteditable в Angular (код описанного пакета лежит на GitHub)
- Оптимизация обработки событий в Angular
По вашему опыту, насколько реально автоматизировать и поддерживать актуальным список проектов, в которых используется тот или иной компонент?
Если проекты-пользователи — это ваши внутренние наработки, к коду которых есть доступ, то это совершенно реально. Мы пробовали разные подходы — на основе импортов модулей (у нас Angular, соответственно речь про ангуляровские модули) и на основе анализа шаблонов, у каждого есть свои плюсы и минусы.
Думаю, об этом можно написать отдельную статью.
Думаю, об этом можно написать отдельную статью.
Тут на неделе Денис Колесников из Авито рассказывал, какой у них Data Science навернут для этого. Рекомендую. Интересующая тематика начинается примерно с 2:14:00.
http://longestjs.org/#talk-01
Я так понимаю, у вас только Angular компоненты. А что делаете с мажорными обновлениями фреймворка? Поддерживаете несколько версий библиотеки или обновляетесь все разом?
> Я так понимаю, у вас только Angular компоненты
Если говорить о библиотеке компонентов, описанной в статье, то да, это именно Angular. Но в целом в компании есть и реализация дизайн-системы для проектов на React.
> А что делаете с мажорными обновлениями фреймворка? Поддерживаете несколько версий библиотеки или обновляетесь все разом?
Библиотеки на Angular 6/7 совместимы с приложениями на Angular 6/7/8 (более старых версий фреймворка у нас нет). Мы не поднимаем версию Angular немедленно после выхода мажорной версии фреймворка, т.к. это не требуется для приложений-пользователей на свежем Angular, но помешает приложениям на более старом.
Со временем, поднимая версию Angular в библиотеке, будем увеличивать мажорную версию самой библиотеки.
Что касается обновления всех приложений разом, мы стараемся не запускать и обновляться быстро, но когда приложений несколько десятков, и работают над ними разные команды, то обновить всё одновременно затруднительно, даем командам время.
Если говорить о библиотеке компонентов, описанной в статье, то да, это именно Angular. Но в целом в компании есть и реализация дизайн-системы для проектов на React.
> А что делаете с мажорными обновлениями фреймворка? Поддерживаете несколько версий библиотеки или обновляетесь все разом?
Библиотеки на Angular 6/7 совместимы с приложениями на Angular 6/7/8 (более старых версий фреймворка у нас нет). Мы не поднимаем версию Angular немедленно после выхода мажорной версии фреймворка, т.к. это не требуется для приложений-пользователей на свежем Angular, но помешает приложениям на более старом.
Со временем, поднимая версию Angular в библиотеке, будем увеличивать мажорную версию самой библиотеки.
Что касается обновления всех приложений разом, мы стараемся не запускать и обновляться быстро, но когда приложений несколько десятков, и работают над ними разные команды, то обновить всё одновременно затруднительно, даем командам время.
Не думали о реализации общих компонент на одном из легковесных фреймворков типа $mol или Svelte, чтобы использовать их в приложениях на любом фреймворке, а не реализовывать их отдельно для Ангуляра, отдельно для Реакта, отдельно для <что там будет в моде через год>?
Да, мы действительно рассматривали разные варианты, чтобы не делать две реализации. Но в итоге остановились на подходе с отдельными версиями.
Если бы кит внутри был основан на другом легковесном фреймворке или даже написан на чистом JS, развивать и поддерживать его было бы сложнее. Да и легковесный фреймворк так же может выйти из моды через год.
- Так можем в полную меру использовать возможности фреймворка.
- Разрабатывать проще, потому что есть экспертиза в Angular. И наоборот, работая над китом, разработчики кита еще сильнее прокачиваются Angular и дают ценные советы коллегам из других команд.
- Разработчики из команд-пользователей могут присылать пулл-реквесты. У нас есть выделенная команда для поддержки кита, но мы поддерживаем и «внутренний open source». Для других ребят это возможность быстрее занести свои изменения и попробовать новый вид задач, не похожий на то, что делают в своем проекте.
Если бы кит внутри был основан на другом легковесном фреймворке или даже написан на чистом JS, развивать и поддерживать его было бы сложнее. Да и легковесный фреймворк так же может выйти из моды через год.
Расскажите подробнее, пожалуйста, о том как вы поддерживаете свою документацию по компонентам. Вручную или автоматически? Есть ли какой-то свой язык разметки или скриптов? Как собираете статистику использования компонентов в проектах?
Перед нашей командой сейчас стоит похожая проблема: как донести до потребителей (разработчиков из других команд) подробную информацию обо всех имеющихся в библиотеке компонентах, их свойствах, примерах использования, и так далее.
Перед нашей командой сейчас стоит похожая проблема: как донести до потребителей (разработчиков из других команд) подробную информацию обо всех имеющихся в библиотеке компонентах, их свойствах, примерах использования, и так далее.
Привет. По статистике Юля ответила ниже, просто промахнулась, похоже :) По поводу документации — в статье есть гифки с нашей интерактивной витриной. Мы вынесли её в отдельный пакет и продолжаем увеличивать её автоматизацию, пишем схематики для генерации и тому подобное. Но в корне своём она всё-таки собирается руками. Она состоит обычно из 3 вкладок:
У разработчиков такая витрина пользуется большой популярностью. В ней есть разделы и поиск, кроме того «натыканные» входные данные со страницы документации сохраняются в URL так что можно передавать друг другу ссылки сразу на готовое состояние компонентов. Кроме разработчиков, витрина полезна технологам и дизайнерам проектов, чтобы видеть что уже можно переиспользовать и какие возможности уже есть у тех или иных компонентов.
- Примеры, которые уж точно не автоматизировать. Там мы показываем несколько особенных примеров использования, покрывающие основные нужды пользователей. Часто, разработчик копирует оттуда код, как отправную точку, близкую к тому, что ему нужно.
- Интерактивная документация. Тут лежит компонент и показаны все его инпуты, значения которых можно покрутить и сразу увидеть эффект.
- Инструкция по подключению. Тут для большинства страниц примерно одно и то же, подключаем модуль, вставляем в шаблон.
У разработчиков такая витрина пользуется большой популярностью. В ней есть разделы и поиск, кроме того «натыканные» входные данные со страницы документации сохраняются в URL так что можно передавать друг другу ссылки сразу на готовое состояние компонентов. Кроме разработчиков, витрина полезна технологам и дизайнерам проектов, чтобы видеть что уже можно переиспользовать и какие возможности уже есть у тех или иных компонентов.
Спасибо за ответ.
То есть без ручной работы всё же не обойтись.
Мы когда-то использовали ExtJS и у нас было своё подобие Sencha Kitchen Sink как раз для этих целей, но её приходилось пополнять и поддерживать вручную одному человеку.
Теперь пишем на Lightning Web Components и возникла необходимость собрать нечто подобное Lightning Strike от Appiphony, однако на этот раз хочется заавтоматизировать всё это донельзя. Поэтому интересно знать как это сделано у других, чтобы не наступать на те же грабли.
То есть без ручной работы всё же не обойтись.
Мы когда-то использовали ExtJS и у нас было своё подобие Sencha Kitchen Sink как раз для этих целей, но её приходилось пополнять и поддерживать вручную одному человеку.
Теперь пишем на Lightning Web Components и возникла необходимость собрать нечто подобное Lightning Strike от Appiphony, однако на этот раз хочется заавтоматизировать всё это донельзя. Поэтому интересно знать как это сделано у других, чтобы не наступать на те же грабли.
Я отвечу на вопрос о статистике использования компонентов, а мой коллега завтра подробнее расскажет о сборке документации, как раз он ее недавно доработал.
Статистику использования собираем полностью автоматически с помощью самописного решения, которое анализирует код шаблонов продуктовых проектов.
В первой версии получали только сам факт использования компонента. Сейчас дорабатываем новую версию, которая дополнительно сохраняет и какие параметры компонентов (inputs, outputs) используются, какие значения в них обычно передаются, умеет выявлять некоторые неправильные использования параметров (например,
Подробности технической реализации, кажется, тянут на еще одну статью.
Дополнительно из package.json и package-lock.json берем информацию о версии библиотеки, TypeScript и Angular. Это вообще реализуется элементарно, а планировать обновления и следить за состоянием фронтенда в целом помогает очень и очень сильно.
Статистику использования собираем полностью автоматически с помощью самописного решения, которое анализирует код шаблонов продуктовых проектов.
В первой версии получали только сам факт использования компонента. Сейчас дорабатываем новую версию, которая дополнительно сохраняет и какие параметры компонентов (inputs, outputs) используются, какие значения в них обычно передаются, умеет выявлять некоторые неправильные использования параметров (например,
someInput="true" вместо [someInput]="true").Подробности технической реализации, кажется, тянут на еще одну статью.
Дополнительно из package.json и package-lock.json берем информацию о версии библиотеки, TypeScript и Angular. Это вообще реализуется элементарно, а планировать обновления и следить за состоянием фронтенда в целом помогает очень и очень сильно.
Вы главное скажите: вы до сих пор разделяете поля в форме не отступами в стилях, а с помощью <br>, как на одной из первых картинок поста?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как организовать работу над библиотекой общих компонентов