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

21–30 of 38 posts

Re: Storybook 8

#21

Post by varrock »

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…

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

Re: Storybook 8

#22

Post by unleashit »

varrock wrote: post #21
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…

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

Re: Storybook 8

#23

Post by [deleted] »

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…

[deleted]

Re: Storybook 8

#24

Post by kaelig »

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.

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.

Re: Storybook 8

#25

Post by Cannabat »

silverlyra wrote: post #5
Cannabat wrote: post #3

Earlier quoted context omitted.

I wonder if renovatebot [0] supports this? [0] https://github.com/renovatebot/renovate

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: https://docs.renovatebot.com/configuration-options/#enabled

Thanks - I was looking in the wrong place in the docs.

Re: Storybook 8

#26

Post by SebastianKra »

mm263 wrote: post #12
dsego wrote: post #8

Earlier quoted context omitted.

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…

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.

Re: Storybook 8

#27

Post by morbicer »

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…

Exactly why we ditched it. Our compliance doesn't even allow vulnerabilities in the dev tools so we can't ignore them

If you are a React shop, give https://ladle.dev/ a try, much more lightweight

Re: Storybook 8

#28

Post by codethief »

unleashit wrote: post #20
mm263 wrote: post #19

Earlier quoted context omitted.

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

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

Re: Storybook 8

#29

Post by Vinnl »

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.

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.

Re: Storybook 8

#30

Post by lloydatkinson »

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.

How is a network mocking tool equivalent to Storybook?
Post reply on HN