storybook организация проекта
Возник вопрос. С самим Storybook в общих чертах все понятно. Но как это все взаимодействует с проектом?
Я создаю компоненты, пишу для них story, и все замечательно и хорошо. Я это должен в итоге использовать просто как набор компонентов, лежащих где-то которые я беру и копирую в проект? Но в этой истории есть проблема - получается две копии компонентов, которые могут независимо меняться.
Можно, конечно, извратиться и писать компоненты так, чтоб они работали и в storybook, и в проекте, но появляется тогда какой-то дополнительный код, который понимает, в какой среде он запущен. В общем, буду признателен, если кто - то поделится опытом. Такое впечатление что не хватает какого то кирпичика для понимания.
Ответы (1 шт):
Человечество изобрело другие способы повторного использования компонентов кроме копипаста.
Один из них - организовать вашу библиотеку с компонентами в отдельный npm package, к которому и прикрутить сторибук. При этом разумеется необязательно (и даже нежелательно) замусоривать npm registry - современные пакетные менеджеры поддерживают локальные зависимости. Проблема "нескольких источников правды" обычно решается именно так.
Можно, конечно, извратиться и писать компоненты так, чтоб они работали и в storybook, и в проекте, но появляется тогда какой-то дополнительный код, который понимает, в какой среде он запущен.
Нужно.
Если у Вас компонент не работает и в сторибук и в проекте то он имеет какую-то неявную зависимость от проекта (или от сторибука). А неявные зависимости обычно чреваты отстреленными ногами.
Также это может быть очень проектоспецифичный компонент. Но тогда пусть останется в проекте, не надо тащить на общий стол все что сделяль.
Дополнительный код для компонента обычно писать не нужно (хотя способы для этого есть).
Что нужно - это возиться с конфигурацией. У сторибука свой конфиг вебпака, бабеля, тайпскрипта и черта лысого. И чтобы компоненты хотя бы работали в проектах и сторибуке, эти конфиги надо как-то дружить.
В итоге, разработка со сторибуком (и аналогами) - это практика для более-менее зрелых проектов с какими-то требованиями к надежности и общей кодовой базой. Если Вам нужен ультраскоростной хренак-хренак, то сторибук только мешаться будет.