дневники разработчиков

Внедряем Storybook

Библиотека компонентов как точка синхронизации команды
С ростом интерфейсной части проекта перед командой встал вопрос: как упростить коммуникацию между разработчиками и дизайнерами, ускорить отладку компонентов и сделать процесс разработки прозрачнее? Ответом стало внедрение Storybook – инструмента для разработки, визуализации и документирования компонентов в изоляции.
С увеличением количества UI-компонентов мы столкнулись с типичными «болями»:

  • Разработчикам приходилось запускать всё приложение, чтобы проверить отдельный компонент.
  • Дизайнеру было сложно понять, какие элементы уже реализованы.
  • Коммуникация внутри команды становилась всё менее эффективной, особенно при появлении новых участников.
  • Не было живой документации, которая бы показывала, как именно работают компоненты в разных состояниях.
Решением всех этих проблем стало (ладно, пока не стало, мы только на старте внедрения инструмента) внедрение Storybook, который оказался не просто удобной «вьюшкой» для компонентов, а полноценным инструментом управления фронтенд-инфраструктурой.

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

  1. Развернуть через GitLab Pages – быстро, без внешних зависимостей.
  2. Использовать сторонний сервис, рекомендуемый сторибуком, например Chromatic – сервис с CI/CD-интеграцией. Но этот вариант потребует больше настройки и ставит инфраструктуру от самого стороннего сервиса.

Решили пойти по пути меньшего сопротивления: задействовать GitLab Pages в нашем облаке. Это позволит быстрее открыть доступ к инструменту всей команде и начать наполнение библиотеки.
  • Юлия Ш.
    фронтенд-разработчик StarsMap
    Наша главная цель сейчас – это синхронизация девелоперов и дизайнера, доступ к библиотеке для любого участника команды. Сторибук будет прямо из Figma на страницу компонента дизайн подтягивать, к примеру.

Storybook: зачем нужен и что даёт проекту

1. Изолированная разработка

  • Компоненты можно поднимать и тестировать без всего приложения.
  • Сокращает время на отладку и упрощает проверку разных состояний.
  • Разработчику не нужно проходить длинные сценарии в приложении, чтобы "добраться" до нужного элемента.

2. Живая документация компонентов

  • Каждый компонент описывается через "истории" с разными вариантами использования.
  • Получается каталог, где видны все доступные элементы UI.
  • Это снижает количество дублирования и упрощает поиск готовых решений.

3. Визуальное и функциональное тестирование

  • Поддержка скриншотных тестов (визуальное сравнение изменений).
  • Проверка accessibility на ранних этапах.
  • Лёгкая интеграция с CI/CD для контроля качества.
  • Меньше багов уходит в продакшн, меньше ручной проверки.

4. Коммуникация внутри команды

  • Дизайнеры видят, что уже реализовано и как работает.
  • QA может тестировать компоненты отдельно, без сложных сценариев.
  • Разработчики быстрее понимают доступный набор элементов и используют их повторно.

5. Масштабируемость

  • При большом количестве компонентов Storybook становится полноценной библиотекой.
  • Это ускоряет разработку новых фич и снижает технический долг.
  • Новым участникам команды проще понять структуру проекта и начать работу.
  • Сергей С.
    ведущий веб-разработчик StarsMap
    Добавлю пример. Возьмем условного фронта Игнатия, который что-то поменял. После этого в проекте иначе стали показываться компоненты, например съехала верстка у кнопки. Storybook перед каждым коммитом делает скрины изменившейся верстки компонентов, поэтому к Игнатию может прийти злой техлид и сказать "айяйяй", так как скриншот покажет когда и где в компоненте произошли изменения, и почему верстка поплыла.

Почему для нас это важно

Storybook-сервер нужен, чтобы команда могла смотреть какие компоненты и их вариации у нас существуют в удобном интерфейсе. Сейчас в StarsMap за это отвечает components-library. Но Storybook предпочтительнее с точки зрения удобства и скорости разработки, вариативности и группировки компонентов. Плюс разработчики получают понятный интерфейс параметров и структур данных. Из минусов: теперь придется использовать отдельный сервер для деплоя.

В долгосрочной перспективе мы видим в этом инструменте следующие преимущества:

1. Создание и поддержка дизайн-системы – Storybook станет основой для единого визуального языка и компонентов, используемых в разных продуктах.

2. Ускоренный онбординг – новые разработчики могут изучить проект через готовые компоненты и их документацию, а значит быстрее включатся в эффективную работу.

3. Снижение технического долга – благодаря описанию API и состояний компоненты будет легче поддерживать.

4. Прозрачность разработки – все элементы доступны в одном месте, что облегчает планирование и контроль качества. Другими словами, разработчики не будут больше бегать к дизайнерам с вопросом, откуда брать актуальный компонент, а дизайнеры избавятся от функции "надзорного органа", следящего, чтобы на проде все было по макетному феншую.

Из минусов

На самом деле минусов видим не так уж много. Пока, по крайней мере.

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

Скорее всего, придется дополнительно прикрутить BackstopJS для регрессивного тестирования, эта фича скорее всего не будет работать из коробки.

И, размеется, требуется время на настройку и написание историй. Пока еще можем позволить себе заняться этим, лучше это сделать "на вырост". В активной фазе масштабирования и расширения функционала на технические описания времени может и не быть.

Другие новости