After using Storybook for a couple years at work, I've soured on it. The Canvas / Docs distinction is weird and confusing. There are lots of poorly documented aspects (did you know pressing "S" causes the sidebar to disappear without any sort of visible way to open it again?). The controls are awkward to build complicated components around.<p>Consider just rolling your own component showcase. You can do it in a day and probably get a much cleaner and more straightforward static site out - all you really need is a sidebar and then display areas hooked up to buttons. That's it. Storybook is just a heavy, complicated, awkward set of abstraction layers over that very simple core experience.
I think what most developers use Storybook for is development in isolation which is essentially what TDD is about.<p>In fact what we end up doing with Storybook is that we create the "stories" (literally .stories.ts files) that renders each component with a specific permutation of props. However this is pretty much a copy of the .test.ts file we write for the component itself - so many times it's literally doing pretty much the same stuff.<p>I find it so weird that in 2021 we don't have a way to just render our test files (which essentially is using some server-side dom abstraction) also to a browser so we can view the component and develop against it.<p>Then we wouldn't need storybook or story files that describe how a component is rendered - that's the test file responsibility.
My main issue with Storybook is how much trouble it is to get everything else running with it. Need next-image? Routing? i18n on demand?<p>Tough luck - you'll need to implement it for both the app you're building and Storybook. And sometimes implementing it in the app itself is the _easy_ part. Nevertheless, I feel like it does improve the dev experience and intend to keep using it. You just need to know when to cut your losses and not use it for more complex use-cases.
We've been using Storybook for isolated development of state-heavy components and it's been a nice productivity booster, compared to testing inside the actual app.<p>As a bonus, the stories that get created live in your codebase and can be integrated into several different types of testing - jest test suites, visual regression testing, and puppeteer / Selenium.<p>There's certainly an overhead for mocking data properly, but I tend to see that as part of the general challenge of testing frontend / JS code.
I use Storybook at work, and while it works ok for the most part, it wouldn't be my first choice to creating a UI component library. Most of what it offers is IMO not that important. And it's quite bloated at this point.<p>I also think that building a bespoke environment for building components in isolation isn't that hard and is probably worth doing if the company is thinking long term. I'll certainly be doing that in the future.
For a bit more simple alternative I might suggest Fractal - <a href="https://fractal.build" rel="nofollow">https://fractal.build</a> . While it doesn't have so much knobs and whistles as StorybookJS, it's easier to set up and get running for smaller projects.
For anyone interested in this space and wishes something like this existed for Android, I got you covered! I open sourced this project last year - <a href="https://github.com/airbnb/Showkase" rel="nofollow">https://github.com/airbnb/Showkase</a>
It was a godsend, I always wanted something like this. I’ve used it in around 10 projects over a year (2019-2020j and it broke every time, suddenly, from a day to another.<p>I hope nowadays it’s more stable. Personally I’ve ended up rolling my own and it works as a charm, integrated with unit tests
For those looking of component showcase i'd kindly advise to also look at <a href="https://bit.dev" rel="nofollow">https://bit.dev</a>, <a href="https://github.com/teambit/bit" rel="nofollow">https://github.com/teambit/bit</a> . It is a standalone service that hosts your components, providing each of it as a npm package.<p>You end up developing the components in a separate repo, and in your main app repo you install each component as dedicated npm package. Those who get excited by `separation of concerns` pattern should find this a real joy.
Storybook is breaking our build. It has Reach Router as a dependency. Reach router does not support React 17 - they PR to support it has been open for nearly a year!! So this week, we were required to upgrade to React 17.0.2 and Storybook broke our build because of its dependency of Reach Router. i.e. NOT FUN!!
I feel like storybook is more complicated than it needs to be, but it's still valuable. I've used it with success in the past. It essentially gives you a standardized way to build out a fully implemented design system rather than just the spec for one in something like Figma.<p>That said, I've really wanted a good alternative for React Native that's similar. Storybook ostensibly works there, but it's more than a little clunky.
For those who are using Storybook:
Do you develop your component in storebook first? Then implement on your actual page?<p>Also are you able to leverage it for automation test? I.e. if you have a photo gallery...have a state where it has 0 photos, 1, 2.. and have some UI automation test (i.e. Selenium) run against it?<p>If not do you have any recommendations for something like this kind of use case?
I've had a lot of success with Storybook as a development aid on a large legacy application where VueJS is slowly taking over.<p>Will use it for building components of any complexity and size under "screen" leaving just the "last mile" to work out in the legacy app. Have it configured so the API can be hit and/or pre-recorded API calls can be used.<p>It has made cross-browser testing and fixes(looking at you Safari) quite quick. Leaned on it for large CSS/SCSS refactors and style updates.<p>Could something like this be written from scratch? Sure, but why? It's a set of conventions already in place and documented. Setting it up was a breeze and creating a "story" can be just about as simple or complicated as you want.
I'm on my second team that's tried and failed to implement this (well, I consider the current setup a failure, the leads apparently don't?).<p>Extra work for no benefit, broken builds, type and lint ignores everywhere, demos always out of date or incomplete.<p>If your designers are skilled and organized, you don't need this. "But my team doesn't have skilled or organized designers!" ... well then you probably have bigger problems, messing with Storybook is the last thing you want.
So, so many people in the comments saying "good to design components in isolation".<p>Why would design your components in isolation? Do they never interact with each other? Appear next to each other on a page? Participate in a layout?<p>This is my main gripe with Storybook in particular and any design system and design system tool in general: they never consider how components work together and force into a mindset of just documenting separate components complete isolation.
I’ve used storybook for 4-5 years (basically since day one) in teams of 1-15 devs and I’d say it’s a must have for any serious react app with 3+ full time developers. It has its rough edges sure but the ROI is 10x nonetheless in my experiences.<p>Advantages<p>- Testing components in isolation forces some good practices and allows to keep the codebase in check by encouraging good practices (limited coupling of unrelated parts of the codebase<p>- It’s super productive because it is both a form of unit tests, useful during development of UX in « TDD mode », and a very good documentation of your UI components. It greatly reduces the effort needed for both these aspects.<p>- For DX, the hot reload is generally faster in storybook than in the App (except if you use vite/snowpack in your app, so far..) because reloading a single component is faster than reloading the whole app and its state. In a large CRA our hot reload could sometimes take up 1min in complex cases, while storybook was taking 3s.<p>- Coupled with Chromatic (their hosted platform) and its GitHub integration it makes QA and visual regression testing a joy, 10x faster than alternatives, I really recommend that.<p>- It allows to share/iterate easily your ongoing developments with non-tech people in your organisation at early stage. A very good bridge between Figma and the final UI. A good support during Daily meetings about UI, just share the deployed story url to ask for feedback.<p>Drawbacks<p>- It has its own Webpack config. So if you have a custom Webpack config in your app (don’t do that anyway, unless absolutely necessary) then be prepared to duplicate the customizations in your storybook config<p>- Global React Contexts needs to be duplicated in your storybook config and, if necessary, configured for individual stories. For example if your signup button changes based on an Auth status stored in a global context, then you will have to use Story.parameters to customize the content of the Auth context.<p>- We had a couple instances where storybook was the limiting factor for us to embrace some new/fancy tech, like yarn v2 or service worker. However maybe that’s a good litmus test: things that storybook support are state of the art JS and generally safe to use. Things that storybook does not support out of the box will cause you problems with other tools anyway: if it’s not storybook, some other tool like Cypress, Jest, Next, or some browsers will cause you trouble with your “shiny new tech”<p>- It can be slow to startup. We had a storybook with 300+ complex stories and it took 5min to startup and 10min to build in the CI<p>- It had some API changes/ migration pains a couple years back. However I think the new API is very good and will last a long time so this is behind.<p>Overall I definitely advocate to use storybook, especially with Chromatic, the ROI is 10x. If you find yourself limited by it in 2021 despite configuring it, maybe question your own tech stack.<p>Don’t try to implement your own storybook copycat (we had a colleague develop an alternative <a href="https://github.com/remorses/vitro" rel="nofollow">https://github.com/remorses/vitro</a> , but i think it was not worth the effort)<p>If you want to see a state of the art monorepo in NextJS that uses storybook extensively with some customizations, check <a href="https://github.com/Labelflow/labelflow/" rel="nofollow">https://github.com/Labelflow/labelflow/</a>
Storybook is too complex and hard to understand. It adds to the growing frontend complexity.<p>A component system is very useful though. Wish something simpler was available.
We had a tricky UI state component recently -- a sharing panel complete with notifications, RBAC, entitlements, loading indicators, and error handlers -- which was a religious moment for us on Storybook. A way to specify the expected states of interest and being able to click through them helps a lot!
as react-native dev, storybook feels like pilling a bunch of cards, you don't want to have to mess around with your base configuration, it's the worst. I've looked into alternatives multiple times, the closest I got is react-cosmos.
There should be adjustable knobs atop a figma design. Just make a component withKnobs that wraps the component on a parent which passes it's knob controlled state to child