Что такое Storybook и зачем он нужен?

Вопрос

Что такое Storybook и какие проблемы он решает в разработке компонентов?

Короткий ответ

Storybook — это инструмент для разработки, документирования и визуального тестирования UI-компонентов в изоляции от остального приложения: каждый компонент описывается набором "историй" (stories) — состояний с разными пропсами — и открывается в отдельном браузерном окружении без необходимости поднимать весь бэкенд и роутинг приложения.

Подробный ответ

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

Storybook даёт компоненту отдельную песочницу:

• Каждый компонент описывается файлом stories — набором предопределённых состояний/вариантов (пропсы, слоты, edge cases вроде пустого списка или ошибки).
• Открывается отдельным dev-сервером со своим UI-каталогом всех компонентов проекта — это превращается в живой style guide, который не расходится с реальным кодом (в отличие от статичной документации в Figma/Confluence, которая часто устаревает).
• Компонент разрабатывается в изоляции: не нужно поднимать роутинг, стор, авторизацию, реальные API — стори сразу передаёт нужные пропсы/моки.
• Даёт визуальное QA: дизайнер или QA может посмотреть все состояния компонента (включая редкие — ошибка, пустое состояние, длинный текст) в одном месте, не гоняясь за ними по приложению.
• Интегрируется с инструментами визуального регрессионного тестирования (Chromatic, Percy) — на каждый PR автоматически делаются скриншоты всех историй и сравниваются с эталоном, что ловит непреднамеренные визуальные изменения.
• Поддерживает аддоны: a11y-проверки, viewport-эмуляцию (адаптивность), интерактивные controls (менять пропсы прямо в UI), автогенерацию документации из типов/JSDoc.

Storybook особенно ценен в дизайн-системах и UI-библиотеках, где компонент переиспользуется во многих местах и его контракт (пропсы, состояния) важно держать явным и протестированным независимо от конкретных страниц, которые его используют.

Пример

// Button.stories.js
import Button from './Button.vue'

export default {
  title: 'UI/Button',
  component: Button,
  argTypes: {
    variant: { control: 'select', options: ['primary', 'secondary', 'danger'] },
  },
}

export const Primary = {
  args: { variant: 'primary', label: 'Сохранить' },
}

export const Loading = {
  args: { variant: 'primary', label: 'Сохранить', loading: true },
}

export const Disabled = {
  args: { variant: 'primary', label: 'Сохранить', disabled: true },
}

# запуск локального Storybook и сборка статической версии для деплоя
npx storybook dev -p 6006
npx storybook build

Дополнительные вопросы

• Чем визуальное регрессионное тестирование через Chromatic дополняет обычные unit/компонентные тесты?
• Как Storybook помогает переиспользовать компоненты между разными командами в монорепозитории?
• Какие есть недостатки/накладные расходы у поддержки Storybook в проекте?