Зачем нужна выделенная Frontend Core команда и как мы внедряли дизайн систему

[kranid]

Прорабатываете ли вы Accessibility своих компонентов? Следуете ли Web Content accessibility guideline www.w3.org/TR/WCAG21? Такой вопрос возникает, т.к. разработка доступных компонентов — это наиболее безболезненный и эффективный способ внедрения accessibility во всем сервисе.

[Royroev]

Спасибо за вопрос! Забыл про это указать в статье. Да, конечно прорабатываем, стараемся поддерживать скрин ридеры, учитываем все комментарии lighthouse по доступности контента для людей с ограниченными возможностями. W3C соблюдаем, но пока что все проверки у нас не автоматизированы, планируем добавить в ci/cd quality gate, используя библиотеку www.npmjs.com/package/node-w3c-validator

[alex_mayak]

Спасибо за статью. Интересно и полезно

[art_nau_0o]

А темная тема будет? Ночью очень не хватает.

[Royroev]

она внедрена в нашу библиотеку уже на 40%, когда сделаем на 100% — будем внедряться в продукты.

[Wint95r]

Ростислав, спасибо за статью!

Очень интересно прочитать про опыт работы с библиотекой компонентов. Подскажите, пожалуйста, при обновлении версий библиотеки элементов для конечного потребителя, вы используете тесты — например snapshot / visual regression? Или кодмоды для обновления использования компонентов?

[Royroev]

Спасибо за вопрос! У нас есть скриншот тестирование, на основе разработанной у нас в компании фреймворка, мы запускаем тесты как и в самой библиотеке компонентов, так и на продуктов после внедрения. Мы думали о кодмодах (или скрипты миграции) для легкого перехода на новые версии компонентов, но рассчитав трудозатраты на создание такого подхода мы поняли, что это будет очень не дешево. Поэтому мы описываем braking changes в readme компонента и надеемся на автотесты

[webistomin]

Спасибо за статью. Как раз занимаюсь нечто похожим :)

[jeremy13]

1. Ваша команда работает по спринтам(скраму)?
2. Зависят ли продуктовые команды от вас в плане выпуска продуктовых фич с вашими компонентами? Или команды используют только, то что есть? Может быть нужны срочные баг фиксы?
3. Как определяете какие компоненты идут в дизайн-систему? Пишут ли команды свои велосипеды? Как с этим боритесь?
4. Сколько у вас команд(проектов) использующих дизайн-систему?

[Royroev]

Спасибо за очень важные вопросы.
1.Да. Мы выбрали недельные спринты что бы декомпозировать задачи по созданию компонентов на небольшие.
2. Иногда зависят, мы обозначаем ddl для таких кейсов. Если есть альтернативы в нашей библиотеке компонентов — они используют то что есть. Криты и блокеры по компонентам у нас в 0 приоритете.
3. Наша команда собирает потребности и области применения компонента в компании. Если потребность есть у нескольких команд или только у одной, но есть гипотеза что остальным тоже понадобится — такой компонент попадает в дизайн систему. Команды пишут свои велосипеды если этот велосипед слишком уникален.
4. Примерно 15 команд в нашей компании используют дизайн систему.

[wnetking]

Спасибо за статью.

Скажите пожалуйста, на чем у вас сделана витрина компонентов.

[Royroev]

Спасибо! У нас самописная витрина, было так решено, когда еще не было Storybook на TS, теперь появилась, может быть и попробуем.

[pepelsbey]

Так Front Core или Web Core? :) Вы определитесь, в статье то одно, то другое.

[Royroev]

Все таки Web Core, т.к. мы решаем намного больше задач, чем просто пилить фронт) Спасибо за замечание, исправили!

[DHi]

Продуктовые команды контрибьютят в core, если им очень нужно ?

[Royroev]

В очень редких случаях