Comment by mm263 | Hacker News Reader

Comment by mm263 | Hacker News Reader

Parent Full thread

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

Reply on news.ycombinator.com