12 ms·

Storybook: UI component explorer for front end developers

197 points by defaulty 5y ago

butz 5y ago
For a bit more simple alternative I might suggest Fractal - https://fractal.build 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 5y ago
  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.
- brylie 5y ago
  Fractal doesn't seem simple in terms of dependencies: https://github.com/frctl/fractal/blob/main/package.json https://github.com/frctl/fractal/blob/main/package.json Is there a similar project without, e.g. the React dependencies for projects that might not include React?
csbartus 5y ago
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 5y ago
  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/editor/Editor/SaveButton/SaveButton.stories.tsx https://github.com/city41/smaghetti/blob/main/src/components...
deleted 5y ago
[deleted]
koboll 5y ago
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.
- nkozyra 5y ago
  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.
- reidjs 5y ago
  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 5y ago
    If anyone needs to be able to not fall for the sunk cost fallacy, it’s management. That’s rather concerning.
- NaN1352 5y ago
  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.
vinaygaba 5y ago
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 https://github.com/airbnb/Showkase
alberth 5y ago
I wonder how many folks use Storybook primary as a component library or primarily for its regression testing functionality.
- d0m3 5y ago
  and for development in isolation
- crubier 5y ago
  Both ! That’s the cool thing about it.
Rapzid 5y ago
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 5y ago
  > 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 5y ago
    > 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.
    - ratww 5y ago
      The fact you tried to rudely and defensively turn my "consider the downsides" (that you actually asked for!) into "rationalization chock-a-block" tells me it doesn't really "depend" for you. If you think I'm taking a side by merely pointing out something has downsides: you're projecting. Neither reusing nor building from scratch should be automatic decisions taken without consideration.
AHappyCamper 5y ago
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 5y ago
For those looking of component showcase i'd kindly advise to also look at https://bit.dev https://bit.dev, https://github.com/teambit/bit 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 5y ago
  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.
- crubier 5y ago
  I’m very big on the monorepo approach and it’s benefits so that will be a pass for me. I like to be able to modify my component and immediately (one hot reload) be able to modify a site of use of this component one second later. Having 1+min of npm publish and npm install get in the way is not what I want. But I can understand the utility for some different use cases.
betoharres 5y ago
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.
bilalq 5y ago
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.
sbacic 5y ago
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.
- steve_adams_86 5y ago
  I tried getting it going with linaria last year and just about lost my marbles. I think it was the deepest webpack rabbit hole I’ve ever gone down. I love the idea of SB but haven’t come across a project where it actually works with the components.
- MisterSandman 5y ago
  Getting Strapi/GraphQL working on it for a sample comonent was so difficult, it took us longer than the actual Stapi/GraphQL setup and we gave up.
faeyanpiraat 5y ago
I have no idea what this does, their intro video is like a generic marketing mumbo jumbo, skimming the docs doesn't help either.
- beebeepka 5y ago
  You are not alone. I guess it's of those things one need to see before giving any judgement. I spent 5 minutes on their website and the best I could gather was that it's not a React only thing. Definitely sounded like it. In my experience the react crowd is more likely to use other people's components instead of rolling their own, even when it barely makes sense or is counter productive
timfsu 5y ago
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.
- Rapzid 5y ago
  Yeah, I like having stories for the different states setup on those types of components too. Our actual app takes seconds to refresh in a development mode and then getting the components back into those states would take extra time, or require extra tooling anyway. Even with HMR some changes will require reloads or component state resets. For complex data from the API I have actually added tooling very similar to VCR that allows me to record API req/responses from the backend into "cassette" JSON files that can be "loaded" on a per-story basis. Don't use it for everything, but it has worked out very well where it has been used.
  - depaulagu 5y ago
    What's the name of the "VCR" tool?
    - Rapzid 5y ago
      Custom code I wrote built on top of fetch-mock.
      - depaulagu 5y ago
        Is it public?
ilrwbwrkhv 5y ago
Storybook is too complex and hard to understand. It adds to the growing frontend complexity. A component system is very useful though. Wish something simpler was available.
- crubier 5y ago
  I used to complain about this several month/years back, but it don’t think it’s the case anymore with the new API. Have you tried it recently ? It’s pretty simple to add decorators and data loaders if you need customization. It is not zero-cost though of course but I find the ROI to be closer to 10x than to 0.
