[HN Gopher] Storybook: UI component explorer for front end devel...
___________________________________________________________________
Storybook: UI component explorer for front end developers
Author : defaulty
Score : 111 points
Date : 2021-09-11 16:36 UTC (6 hours ago)
(HTM) web link (storybook.js.org)
(TXT) w3m dump (storybook.js.org)
| timfsu wrote:
| We've been using Storybook for isolated development of state-
| heavy components and it's been a nice productivity booster,
| compared to testing inside the actual app.
|
| As a bonus, the stories that get created live in your codebase
| and can be integrated into several different types of testing -
| jest test suites, visual regression testing, and puppeteer /
| Selenium.
|
| There's certainly an overhead for mocking data properly, but I
| tend to see that as part of the general challenge of testing
| frontend / JS code.
| vinaygaba wrote:
| For anyone interested in this space and wishes something like
| this existed for Android, I got you covered! I open sourced this
| project last year - https://github.com/airbnb/Showkase
| AHappyCamper wrote:
| Storybook is breaking our build. It has Reach Router as a
| dependency. Reach router does not support React 17 - they PR to
| support it has been open for nearly a year!! So this week, we
| were required to upgrade to React 17.0.2 and Storybook broke our
| build because of its dependency of Reach Router. i.e. NOT FUN!!
| toinbis wrote:
| For those looking of component showcase i'd kindly advise to also
| look at https://bit.dev, https://github.com/teambit/bit . It is a
| standalone service that hosts your components, providing each of
| it as a npm package.
|
| You end up developing the components in a separate repo, and in
| your main app repo you install each component as dedicated npm
| package. Those who get excited by `separation of concerns`
| pattern should find this a real joy.
| crooked-v wrote:
| I took a look at that, and it's completely incomprehensible to
| me why I should use it and what actual benefits I get for
| adding all this extra tooling and complexity as compared to
| just having a company monorepo for reusable components.
| csbartus wrote:
| It was a godsend, I always wanted something like this. I've used
| it in around 10 projects over a year (2019-2020j and it broke
| every time, suddenly, from a day to another.
|
| I hope nowadays it's more stable. Personally I've ended up
| rolling my own and it works as a charm, integrated with unit
| tests
| city41 wrote:
| It's been in very active development for the past couple years
| or so. Lately it seems like it's been stabilizing and I'm now
| pretty happy with Storybook.
|
| I agree it's still heavy and when it breaks may god help you.
| But when it works, it's pretty nice. I am really happy with how
| clean stories files can be now, for example:
| https://github.com/city41/smaghetti/blob/main/src/components...
| alberth wrote:
| I wonder how many folks use Storybook primary as a component
| library or primarily for its regression testing functionality.
| d0m3 wrote:
| and for development in isolation
| Rapzid wrote:
| I've had a lot of success with Storybook as a development aid on
| a large legacy application where VueJS is slowly taking over.
|
| Will use it for building components of any complexity and size
| under "screen" leaving just the "last mile" to work out in the
| legacy app. Have it configured so the API can be hit and/or pre-
| recorded API calls can be used.
|
| It has made cross-browser testing and fixes(looking at you
| Safari) quite quick. Leaned on it for large CSS/SCSS refactors
| and style updates.
|
| Could something like this be written from scratch? Sure, but why?
| It's a set of conventions already in place and documented.
| Setting it up was a breeze and creating a "story" can be just
| about as simple or complicated as you want.
| ratww wrote:
| _> Could something like this be written from scratch? Sure, but
| why?_
|
| There's lots of reasons: it is simple enough that it can be
| done in an afternoon. It is a great learning exercise,
| especially for junior devs. It has hard dependencies on React,
| Webpack, Babel, Reach Router, PostCSS that can cause you
| project to break if you're not careful, not to mention the
| bloat. If you use Vue, Typescript or other bundler you have a
| lot of redundancy now, and possibly some quirks due to
| incompatibilities between bundlers. Also there's UI/UX quirks.
| And it's harder to customise than a plain page.
|
| I'm all for reusing other projects and saving time, but the
| automatic reflex we have of automatically adding dependencies
| without considering the downsides becomes very problematic in
| non-trivial projects.
| Rapzid wrote:
| > There's lots of reasons
|
| Boy howdy. Of course, every NIH project that turns into a
| huge wasted time sink has a rationalization chock-a-block
| with _reasons_.
|
| It depends. YMMV. etc.
| [deleted]
| butz wrote:
| For a bit more simple alternative I might suggest Fractal -
| https://fractal.build . While it doesn't have so much knobs and
| whistles as StorybookJS, it's easier to set up and get running
| for smaller projects.
| lloydatkinson wrote:
| Looks very interesting. The docs for it appear to be using
| VuePress.
|
| So I checked it out and it's not clear to me how if it all it
| supports different frameworks. All the examples seem to be for
| handlebars based components not actual components in the JS
| framework sense of the word.
| bilalq wrote:
| I feel like storybook is more complicated than it needs to be,
| but it's still valuable. I've used it with success in the past.
| It essentially gives you a standardized way to build out a fully
| implemented design system rather than just the spec for one in
| something like Figma.
|
| That said, I've really wanted a good alternative for React Native
| that's similar. Storybook ostensibly works there, but it's more
| than a little clunky.
| betoharres wrote:
| as react-native dev, storybook feels like pilling a bunch of
| cards, you don't want to have to mess around with your base
| configuration, it's the worst. I've looked into alternatives
| multiple times, the closest I got is react-cosmos.
| koboll wrote:
| After using Storybook for a couple years at work, I've soured on
| it. The Canvas / Docs distinction is weird and confusing. There
| are lots of poorly documented aspects (did you know pressing "S"
| causes the sidebar to disappear without any sort of visible way
| to open it again?). The controls are awkward to build complicated
| components around.
|
| 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. That's it. Storybook is just
| a heavy, complicated, awkward set of abstraction layers over that
| very simple core experience.
| reidjs wrote:
| Thank you! My team was looking for a tool like this and
| storybook was the only one I knew about. I linked to it in
| slack as an option and the people delegated to implementing the
| component library hopped on board. After looking at how complex
| it was I knew it would be a terrible idea for what we needed:
| something very basic. I tried to veer them away from it. I even
| rolled my own component showcase like you were talking about
| before they put storybook in. No luck, they implemented
| storybook and after a couple months the people delegated to
| roll it out lost interest in it.
|
| We still use it, because management doesn't like the idea of
| how much time we've already sunk into it. Storybook is a
| nightmare to maintain and train devs on.
| Waterluvian wrote:
| If anyone needs to be able to not fall for the sunk cost
| fallacy, it's management. That's rather concerning.
| brundolf wrote:
| > 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 wrote:
| How useful is the knob thingy anyway? The devs using this
| would be looking at the code anyway and all you need is
| documents your props properly and let hot reload takes care
| of it
| brundolf wrote:
| 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.
|
| 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?
| stevenpetryk wrote:
| Not to mention that every time you start Storybook, it seems to
| compile itself. At Aha! we use it for hosting our component
| library (which are web components written in Stencil, and which
| don't require webpack to be built), and even then, we spend
| about 20-30s waiting for webpack to startup and compile
| everything inside of Storybook.
| lloydatkinson wrote:
| 1000% this. It's a nightmare and the maintainers have been less
| than receptive in the past. The fact it's built on react which
| apparently means it needs a million react dependencies. Fair
| enough but when the dependencies break your eg Vue app because
| of the deeply flawed way NPM resolves dependencies and screws
| things up in mysterious and frustrating ways, it's just a non
| starter.
|
| Writing documentation for the components is a weird mix of JSX,
| interpolated strings, and markdown. Often overlapping,
| confusing, and conflicting ways of doing the same thing.
| type0 wrote:
| It is such an over-engineered piece of crap that I regret
| spending so much time trying to use it. Use a templating
| language of your choice and some simple npm and Gulp scripts to
| build html and you'll be so much better off.
| dimal wrote:
| My initial reaction to this was to think, "heresy!" SB has been
| amazing for developing components in isolation and setting up a
| design system. Then I thought it over. Yeah, the great thing is
| implementing a design system and developing components in
| isolation, not SB. And it's not hard to set up a bespoke system
| to develop components in isolation. Setting up custom tooling
| in SB was possible, but was certainly made a lot harder by the
| fact that I had to jump through their hoops. And then I think
| about how many times they've changed the format for defining a
| component story over the years and I start to get annoyed.
| Yeah, next time around I might just roll my own.
|
| Oh, and that "S" thing. Yeah, I hit that. Grr.
| felixfbecker wrote:
| Don't forget when you wanna upgrade Webpack but you can't
| because Storybook still only works with the old version
| months in
| nkozyra wrote:
| Agreed, I found it heavy weight, if a noble idea.
|
| Isolated components that can be tested under different
| scenarios is a great idea, but I've found it uncovered almost
| no bugs and served almost exclusively as a showcase.
| gtm1260 wrote:
| Hard agree. The overhead of fixing all the issues with the
| Storybook versions of components made a lot of people just skip
| it all together.
| NaN1352 wrote:
| I agree it's fairly easy nowadays to maintain a "live" demo of
| your components with Vue or React.
|
| It's useful also to keep semi static mockups when you do
| revisions on a homepage for example (as the html/css guy) so
| you can preview something with the team.
|
| And nowadays you have simple Markdown + Vue plugins for eg.
| Vite, so you could even write your styleguide / demo as .md
| files.
| gedy wrote:
| > The Canvas / Docs distinction is weird and confusing.
|
| Yes. While I otherwise like Storybook, the addition of docs
| along side canvas is not clear what the purpose is. Incremental
| way to introduce a new default? Very confusing to have both
| tabs available at same time.
| roberttod wrote:
| Completely agree. I've seen Storybook used at 2 different
| companies now, and always found it confusing and the docs
| incomplete. Developers get excited about auto-generating docs
| but in the end it's nowhere near as good as just setting up a
| static page of rendered components with hand-written
| documentation alongside (as another sibling comment suggests).
| sbacic wrote:
| My main issue with Storybook is how much trouble it is to get
| everything else running with it. Need next-image? Routing? i18n
| on demand?
|
| Tough luck - you'll need to implement it for both the app you're
| building and Storybook. And sometimes implementing it in the app
| itself is the _easy_ part. Nevertheless, I feel like it does
| improve the dev experience and intend to keep using it. You just
| need to know when to cut your losses and not use it for more
| complex use-cases.
| faeyanpiraat wrote:
| I have no idea what this does, their intro video is like a
| generic marketing mumbo jumbo, skimming the docs doesn't help
| either.
___________________________________________________________________
(page generated 2021-09-11 23:00 UTC)