For those wondering what the use case is, you must not have tried it. It does take work to set up (with each version that's less), but it can be very nice to test in isolation esp in cases where a component is under a login, the 4th page of a 10 page form, etc. Also obviously if you're working on a component library that ships without an app, Storybook can be your development and/or demo app.
I have worked with storybook extensively over the past couple of years and my team is moving away from it in favour of MSW (https://mswjs.io).
For "4th page of a 10 page form" during the development there's hot reloading which is really stable nowadays and haven't failed me, although I understand that some setups are old and it might be easier to configure Storybook than good hot reloading.
I'm not entirely sure about the testing part of it and I'd be grateful if you could elaborate. I haven't felt the need for some special setup with SB because for unit tests, I can test a deeply nested component separately with react-testing-library. For E2E tests, I usually test the whole form anyway.
I agree on the component library part, this is probably the only use case where Storybook is 100% justified, but I'm unconvinced about the usual SPA use case
As far as live reload, you're right but only once you've achieved the state. If you're firing up storybook or moving between components, you can already have any state ready to go (or quickly set with the controls). If you're in the actual app and don't have something like Redux Dev Tools, you have to manually go through the steps.... which can be a pain.
That said, so far I'm only using Storybook for the "component library" use case. And for that it's a big improvement from the previous DIY app I had.
The main issue is that Storybook provides an interface for the server and transpiler/compiler process. So, if you already have Webpack, Vite, Parcel, or Next, you’ll need to configure SB to work with your toolchain. After many frustrations, I created an ad-hoc page using the import.meta.glob from Vite in my latest projects. Loading files utilizing a sub-set of SB CSF is easy, and that crappy ad-hoc playground covers 80% of my use cases, with the possibility of migrating to SB if I need more.
SB is very useful for anyone doing a DS, but now is too big for my needs.
[0] https://github.com/dependabot/dependabot-core/issues/2521
This sounds familiar, but, on a positive note, I take this as a reminder to update all my project's dependencies. Dependabot alerts typically start popping up a month or two since the last update, by which time a dozen of direct dependencies usually have a newer version.
If you are a React shop, give https://ladle.dev/ a try, much more lightweight
That said, I wish this was at a place where I could easily use it for the UI layer with simple integration into a given CMS. As others have stated, it's great in isolation and for demos. Also, I realize that most apps and CMSes are so opinionated and using Storybook for the view of that system is a lot of overhead.
One less than stellar example is WordPress. It's technically possible to create a headless app using Next.js or Remix on the front-end, Gutenberg for the data layer and authoring, and Storybook as the source of truth for both ends. However, it was so much work to get there.
Maybe a legacy PHP system trying to be modern isn't a great example. But, then I'm stuck with any flavor of, usually paid database hosted, software like Contentful or Sanity. Again, the overhead!
I am a huge advocate for design systems that translate into component libraries, and Storybook fills part of that gap, but it'd be huge to see this type of setup become more practical.
The only one I can think of is developing a UI library, but for the usual SPA development, it seems to me that MSW provides a much smoother and less obtrusive dev experience without affecting how my app is architected.
I'm going to use Oxide console [1] as an example because it has a really good setup of MSW + OpenAPI autogenerated mocks (which means that it doesn't need any complete running backend, just a defined contract).
Consider this fairly simple page [2]. If I'm using the Storybook pattern, I'm keeping all of the state outside of the component, which means I now have to manually memoize every single variable defined before the return to make sure that the component doesn't do any unnecessary re-renders. This includes `intervalPicker`, `commonProps`, `setFilterId`, every return of `useDateTimeRangePicker`. With MSW I have benefits of not needing the API as well as developing in the context of a real production app, using the same exact mocks for unit tests and development.
[1]: https://github.com/oxidecomputer/console
[2]: https://github.com/oxidecomputer/console/blob/main/app/pages...
Also very useful for non technical stakeholders (design, product, etc) to test UIs in isolation.
They're both amazing tools, solving intersecting but different needs.
As part of your SPA (or MPA) development, UI state complexity will inevitably grow, and shipping seemingly small cosmetic or logic changes becomes scary.
Documenting component states in Storybook and plugging it to a tool like Chromatic or Percy or Applitools, will catch visual/accessibility/interaction regressions as a CI step.
I work at Netlify where it's an integral part of "how we build", and the peace of mind we get out of these tests is amazing DX.
In another project we've adopted React Server Components, and no longer have an API - so MSW is not even an option there. Storybook does work, although it's still a bit of a hassle to have to split our Server Components into two components, only one of which actually makes use of server-side APIs.
What I'm saying is that effectively, my team has been using Storybook to develop components in isolation from the backend or the rest of the app and this was the main feature that we utilized. For example, we develop whole pages in Storybook. Our use case is that we also don't have a component library which is what people use it for primarily, from my understanding. Component library is a valid use case for teams who have a homegrown set of components but we don't have one.
So in our use case, developing a component in Storybook meant writing a story that passes all of the props and different prop variations to a component that doesn't have any state inherently. Swapping Storybook to MSW allowed us to avoid structuring components in a specific way (e.g. separating state from the JSX) while retaining the benefits of not having to have a complete backend.
In conclusion, we used both tools primarily to develop our SPA in separation from the backend. MSW filled this niche (which was specific to us) better.