emadabdulrahim 5y ago
I use Storybook at work, and while it works ok for the most part, it wouldn't be my first choice to creating a UI component library. Most of what it offers is IMO not that important. And it's quite bloated at this point. I also think that building a bespoke environment for building components in isolation isn't that hard and is probably worth doing if the company is thinking long term. I'll certainly be doing that in the future.
lmeyerov 5y ago
We had a tricky UI state component recently -- a sharing panel complete with notifications, RBAC, entitlements, loading indicators, and error handlers -- which was a religious moment for us on Storybook. A way to specify the expected states of interest and being able to click through them helps a lot!
fma 5y ago
For those who are using Storybook: Do you develop your component in storebook first? Then implement on your actual page? Also are you able to leverage it for automation test? I.e. if you have a photo gallery...have a state where it has 0 photos, 1, 2.. and have some UI automation test (i.e. Selenium) run against it? If not do you have any recommendations for something like this kind of use case?
- crubier 5y ago
  Yes we develop on storybook first, it’s a bit like TDD but for UI. And yes, we use Chromatic (their hosted service) and it’s been hugely beneficial, I would say a 10x ROI. Super useful for visual regression testing, sharing with non technical people in the org, etc...) My recommendation in this field is Storybook. It’s the best tool for this use case. We also use Cypress for integration tests and heat for unit tests.
  - fma 5y ago
    Hi - Thanks for your reply! Glad to hear of success amid a sea of negative experiences. I tried looking up "Heat" but was not able to find a framework/util. Could you send me the link please? It looks like the testing feature of Chromatic is to take screenshots of the deployed component and visually compare them? So there's literally no code writing if comparing one commit to the next.
    - crubier 5y ago
      Sorry, autocorrect transformed « Jest » to « Heat ». I meant « Jest » And yes you are right about Chromatic. It informs you directly in GitHub PRs about the number of stories that changed, visually or at the dom level. And has a nice UI to review changes visually in a click.
