Современное и масштабное frontend-приложение сложно разработать без создания компонентов, даже если используется какая-то готовая библиотека компонентов.
Хотя чаще мне приходилось участвовать в проектах, где используется собственная UI-библиотека (кнопки, поля ввода, иконки, выпадающие списки, меню и пр.).
Для всего этого последние 4 года и на трёх разных проектах я использую Storybook . И в этой статье я расскажу, почему Storybook является очень полезным инструментом. Статья будет полезна тем, кто не пробовал Storybook, или сомневается в его пользе.
Что такое Storybook?
Если очень кратко, то это каталог с демонстрацией ваших компонентов в различных состояниях.
Когда пригодится Storybook?
Практически всегда при разработке frontend-части для долгосрочных проектов.
Взять к примеру простой компонент кнопки. У кнопки есть много меняемых параметров: цвет, размер, иконка, индикация состояния (загрузка, disabled и пр.) и так далее. Также нужно учитывать, как кнопка впишется в другой компонент (карточка товара или другой виджет) или отобразит очень длинный текст.
При разработке MVP легко контролировать такое разнообразие состояний компонентов. Но проект разрастается: растёт количество компонентов, их сложность, их взаимосвязь.
И если в какой-то момент вы решите отрефакторить компонент кнопки, то придётся сделать очень много приседаний, чтобы протестировать поведение кнопки во всём проекте. А если где-то на середине тестирования обнаружится некорректное отображение кнопки без текста, то после исправления компонента придётся тестировать всё заново. Это может быть очень унылым занятием, если для отображения проверяемого состояния придётся совершить много подготовительных действий. А теперь представьте, что вы отрефакторили что-то сложнее кнопки.
К примеру, недавно я разрабатывал сценарий, состоящий из 4 последовательных шагов. Для проверки вёрстки на последнем шаге мне приходилось совершать много повторяемых действий.
Поняв, что это отнимает много времени, я создал для всех 4 экранов так называемые истории. Это позволило мне исправлять вёрстку любого компонента и в любой момент времени, не задумываясь о бизнес-логике.
Как изменится код проекта?
Каких-то кардинальных изменений в код проекта вносить не нужно, Storybook спокойно встраивается в текущую структуру проекта.
Хотя лично меня Storybook приучил ещё больше разделять логику и представление, так как для простых компонентов проще создавать истории. Но это субъективное, потому что есть любители обмазываться моками.
Когда внедрять Storybook?
Мой опыт подсказывает, что внедрить Storybook можно в любой момент жизни проекта, пусть и со своими нюансами.
Если внедрить Storybook в начале жизни проекта, то можно погрязнуть в постоянной синхронизации компонентов и историй.
Идеально, если API компонентов готов по принципу Парето хотя бы на 80%, и дальше планируется только поддерживать стабильное расширение функционала.
А если ещё и деплоить ваш сторибук на тестовом сервере, то можно подключить QA-специалистов к тестированию интерфейса.
Давай ещё что-нибудь про Storybook
Я использовал Storybook для проектов, написанных с использованием React и Angular. Но на этом список поддерживаемых платформ не заканчивается: Storybook можно развернуть для приложений, написанных на Vue, Ember, Svelte и пр.
Пользовался в качестве альтернативы Styleguidist, но так как мне лень делать объективное сравнение, отдам субъективный голос в пользу Storybook.
Вывод
Storybook — это здорово.