[HN Gopher] Storybook 8
___________________________________________________________________
Storybook 8
Author : unleashit
Score : 44 points
Date : 2024-03-13 20:14 UTC (2 hours ago)
(HTM) web link (storybook.js.org)
(TXT) w3m dump (storybook.js.org)
| Etheryte wrote:
| 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
| Cannabat wrote:
| I wonder if renovatebot [0] supports this?
|
| [0] https://github.com/renovatebot/renovate
| silverlyra wrote:
| 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
| azangru wrote:
| > 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.
| diegof79 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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/p
| ages...
| lowboy wrote:
| 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.
| maclockard wrote:
| What does MSW stand for here? Maybe "Mock Service Worker"
| https://mswjs.io/?
| mm263 wrote:
| Yes, sorry for the confusion
| unleashit wrote:
| 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 wrote:
| > 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. For E2E tests, I usually
| test the whole form.
|
| 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
| technojunkie wrote:
| 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 wrote:
| Interesting! What would the integration between Storybook and a
| CMS such as Wordpress look like, ideally? How would you use it?
___________________________________________________________________
(page generated 2024-03-13 23:00 UTC)