darepublic 5y ago
There should be adjustable knobs atop a figma design. Just make a component withKnobs that wraps the component on a parent which passes it's knob controlled state to child
sktrdie 5y ago
I think what most developers use Storybook for is development in isolation which is essentially what TDD is about. In fact what we end up doing with Storybook is that we create the "stories" (literally .stories.ts files) that renders each component with a specific permutation of props. However this is pretty much a copy of the .test.ts file we write for the component itself - so many times it's literally doing pretty much the same stuff. I find it so weird that in 2021 we don't have a way to just render our test files (which essentially is using some server-side dom abstraction) also to a browser so we can view the component and develop against it. Then we wouldn't need storybook or story files that describe how a component is rendered - that's the test file responsibility.
- DerJacques 5y ago
  Have you looked into Cypress (https://www.cypress.io/ https://www.cypress.io/)? If I understand you correctly, it may actually do what you are describing here.
  - stepbeek 5y ago
    The combination of cypress and something like percy (https://percy.io/ https://percy.io/) has made me completely lose interest in testing components independently. The components that make up a UI are an implementation concern that I don't really care about testing independently. I can write automated tests to verify that a component in a relevant context still functions, and can have a check at PR time to verify that the UI hasn't changed unexpectedly.
  - sktrdie 5y ago
    Yes cool but I want to be able to run the test in command line like I currently do with Jest where everything is mocked (even DOM) so it runs super fast (during CI) but then I also just wanna run the test in a browser for my development workflow. Running all tests in Cypress would result in slow CIs.
- jabbawookiees 5y ago
  Have you heard of the storyshots addon? I pretty much ignore its output but I've found it a useful sanity check to see that everything at least renders without errors without any additional effort. I no longer make simple render tests when a story suffices. https://github.com/storybookjs/storybook/tree/main/addons/storyshots/storyshots-core https://github.com/storybookjs/storybook/tree/main/addons/st...
brendanmc6 5y ago
I'm on my second team that's tried and failed to implement this (well, I consider the current setup a failure, the leads apparently don't?). Extra work for no benefit, broken builds, type and lint ignores everywhere, demos always out of date or incomplete. If your designers are skilled and organized, you don't need this. "But my team doesn't have skilled or organized designers!" ... well then you probably have bigger problems, messing with Storybook is the last thing you want.
dmitriid 5y ago
So, so many people in the comments saying "good to design components in isolation". Why would design your components in isolation? Do they never interact with each other? Appear next to each other on a page? Participate in a layout? This is my main gripe with Storybook in particular and any design system and design system tool in general: they never consider how components work together and force into a mindset of just documenting separate components complete isolation.
- ojkelly 5y ago
  Build* in isolation the same way we chunk up server side code and test that in isolation. These are unit tests for UI. Storybook gives you the framework to run them. Add something like cypress on top and you have the whole testing loop. Making and updating the components in isolation reduces how much you need to reason about when building highly composable components. The higher up you go (ie more composition) the less you can do in isolation. But this is only building, you should design with as full an understanding of the rest of your components. Behaviours need to match, style needs to be consistent. You don’t build a whole program at once, in the same way you can’t build a whole UI at once. At some point, you focus in on one area. This because exponentially helpful when you team grows to a size larger than one.
  - dmitriid 5y ago
    > Making and updating the components in isolation reduces how much you need to reason about when building highly composable components. How do you know they are composable if you make and update them in isolation?
- crubier 5y ago
  Do you never use unit tests or integretion tests ? When you are building an app bottom up, you will be working on components “in isolation” 100% of the time all the way up. Integration between components is just part of the behavior of a component higher in the hierarchy. You can make stories of larger components assembling smaller components, entire pages, and even your entire app! It’s been very valuable for my teams, especially coupled with Chromatic.
montag 5y ago
Storybook seems way overengineered in my experience. Most small teams will be better off building their own simple tool.
crubier 5y ago
I’ve used storybook for 4-5 years (basically since day one) in teams of 1-15 devs and I’d say it’s a must have for any serious react app with 3+ full time developers. It has its rough edges sure but the ROI is 10x nonetheless in my experiences. Advantages - Testing components in isolation forces some good practices and allows to keep the codebase in check by encouraging good practices (limited coupling of unrelated parts of the codebase - It’s super productive because it is both a form of unit tests, useful during development of UX in « TDD mode », and a very good documentation of your UI components. It greatly reduces the effort needed for both these aspects. - For DX, the hot reload is generally faster in storybook than in the App (except if you use vite/snowpack in your app, so far..) because reloading a single component is faster than reloading the whole app and its state. In a large CRA our hot reload could sometimes take up 1min in complex cases, while storybook was taking 3s. - Coupled with Chromatic (their hosted platform) and its GitHub integration it makes QA and visual regression testing a joy, 10x faster than alternatives, I really recommend that. - It allows to share/iterate easily your ongoing developments with non-tech people in your organisation at early stage. A very good bridge between Figma and the final UI. A good support during Daily meetings about UI, just share the deployed story url to ask for feedback. Drawbacks - It has its own Webpack config. So if you have a custom Webpack config in your app (don’t do that anyway, unless absolutely necessary) then be prepared to duplicate the customizations in your storybook config - Global React Contexts needs to be duplicated in your storybook config and, if necessary, configured for individual stories. For example if your signup button changes based on an Auth status stored in a global context, then you will have to use Story.parameters to customize the content of the Auth context. - We had a couple instances where storybook was the limiting factor for us to embrace some new/fancy tech, like yarn v2 or service worker. However maybe that’s a good litmus test: things that storybook support are state of the art JS and generally safe to use. Things that storybook does not support out of the box will cause you problems with other tools anyway: if it’s not storybook, some other tool like Cypress, Jest, Next, or some browsers will cause you trouble with your “shiny new tech” - It can be slow to startup. We had a storybook with 300+ complex stories and it took 5min to startup and 10min to build in the CI - It had some API changes/ migration pains a couple years back. However I think the new API is very good and will last a long time so this is behind. Overall I definitely advocate to use storybook, especially with Chromatic, the ROI is 10x. If you find yourself limited by it in 2021 despite configuring it, maybe question your own tech stack. Don’t try to implement your own storybook copycat (we had a colleague develop an alternative https://github.com/remorses/vitro https://github.com/remorses/vitro , but i think it was not worth the effort) If you want to see a state of the art monorepo in NextJS that uses storybook extensively with some customizations, check https://github.com/Labelflow/labelflow/ https://github.com/Labelflow/labelflow/

197 points by defaulty 5y ago

butz 5y ago

For a bit more simple alternative I might suggest Fractal - https://fractal.build 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 5y ago
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.
brylie 5y ago
Fractal doesn't seem simple in terms of dependencies: https://github.com/frctl/fractal/blob/main/package.json https://github.com/frctl/fractal/blob/main/package.json Is there a similar project without, e.g. the React dependencies for projects that might not include React?

csbartus 5y ago

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 5y ago
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/editor/Editor/SaveButton/SaveButton.stories.tsx https://github.com/city41/smaghetti/blob/main/src/components...

deleted 5y ago

[deleted]

koboll 5y ago

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.

nkozyra 5y ago
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.
reidjs 5y ago
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 5y ago
  If anyone needs to be able to not fall for the sunk cost fallacy, it’s management. That’s rather concerning.
NaN1352 5y ago
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.

vinaygaba 5y ago

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 https://github.com/airbnb/Showkase

alberth 5y ago

I wonder how many folks use Storybook primary as a component library or primarily for its regression testing functionality.

d0m3 5y ago
and for development in isolation
crubier 5y ago
Both ! That’s the cool thing about it.

Rapzid 5y ago

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 5y ago
> 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 5y ago
  > 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.
  - ratww 5y ago
    The fact you tried to rudely and defensively turn my "consider the downsides" (that you actually asked for!) into "rationalization chock-a-block" tells me it doesn't really "depend" for you. If you think I'm taking a side by merely pointing out something has downsides: you're projecting. Neither reusing nor building from scratch should be automatic decisions taken without consideration.

AHappyCamper 5y ago

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 5y ago

For those looking of component showcase i'd kindly advise to also look at https://bit.dev https://bit.dev, https://github.com/teambit/bit 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 5y ago
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.
crubier 5y ago
I’m very big on the monorepo approach and it’s benefits so that will be a pass for me. I like to be able to modify my component and immediately (one hot reload) be able to modify a site of use of this component one second later. Having 1+min of npm publish and npm install get in the way is not what I want. But I can understand the utility for some different use cases.

betoharres 5y ago

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.

bilalq 5y ago

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.

sbacic 5y ago

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.

steve_adams_86 5y ago
I tried getting it going with linaria last year and just about lost my marbles. I think it was the deepest webpack rabbit hole I’ve ever gone down. I love the idea of SB but haven’t come across a project where it actually works with the components.
MisterSandman 5y ago
Getting Strapi/GraphQL working on it for a sample comonent was so difficult, it took us longer than the actual Stapi/GraphQL setup and we gave up.

faeyanpiraat 5y ago

I have no idea what this does, their intro video is like a generic marketing mumbo jumbo, skimming the docs doesn't help either.

beebeepka 5y ago
You are not alone. I guess it's of those things one need to see before giving any judgement. I spent 5 minutes on their website and the best I could gather was that it's not a React only thing. Definitely sounded like it. In my experience the react crowd is more likely to use other people's components instead of rolling their own, even when it barely makes sense or is counter productive

timfsu 5y ago

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.

Rapzid 5y ago
Yeah, I like having stories for the different states setup on those types of components too. Our actual app takes seconds to refresh in a development mode and then getting the components back into those states would take extra time, or require extra tooling anyway. Even with HMR some changes will require reloads or component state resets. For complex data from the API I have actually added tooling very similar to VCR that allows me to record API req/responses from the backend into "cassette" JSON files that can be "loaded" on a per-story basis. Don't use it for everything, but it has worked out very well where it has been used.
- depaulagu 5y ago
  What's the name of the "VCR" tool?
  - Rapzid 5y ago
    Custom code I wrote built on top of fetch-mock.
    - depaulagu 5y ago
      Is it public?

ilrwbwrkhv 5y ago

Storybook is too complex and hard to understand. It adds to the growing frontend complexity. A component system is very useful though. Wish something simpler was available.

crubier 5y ago
I used to complain about this several month/years back, but it don’t think it’s the case anymore with the new API. Have you tried it recently ? It’s pretty simple to add decorators and data loaders if you need customization. It is not zero-cost though of course but I find the ROI to be closer to 10x than to 0.

emadabdulrahim 5y ago

I use Storybook at work, and while it works ok for the most part, it wouldn't be my first choice to creating a UI component library. Most of what it offers is IMO not that important. And it's quite bloated at this point. I also think that building a bespoke environment for building components in isolation isn't that hard and is probably worth doing if the company is thinking long term. I'll certainly be doing that in the future.

lmeyerov 5y ago

We had a tricky UI state component recently -- a sharing panel complete with notifications, RBAC, entitlements, loading indicators, and error handlers -- which was a religious moment for us on Storybook. A way to specify the expected states of interest and being able to click through them helps a lot!

fma 5y ago

For those who are using Storybook: Do you develop your component in storebook first? Then implement on your actual page? Also are you able to leverage it for automation test? I.e. if you have a photo gallery...have a state where it has 0 photos, 1, 2.. and have some UI automation test (i.e. Selenium) run against it? If not do you have any recommendations for something like this kind of use case?

crubier 5y ago
Yes we develop on storybook first, it’s a bit like TDD but for UI. And yes, we use Chromatic (their hosted service) and it’s been hugely beneficial, I would say a 10x ROI. Super useful for visual regression testing, sharing with non technical people in the org, etc...) My recommendation in this field is Storybook. It’s the best tool for this use case. We also use Cypress for integration tests and heat for unit tests.
- fma 5y ago
  Hi - Thanks for your reply! Glad to hear of success amid a sea of negative experiences. I tried looking up "Heat" but was not able to find a framework/util. Could you send me the link please? It looks like the testing feature of Chromatic is to take screenshots of the deployed component and visually compare them? So there's literally no code writing if comparing one commit to the next.
  - crubier 5y ago
    Sorry, autocorrect transformed « Jest » to « Heat ». I meant « Jest » And yes you are right about Chromatic. It informs you directly in GitHub PRs about the number of stories that changed, visually or at the dom level. And has a nice UI to review changes visually in a click.

darepublic 5y ago

There should be adjustable knobs atop a figma design. Just make a component withKnobs that wraps the component on a parent which passes it's knob controlled state to child

sktrdie 5y ago

I think what most developers use Storybook for is development in isolation which is essentially what TDD is about. In fact what we end up doing with Storybook is that we create the "stories" (literally .stories.ts files) that renders each component with a specific permutation of props. However this is pretty much a copy of the .test.ts file we write for the component itself - so many times it's literally doing pretty much the same stuff. I find it so weird that in 2021 we don't have a way to just render our test files (which essentially is using some server-side dom abstraction) also to a browser so we can view the component and develop against it. Then we wouldn't need storybook or story files that describe how a component is rendered - that's the test file responsibility.

DerJacques 5y ago
Have you looked into Cypress (https://www.cypress.io/ https://www.cypress.io/)? If I understand you correctly, it may actually do what you are describing here.
- stepbeek 5y ago
  The combination of cypress and something like percy (https://percy.io/ https://percy.io/) has made me completely lose interest in testing components independently. The components that make up a UI are an implementation concern that I don't really care about testing independently. I can write automated tests to verify that a component in a relevant context still functions, and can have a check at PR time to verify that the UI hasn't changed unexpectedly.
- sktrdie 5y ago
  Yes cool but I want to be able to run the test in command line like I currently do with Jest where everything is mocked (even DOM) so it runs super fast (during CI) but then I also just wanna run the test in a browser for my development workflow. Running all tests in Cypress would result in slow CIs.
jabbawookiees 5y ago
Have you heard of the storyshots addon? I pretty much ignore its output but I've found it a useful sanity check to see that everything at least renders without errors without any additional effort. I no longer make simple render tests when a story suffices. https://github.com/storybookjs/storybook/tree/main/addons/storyshots/storyshots-core https://github.com/storybookjs/storybook/tree/main/addons/st...

brendanmc6 5y ago

I'm on my second team that's tried and failed to implement this (well, I consider the current setup a failure, the leads apparently don't?). Extra work for no benefit, broken builds, type and lint ignores everywhere, demos always out of date or incomplete. If your designers are skilled and organized, you don't need this. "But my team doesn't have skilled or organized designers!" ... well then you probably have bigger problems, messing with Storybook is the last thing you want.

dmitriid 5y ago

So, so many people in the comments saying "good to design components in isolation". Why would design your components in isolation? Do they never interact with each other? Appear next to each other on a page? Participate in a layout? This is my main gripe with Storybook in particular and any design system and design system tool in general: they never consider how components work together and force into a mindset of just documenting separate components complete isolation.

ojkelly 5y ago
Build* in isolation the same way we chunk up server side code and test that in isolation. These are unit tests for UI. Storybook gives you the framework to run them. Add something like cypress on top and you have the whole testing loop. Making and updating the components in isolation reduces how much you need to reason about when building highly composable components. The higher up you go (ie more composition) the less you can do in isolation. But this is only building, you should design with as full an understanding of the rest of your components. Behaviours need to match, style needs to be consistent. You don’t build a whole program at once, in the same way you can’t build a whole UI at once. At some point, you focus in on one area. This because exponentially helpful when you team grows to a size larger than one.
- dmitriid 5y ago
  > Making and updating the components in isolation reduces how much you need to reason about when building highly composable components. How do you know they are composable if you make and update them in isolation?
crubier 5y ago
Do you never use unit tests or integretion tests ? When you are building an app bottom up, you will be working on components “in isolation” 100% of the time all the way up. Integration between components is just part of the behavior of a component higher in the hierarchy. You can make stories of larger components assembling smaller components, entire pages, and even your entire app! It’s been very valuable for my teams, especially coupled with Chromatic.

montag 5y ago

Storybook seems way overengineered in my experience. Most small teams will be better off building their own simple tool.

crubier 5y ago

I’ve used storybook for 4-5 years (basically since day one) in teams of 1-15 devs and I’d say it’s a must have for any serious react app with 3+ full time developers. It has its rough edges sure but the ROI is 10x nonetheless in my experiences. Advantages - Testing components in isolation forces some good practices and allows to keep the codebase in check by encouraging good practices (limited coupling of unrelated parts of the codebase - It’s super productive because it is both a form of unit tests, useful during development of UX in « TDD mode », and a very good documentation of your UI components. It greatly reduces the effort needed for both these aspects. - For DX, the hot reload is generally faster in storybook than in the App (except if you use vite/snowpack in your app, so far..) because reloading a single component is faster than reloading the whole app and its state. In a large CRA our hot reload could sometimes take up 1min in complex cases, while storybook was taking 3s. - Coupled with Chromatic (their hosted platform) and its GitHub integration it makes QA and visual regression testing a joy, 10x faster than alternatives, I really recommend that. - It allows to share/iterate easily your ongoing developments with non-tech people in your organisation at early stage. A very good bridge between Figma and the final UI. A good support during Daily meetings about UI, just share the deployed story url to ask for feedback. Drawbacks - It has its own Webpack config. So if you have a custom Webpack config in your app (don’t do that anyway, unless absolutely necessary) then be prepared to duplicate the customizations in your storybook config - Global React Contexts needs to be duplicated in your storybook config and, if necessary, configured for individual stories. For example if your signup button changes based on an Auth status stored in a global context, then you will have to use Story.parameters to customize the content of the Auth context. - We had a couple instances where storybook was the limiting factor for us to embrace some new/fancy tech, like yarn v2 or service worker. However maybe that’s a good litmus test: things that storybook support are state of the art JS and generally safe to use. Things that storybook does not support out of the box will cause you problems with other tools anyway: if it’s not storybook, some other tool like Cypress, Jest, Next, or some browsers will cause you trouble with your “shiny new tech” - It can be slow to startup. We had a storybook with 300+ complex stories and it took 5min to startup and 10min to build in the CI - It had some API changes/ migration pains a couple years back. However I think the new API is very good and will last a long time so this is behind. Overall I definitely advocate to use storybook, especially with Chromatic, the ROI is 10x. If you find yourself limited by it in 2021 despite configuring it, maybe question your own tech stack. Don’t try to implement your own storybook copycat (we had a colleague develop an alternative https://github.com/remorses/vitro https://github.com/remorses/vitro , but i think it was not worth the effort) If you want to see a state of the art monorepo in NextJS that uses storybook extensively with some customizations, check https://github.com/Labelflow/labelflow/ https://github.com/Labelflow/labelflow/