Всем привет! Если вы считаете Storybook лишним инструментом, эта статья для вас. Раньше я и сам мог присоединиться к такому мнению, но попробовал Storybook в деле, когда участвовал в разработке сервиса рассрочки для одного из крупнейших маркетплейсов. Разработкой этого проекта занимались две команды, состоящие из 15 человек.

Меня зовут Александр, я frontend-разработчик в Simbirsoft. Хочу поделиться, как этот инструмент может сократить время на разработку и тестирование, улучшить качество конечного продукта, а также сэкономить бюджет на больших проектах.

Советую к прочтению фронтенд-разработчикам и тимлидам, которые хотят упростить процесс тестирования и отладки компонентов интерфейса веб-приложений. Также материал может помочь менеджерам проектов и владельцам бизнеса в поиске новых подходов для ускорения и оптимизации процесса разработки. И даже если вы новичок во frontend-разработке и хотите узнать о новых инструментах и технологиях в этой области — welcome.

Мы рассмотрим такие возможности, как создание документации, тестирование, тестирование доступности, работу с моками, аддоны для имитации API и контекста. Я поделюсь, какие проектные задачи мне удалось решить, и чем может быть полезен Storybook для вас.

Для начала развеем одно из наиболее распространенных заблуждений среди разработчиков, что фронтенд — это просто. С появлением адаптивного дизайна количество пользовательских интерфейсов значительно возросло — каждый с уникальными ограничениями. С течением времени появились новые требования к интерфейсам устройств и браузеров, к доступности и производительности. Мы начали использовать JavaScript-фреймворки, добавлять различные типы рендеринга наших приложений (CSR, SSR, SSG и ISR) и разбивать монолит на микрофронтенды. В конечном итоге всё это усложнило фронтенд и создало необходимость в новых подходах к разработке и тестированию приложений.

Результаты исследования от 2020 года показали, что 77% разработчиков считают нынешнюю разработку более сложной, чем 10 лет назад. Несмотря на достижения в области инструментов JavaScript, специалисты продолжают сталкиваться с более сложными задачами. Компонентный подход, используемый в React, Vue и Angular, помогает разбить сложные пользовательские интерфейсы на простые компоненты, но этого не всегда достаточно. По мере роста приложения увеличивается количество компонентов, в серьезных проектах их может быть сотни, что дает тысячи вариаций. Еще больше усложняют ситуацию интерфейсы, которые трудно отлаживать, потому что они запутаны в бизнес-логике, интерактивных состояниях и контексте приложения.

И здесь на помощь приходит Storybook.

Что такое Storybook

Storybook — это инструмент JavaScript для организации пользовательских интерфейсов, который делает процессы разработки компонентов, тестирования и создания документации более эффективными и простыми. Он поддерживает множество фреймворков и библиотек для веб-приложений, в том числе React, Vue и Angular.

Storybook пропагандирует подход Component-Driven Development (CDD), согласно которому каждая часть пользовательского интерфейса — это компонент. Это основные строительные блоки приложения. Каждый из них разрабатывается, тестируется и документируется отдельно от других, что упрощает процесс разработки и поддержки приложения в целом.

Компонент — это независимый фрагмент интерфейса приложения. Например, кнопка, инпут, бейдж и так далее. Если мы понимаем принципы CDD и умеем применять этот подход в разработке, то можем использовать компоненты в качестве основы для создания приложений. Они должны быть максимально независимы друг от друга и разрабатываться с возможностью переиспользования в других частях приложения. 

Можно подходить к созданию компонентов по-разному: начинать с меньших и постепенно объединять их в более крупные, и наоборот. Можно создавать их как в рамках самого приложения, так и в отдельном проекте — в виде библиотеки компонентов.

Благодаря мощной функциональности Storybook вы можете просматривать ваш интерфейс так, как это делают пользователи. Он предоставляет возможность запускать автоматические тесты, анализировать различные состояния интерфейса, работать с моковыми данными, создавать документацию и даже проводить ревью кода. Все эти задачи выполняются в рамках так называемой Story, что позволяет эффективно использовать Storybook для разработки.

