[brundolf]

> Consider just rolling your own component showcase. You can do it in a day and probably get a much cleaner and more straightforward static site out - all you really need is a sidebar and then display areas hooked up to buttons.

It gets more complicated when you want to let people play with the component's props/parameters from within the GUI. I hand-rolled one of these once and was able to use a library that scraped prop info from our React PropTypes automatically and put it into a JSON file, but it was fiddly and eventually broke when we started using TypeScript. I don't know if something better exists now (or how Storybook solves this), but it's a hard problem. And it's not just about gathering metadata: you have to dynamically set aside a piece of state for each prop that hooks in accordingly. Sometimes, like with value/onChange, you need to hook two different props together into the same piece of state. Etc.

I suppose you could just hand-code all the controls for each component, but at that point it seems like it would be more trouble than it's worth (especially the ongoing maintenance burden every time one of the base components changes)

[nsonha]

How useful is the knob thingy anyway? The devs using this would be looking at the code anyway and all you need is to document your props properly and let hot reload takes care of it

[brundolf]

It's the main benefit IMO. It's great for quickly seeing what a component can do, but it's also fantastic for testing the different features. You can click through all the states (and transition between them), mix and match every permutation you can think of to make sure they all work together, etc. I've discovered several bugs this way in the past by selecting an odd combination of flags and finding out they break when used together.

Tbh without the ability to play with props I wouldn't even bother with a storybook-like interface. As you say, they probably have the code (and all its comments) in front of them, so what's the point of pretty documentation at that point?

[runarberg]

I’ve found that with semantic prop names + values and good documentation there is no real need for developers to play with the components. E.g. if you have a boolean property called `filled` on a button, and the mock has a filled button, a junior developer can easily figure out how to get the button to look according to the mock without any need to open the story book and play with the knobs.

The only benefits for the knobs I see is to provide a nice interface for the designers to scrutinize the system on an atomic level. However I am not a designer so I don’t know how valuable it is for them to do that through story book over exploring the actual app or a custom showcase. And if the benefits to the designers are only marginal, you have to ask if it is worth it for devs to maintain the storybook interface.

[brundolf]

When I used one we didn't have a designer at all, much less neatly-organized mockups.

But even if we had, we might not have discovered things like "oh, if you have the modal set to show a close button in the corner and also give it a really long title and make the window narrow then the button gets awkwardly pushed to the next line". The kind of stuff that mockups often don't cover, but real-world users might encounter some day.