I was pretty excited to add storybook to my project, but after setting up my basic components like buttons and moving on to higher level components that render slices of state using selectors … I have regrets.
Is it me or is it really hard to ‘storybook-i-fy’ react components using selectors? I found this tutorial on the Storybook site and it looks like the preferred pattern is to duplicate your store in your storybook file? That can’t be right, can it?
Someone talk me out of taking Storybook out back and uninstalling it from my repo.
Also, storybook is shit. Use… that drop in replacement that’s name escapes me but is 1000x better
hahaha I really want to know what you’re talking about!
Ladle?
Hated it every time I used it in every codebase. Dogshit APIs that suddenly change dramatically every major version
Can’t talk you out of it, every job that requires me to use storybook was absolute garbage. It led to code duplication, high maintenance cost, and eventually even product management agreeing to not update storybook because it slowed down development.
I use storybook as a tool to organise and document my component library/design system (buttons, cards, typography, colours, etc) and have never had any issues. I’d stick to using it for low-level components.
I worked on a team that did, and it was the second-worst application I’ve ever touched.
You should only use storybook if you are going to share components across devs/projects (+ learning ofc).
I don’t know why you’d duplicate the store. Just write centralized mock constructors once and use them for both storybook and tests. Ideally test the storybook components, so they always stay up to date with changes, but that was relatively new when I used it a couple years ago so I don’t know if they’ve ironed out the kinks yet.
Stories are like tests. You need to mock your stores if you want to isolate your stories. Just like how you mock HTTP APIs or database connections when writing tests. This is the cost of writing testable code.