Что такое Story?

Это основная единица конструкции Storybook, которая позволяет продемонстрировать различные состояния компонента для проверки его внешнего вида и поведения. Каждый компонент может иметь несколько историй, и каждую можно рассматривать как отдельный тест-кейс для проверки функциональности компонента.

Вы пишете истории для определенных состояний компонентов пользовательского интерфейса, а затем используете их для демонстрации внешнего вида во время разработки, тестирования и документирования.

// Button.stories.js|jsx

import React from 'react';

import { Button } from './Button';

export default {
  title: 'Button',
  component: Button,
};

//???? Мы создаем шаблон того, как аргументы соотносятся с отображением (рендерингом) в Storybook.
const Template = (args) => <Button {...args} />;

//???? Затем каждая история повторно использует этот шаблон.
export const Primary = Template.bind({});
Primary.args = {
   primary: true,
   label: 'Button',
};

С помощью панели управления Storybook вы можете редактировать каждый из аргументов функции истории в реальном времени. Это позволяет вашей команде динамически изменять компоненты в Storybook для тестирования и проверки различных крайних случаев.

Возможности Storybook

Создание документации

Storybook предоставляет возможность создавать документацию вместе с компонентами, что делает процесс более удобным. С его помощью можно генерировать автоматическую документацию на основе комментариев к коду, а также создавать отдельные страницы с примерами использования и описанием свойств компонентов. Это позволяет сохранить актуальную и подробную документацию, которая будет полезна не только для разработчиков, но и для дизайнеров, тестировщиков и пользователей. В качестве удачного референса можно привести пример Storybook Wix.

Тестирование

Еще одно оправданное применение Storybook. UI-тесты выявляют визуальные изменения интерфейсов и проверяют историю на пользовательское взаимодействие.

Рассмотрим на примере Chromatic. Сервис делает снимок каждой истории в среде облачного браузера. Всякий раз, когда вы пушите код, Chromatic создает новый набор снэпшотов и сравнивает их с существующими снимками из предыдущих сборок. Список изменений отображается на странице сборки в веб-приложении. Сборка будет помечена как «непроверенная», а изменения будут перечислены в таблице «Тесты».

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

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

Тестирование доступности

Как показало исследование The State of Frontend 2022, респонденты уделяют большое внимание доступности, и 63% прогнозируют, что в ближайшие годы этот тренд наберет большую популярность. 

Доступность в Storybook можно тестировать с помощью аддона storybook-addon-a11y. После установки аддона появится вкладка “Accessibility”, где можно увидеть результаты аудита текущей истории.

Работа с моками

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

Aддоны для имитации API и контекста

Аддоны Storybook могут помочь вам имитировать различные сценарии использования компонентов, такие как запросы API или различные значения контекста. Это позволит вам быстро тестировать компоненты в реалистичных сценариях. Если в вашем компоненте используется провайдер для передачи данных, то можно применить декоратор, который оборачивает историю и предоставляет замоканную версию провайдера. Это особенно полезно, если вы используете Redux или контекст. На проекте мы работаем с контекстом, поэтому делюсь ссылкой на пример создания декоратора для контекста: react-context-in-storybook.

Решаем проектные задачи. Мой опыт

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

• Трата ресурсов на пользовательский путь

Отличительной чертой моего проекта является то, что бэкенд полностью отвечает за роутинг. Сервер возвращает ответ с тем, какой экран нужно отобразить. Чтобы «перекрасить кнопочку» на последнем экране приложения, разработчику необходимо сбросить тестового пользователя на начало пути, запустить приложение, авторизоваться, дойти до нужного экрана, заполняя по пути все формы, и только после этого проверить, применился ли новый стиль для кнопки. 

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

• Разработка без реальных данных

Часто возникают ситуации, когда разработка пользовательского интерфейса начинается раньше, чем готов API от бэкенд-разработчиков. Storybook позволяет создавать компоненты с заглушками для данных, которые в будущем будут получены из реального API. Это позволяет разработчикам прототипировать и тестировать пользовательский интерфейс, независимо от наличия или готовности бэкенда, и применять мок-данные для демонстрации компонентов.

