7 ms·

Storybook 8

86 points by unleashit 3y ago

Etheryte 3y ago
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/dependabot/dependabot-core/issues/2521 https://github.com/dependabot/dependabot-core/issues/2521
- Cannabat 3y ago
  I wonder if renovatebot [0] supports this? [0] https://github.com/renovatebot/renovate https://github.com/renovatebot/renovate
  - silverlyra 3y ago
    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 https://docs.renovatebot.com/configuration-options/#enabled
    - Cannabat 3y ago
      Thanks - I was looking in the wrong place in the docs.
- azangru 3y ago
  > this makes Storybook a Big Noise Generator 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.
- lyjackal 3y ago
  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!
- morbicer 3y ago
  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/ https://ladle.dev/ a try, much more lightweight
diegof79 3y ago
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.
mm263 3y ago
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.
- maclockard 3y ago
  What does MSW stand for here? Maybe "Mock Service Worker" https://mswjs.io/ https://mswjs.io/?
  - mm263 3y ago
    Yes, sorry for the confusion
- dsego 3y ago
  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 3y ago
    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 https://github.com/oxidecomputer/console [2]: https://github.com/oxidecomputer/console/blob/main/app/pages/SiloUtilizationPage.tsx https://github.com/oxidecomputer/console/blob/main/app/pages...
unleashit 3y ago
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.
- mm263 3y ago
  > 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 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
  - unleashit 3y ago
    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.
technojunkie 3y ago
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.
- gehen88 3y ago
  Interesting! What would the integration between Storybook and a CMS such as Wordpress look like, ideally? How would you use it?
  - sam98brown 3y ago
    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.
- deleted 3y ago
  [deleted]

86 points by unleashit 3y ago

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/dependabot/dependabot-core/issues/2521 https://github.com/dependabot/dependabot-core/issues/2521

Cannabat 3y ago
I wonder if renovatebot [0] supports this? [0] https://github.com/renovatebot/renovate https://github.com/renovatebot/renovate
- silverlyra 3y ago
  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 https://docs.renovatebot.com/configuration-options/#enabled
  - Cannabat 3y ago
    Thanks - I was looking in the wrong place in the docs.
azangru 3y ago
> this makes Storybook a Big Noise Generator 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.
lyjackal 3y ago
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!
morbicer 3y ago
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/ https://ladle.dev/ a try, much more lightweight

diegof79 3y ago

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.

mm263 3y ago

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.

maclockard 3y ago
What does MSW stand for here? Maybe "Mock Service Worker" https://mswjs.io/ https://mswjs.io/?
- mm263 3y ago
  Yes, sorry for the confusion
dsego 3y ago
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 3y ago
  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 https://github.com/oxidecomputer/console [2]: https://github.com/oxidecomputer/console/blob/main/app/pages/SiloUtilizationPage.tsx https://github.com/oxidecomputer/console/blob/main/app/pages...

unleashit 3y ago

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.

mm263 3y ago
> 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 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
- unleashit 3y ago
  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.

technojunkie 3y ago

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.

gehen88 3y ago
Interesting! What would the integration between Storybook and a CMS such as Wordpress look like, ideally? How would you use it?
- sam98brown 3y ago
  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.
deleted 3y ago
[deleted]