Just finishing up a Storybook based on the v8 beta and was pleasantly surprised how far it's come along since I last tried it a few years ago. The auto docs (with the help of react-docgen) while still a bit rough on the edges and buggy in the new release is amazing. I wish the documentation was a bit better in some areas (the examples are usually repeated simple use cases from their demo content like a button) but I was able to achieve most of what I needed and then some.
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.
> 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
Haven't used MSW, but don't people use it for mocking APIs? Isn't that apples and oranges? If your stories need data, you can always still use MSW. But otherwise when it comes to testing (in the app vs. Stories) I'd agree. Not exactly testing, but the play feature beats E2E if you want to show a smooth demo for clients/fellow devs.
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.
> Haven't used MSW, but don't people use it for mocking APIs? Isn't that apples and oranges?
At first, I was confused by what OP meant, too, but I think the point is that if you can mock your data easily, then getting your app into the desired state is straightforward enough that Storybook becomes unnecessary. At least, that's how I interpreted it.
Thanks. Need to try MSW, but right now it's not clear to me how it can be used more than a fake HTTP endpoint. With Storybook, I can create links with any set of props I want for each component (or change with the controls). A lot of state doesn't rely on a back end (client side history or user prefs stored in local state, etc.).
The Storybook use case and the MSW use case is fairly similar to me: develop your SPA in separation from the backend and this is how Storybook was pitched to me and is usually pitched. Both allow me to hook up the backend after a component has been developed.
> the play feature beats E2E if you want to show a smooth demo for clients/fellow devs
We actually haven't used this at all, but it's a neat feature.
The tradeoffs we evaluated were:
- Storybook allows to develop components in isolation, but requires to structure your components in a very specific way that is detrimental to how React works (see my other comment with the Oxide in the thread).
- MSW allows to develop your whole app in isolation but it lacks all of the bells and whistles that Storybook has (e.g. testing, various plugins, demo, discoverability of the components).
But in general, our use case is developing an internal SPA using Tailwind, so we don't exactly have a component library that we need to develop in isolation. I can see the value of Storybook if that's the case for your team. Many other companies maintain their homegrown UI library that could benefit from all of the features of Storybook, so it makes sense for them.
Thanks for the explanation, but I still don't understand how MSW and Storybook are comparable. As you said, MSW can be used to isolate a "backend". But Storybook really mainly to isolate the "frontend" parts. I see the point of both. On that note, while pretty happy with my current mocking solutions I've been meaning to take a closer look at MSW!
How does SB require a certain component structure? I didn't have to touch mine. They have a "sub component" feature for documenting nested components that work together, although I didn't even use it. Just used either decorators or render functions in my stories where needed (which did require a little wiring up to update the args).
I don't use Tailwind (yuck, sorry!), but how is choice of styling a factor?
The auto docs have some weird glitches and did force me to adjust my TS types a bit is my complaint (and react-docgen-typescript wasn't working for me at all).
I agree that SB is probably not worth the effort for everyone though.
> which did require a little wiring up to update the args
> The auto docs have some weird glitches and did force me to adjust my TS types a bit is my complaint
This, to me, is the biggest downside of Storybook. Storybook might provide reasonable defaults but if you want to configure how exactly things are supposed to look & behave, and want type support, you are in for a world of pain, arcane magic, and glitches. My team recently convinced me to give Storybook another shot in our current project and I regret it already and now remember again why I always disliked it. We are indeed developing a component library and in hindsight I would have preferred to write a simple Vue app showcasing our components, and adding any component controls myself.
I used Storybook often, but the transition on each major release was painful.
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.
Storybook is great and all, but these days nearly every Dependabot alert I get is about a sub-dependency of Storybook. Since Dependabot doesn't currently allow you to ignore dev dependencies and only check production dependencies [0], this makes Storybook a Big Noise Generator and every time I dismiss another alert from it, I can't help but wonder if there's a better option out there.
Looks like it does – you can add a rule to set the enabled option to false for all devDependencies. It’s the third example in the docs for the enabled option:
It’s also extremely bloated. The storybook related dependencies were slowing down our builds significantly. We have done additional storybook plugins, but making storybook an optional dependency reduced the build server’s node_modules size by 1GB!
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.
I just tried Storybook this past week and it's a great improvement even from version 6.x.
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.
We have a Storybook set up that displays components rendered with PHP and Twig using a REST API endpoint on our WP install. Pretty crazy setup but it works. We use play functions in Storybook to fire the request and just render the returned HTML from the server.
I'd be curious to hear from everyone what's the use case for using Storybook in 2024?
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.
Why only for UI libraries? I imagine you can develop & test your UI independently from your app. Say a page has complex form with many states, you test it out in storybook before embedding in your app and connecting to your API backend. The other things is for all your custom components, easier to onboard a new developer, they can just look at storybook to see if a UI component already exists in the project, without having to dig through the code.
I've used Storybook during development for a while now and the use case you present is how the Storybook is usually pitched. I actually agree about the simplicity of discovering the components. What I disagree with, though, is that I can't see the value of "develop & test your UI independently from your app" part. It forces me to decouple the state from a component and this in turn adds unnecessary complexity to the architecture.
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.
I don't think the point is to isolate all state. In the SiloUtilizationPage, I would assume that the hard part is getting the result of the two useApiQuery calls. The other state could be set up by clicking around or in a `play()` function. Since you're using ReactQuery, you can just create a separate QueryClient for testing, call `setQueryData` on it, and then pass it in through a context.
That way you could render this component without any changes to it.
We may have been using it incorrectly in my team, but our pattern is moving out all of the state out of the component, essentially separating the logic from the view.
This has great discoverability for other eng teams ime. Duplication of components across multiple product teams is a drag on velocity and a major pain when you want to update brand/design across the board. In a previous role, we spun up a Storybook with the few dozen atomic React + pure HTML components, shopped it around the relevant teams. Saw great uptake for centralizing components, and a few teams did storybook-driven development for their more complex UIs. Can recommend.
Also very useful for non technical stakeholders (design, product, etc) to test UIs in isolation.
I'd go as far as saying: use both Storybook and MSW!
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.
I've used both MSW and Storybook, and they're both fine. They both have some advantages and disadvantages. One advantage of Storybook is that getting to a particular state on a particular page is a matter of selecting the right story, whereas with our MSW setup, I have to simulate a login with a user with the right characteristics, and then navigate through our UI to get to the step in the flow I'm looking for.
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.
It's not equivalent. Storybook has lots of features and plugins that make it useful.
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.
Totally bizarre, it's the second time in the thread I saw this comparison being drawn. From what I've seen in the past HN seems to fail to understand ideas like "design systems" and "component libraries" or sometimes even frontend at large, perhaps the confusion comes from there...
It's totally unfair to say that we don't understand design systems or component libraries when I mentioned in multiple comments that in our case we don't have a component library. Component library is a valid use case, as I mentioned previously, but it seems to me that our setup with no component library is fairly uncommon.
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.