• Часто меняющийся дизайн

На проекте мы часто сталкиваемся с изменениями в дизайне макетов, и для нас очень важно быстро адаптировать наши компоненты под эти изменения. Storybook позволяет быстро создавать и сравнивать различные версии компонентов, что помогает сэкономить время и сделать процесс разработки более эффективным.

• Проблемы инфраструктуры

Команда может столкнуться с проблемами, когда тестовый стенд или сервис партнера перестает работать. Это чревато задержками и потерями производительности. Однако с помощью Storybook возможно продолжать работу даже при подобных сбоях, разрабатывать компоненты в изоляции и не ожидать восстановления работоспособности тестового стенда или сервиса. Storybook также позволяет быстро переключаться между версиями приложения и тестировать компоненты в различных контекстах. Это значительно сокращает время простоя и увеличивает производительность.

• Передача проектных знаний

В больших проектах вхождение нового специалиста может занять много времени и ресурсов. Storybook позволяет разработчику быстро ознакомиться с каждым компонентом проекта и его работой, понять структуру проекта и начать работать над конкретными компонентами, не изучая всё с нуля. Это делает процесс разработки более простым и интуитивно понятным, даже для тех, кто не знаком с определенным фреймворком.

Мой опыт показал, что фронтенд-разработчик, работающий на Vue, может быстро ознакомиться с компонентами, написанными на React в Storybook и выполнять небольшие задачи по верстке без необходимости изучения всего проекта React. 

• Сборка приложения занимает много времени

Webpack является мощным инструментом для сборки JavaScript-приложений. Но при разработке больших приложений сборка проекта может занимать длительное время. Эта проблема решается с помощью Storybook и применения автоматической компиляции и сборки компонентов при каждом изменении. Так разработчики быстро получают обновленные версии компонентов без пересборки всего проекта. Кроме того, Storybook позволяет использовать дополнительные плагины и расширения для Webpack, которые помогают улучшить производительность и оптимизировать время сборки проекта.

Как правильно готовить?

Один из ключевых элементов работы с Storybook — это истории. Рассмотрим несколько лучших практик написания историй для Storybook.

1. Отнеситесь к использованию и поддержке Storybook серьезно

«Это же не прод, зачем заморачиваться?». Это частое заблуждение, которое встречается во многих командах. Storybook важно поддерживать в актуальном и рабочем состоянии. Помните, что с ним будут работать ваши коллеги, по сути ваши пользователи. Не допускайте наличия лишних или нерабочих историй, которые могут запутать коллег и замедлить работу. Также рекомендуется периодически проводить рефакторинг историй, чтобы сохранить чистоту и структурированность.

2. Используйте группировку историй

Когда вы начнете писать истории, их может быть очень много. Используйте группировку по компонентам и функциональности, чтобы истории можно было легко найти.

3. Отражайте в историях конкретное состояние или API компонента

Названия историй должны быть понятными и легко читаемыми. Не используйте слишком общие или неинформативные названия, например, "Button" или "Form". Отражайте функциональность компонента, например, "Primary Button" или "Login Form". 

Например, у нас есть компонент кнопки, type свойства которого принимают значения primary, secondary, tertiary или error. Тогда у нас будет четыре истории: Button/Primary, Button/Secondary, Button/Tertiary и Button/Error. Есть как минимум две  причины следовать этому шаблону:

• Легче поделиться ссылкой на компонент, точно определяющий состояние, на которое вы хотите сослаться, что полезно при общении с QA и дизайнерами.

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

Также не забывайте добавлять описание к каждой истории.

4. Придерживайтесь одинаковой разбивки на Story

Давайте рассмотрим, как разработчики из Audi справились с созданием Storybook для своей ui-библиотеки. Например, Checkbox:

