Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Storybook 8

storybook.js.org

Post reply on HN
Print view View original

11–20 of 38 posts

Re: Storybook 8

#11

Post by technojunkie »

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.

Re: Storybook 8

#12

Post by mm263 »

dsego wrote: post #8
mm263 wrote: post #7

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…

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

Re: Storybook 8

#13

Post by mm263 »

maclockard wrote: post #10
mm263 wrote: post #7

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.

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

Yes, sorry for the confusion

Re: Storybook 8

#14

Post by gehen88 »

technojunkie wrote: post #11

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…

Interesting! What would the integration between Storybook and a CMS such as Wordpress look like, ideally? How would you use it?

Re: Storybook 8

#15

Post by mm263 »

unleashit wrote: post #9

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…

> 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

Re: Storybook 8

#16

Post by lowboy »

dsego wrote: post #8
mm263 wrote: post #7

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…

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.

Re: Storybook 8

#17

Post by unleashit »

mm263 wrote: post #15
unleashit wrote: post #9

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…

> 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 sto…

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.

Re: Storybook 8

#18

Post by lyjackal »

Etheryte wrote: post #2

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. [0] https://github.com/dependabo…

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!

Re: Storybook 8

#19

Post by mm263 »

unleashit wrote: post #17
mm263 wrote: post #15

Earlier quoted context omitted.

> 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 sto…

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…

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.

Re: Storybook 8

#20

Post by unleashit »

mm263 wrote: post #19
unleashit wrote: post #17

Earlier quoted context omitted.

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…

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 tradeo…

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.

Post reply on HN