[mm263]

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.

[dsego]

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.

[mm263]

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.

[1]: https://github.com/oxidecomputer/console

[2]: https://github.com/oxidecomputer/console/blob/main/app/pages...

[SebastianKra]

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.

[mm263]

> I don't think the point is to isolate all state

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.

[lowboy]

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.

[kaelig]

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.

[Vinnl]

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.

[maclockard]

What does MSW stand for here? Maybe "Mock Service Worker" https://mswjs.io/?

[mm263]

Yes, sorry for the confusion

[lloydatkinson]

How is a network mocking tool equivalent to Storybook?

[mm263]

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.

[thiht]

Same question here, I see absolutely no overlap between the two

[lloydatkinson]

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...

[mm263]

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.

[Nullabillity]

Looks like the same person raising it in both cases.

[dbbk]

Looks like MSW is just a network override, how is that comparable?