В разделе Properties перечислены все свойства, которые могут использоваться с компонентом, а также возможные значения для каждого свойства. В Overview представлена краткая информация о компоненте, ссылки на макеты и лучшие практики по работе с ним. В Variations демонстрируются все возможные варианты использования компонента. На вкладке Accessibility описаны решения, предоставляемые компонентом для улучшения доступности. И, наконец, на вкладке All Stories представлены всевозможные тест-кейсы для компонента, позволяющие протестировать его функциональность и взаимодействие с другими компонентами.

1. Организуйте понятную структуру

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

2. Соблюдайте DRY подход при написании моков

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

// DocumentScreen.jsx

import React from 'react';

import { PageLayout } from './PageLayout';
import { DocumentHeader } from './DocumentHeader';
import { DocumentList } from './DocumentList';

export function DocumentScreen({ user, document, subdocuments }) {
  return (
    <PageLayout user={user}>
      <DocumentHeader document={document} />
      <DocumentList documents={subdocuments} />
    </PageLayout>
  );
}

// DocumentScreen.stories.jsx

import React from 'react';

import { DocumentScreen } from './YourPage';

//???? Импортируем истории подкомпонентов
import * as PageLayout from './PageLayout.stories';
import * as DocumentHeader from './DocumentHeader.stories';
import * as DocumentList from './DocumentList.stories';

export default {
  title: 'DocumentScreen',
  component: DocumentScreen,
};

const Template = (args) => <DocumentScreen {...args} />;

export const Simple = Template.bind({});
//???? Используем данные из подкомпонентов
Simple.args = {
  user: PageLayout.Simple.args.user,
  document: DocumentHeader.Simple.args.document,
  subdocuments: DocumentList.Simple.args.documents,
};

Преимущества и недостатки Storybook

Преимущества

Более надежные пользовательские интерфейсы

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

Одно из главных преимуществ Storybook — возможность использования моковых данных, аддонов для имитации контекста, запросов API и так далее. Это позволяет разработчикам проверять компоненты в различных условиях, что повышает надежность и безопасность интерфейса.

Тестирование с меньшими усилиями и без ошибок.

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

Доступная документация

Storybook — ценный источник информации об интерфейсе. Он индексирует все компоненты и состояния, облегчая поиск и повторное использование существующих шаблонов интерфейса для вашей команды. А также автоматически создает документацию из историй, позволяя разработчикам быстро и легко получить необходимую информацию о каждом компоненте. Storybook поможет вашей команде быстрее находить и повторно использовать существующие компоненты интерфейса, что уменьшает время и усилия на разработку и тестирование.

Шэринг для взаимодействия с командой

Storybook демонстрирует реальное поведение интерфейса, а не только задуманное. Можно выложить его на отдельный стенд, чтобы все участники команды были в курсе актуального состояния проекта, знали, какие компоненты уже существуют, а какие нуждаются в обновлении. Также знакомство со Storybook сократит время на коммуникацию со специалистами по контролю качества и менеджерами проекта.

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

Недостатки

Нестабильность 

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

Необходимость настройки 

Для работы с Storybook необходима настройка конфигурационных файлов, что может занять время. Некоторые разработчики могут считать эту процедуру утомительной. Несмотря на то, что Storybook поставляется с готовым конфигурационным файлом, иногда требуется дополнительная настройка, чтобы адаптировать Storybook под специфические требования проекта. Могут понадобиться знания Webpack или Vite.

Не всегда подходит для быстрого прототипирования

Storybook может быть очень полезным для разработки сложных компонентов, но для простых прототипов он является оверхэдом.

Необходимость поддержки

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

Заключение

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

Однако перед тем как принять решение об использовании Storybook, учитывайте следующие факторы:

• Опытность. Если вы не имеете опыта работы с Storybook, то может потребоваться дополнительное обучение и практика для эффективного использования инструмента.

• Масштаб проекта. Storybook может быть полезным для крупных проектов, которые содержат множество компонентов, но будет избыточен для небольших.

• Команда разработчиков. Если вы работаете в большой команде, то использование Storybook может потребовать координации и согласования с другими членами команды.

Спасибо за внимание!

Полезные материалы о frontend-разработке мы также публикуем в наших соцсетях – ВКонтакте и Telegram.