by defaulty on 9/11/21, 4:36 PM with 86 comments
by koboll on 9/11/21, 6:37 PM
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.
by sktrdie on 9/12/21, 2:35 AM
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.
by sbacic on 9/11/21, 9:47 PM
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.
by timfsu on 9/11/21, 10:27 PM
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.
by emadabdulrahim on 9/12/21, 1:13 AM
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.
by butz on 9/11/21, 7:17 PM
by vinaygaba on 9/11/21, 6:43 PM
by csbartus on 9/11/21, 6:23 PM
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
by toinbis on 9/11/21, 8:35 PM
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.
by AHappyCamper on 9/11/21, 8:34 PM
by bilalq on 9/11/21, 9:07 PM
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.
by fma on 9/12/21, 1:58 AM
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?
by Rapzid on 9/11/21, 7:44 PM
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.
by brendanmc6 on 9/12/21, 2:36 AM
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.
by alberth on 9/11/21, 6:48 PM
by dmitriid on 9/12/21, 5:51 AM
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.
by crubier on 9/12/21, 7:48 AM
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 , 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/
by ilrwbwrkhv on 9/12/21, 12:15 AM
A component system is very useful though. Wish something simpler was available.
by lmeyerov on 9/12/21, 1:52 AM
by betoharres on 9/11/21, 8:49 PM
by darepublic on 9/12/21, 2:26 AM
by faeyanpiraat on 9/11/21, 10:23 PM
by montag on 9/12/21, 6:40 AM