this post was submitted on 10 Sep 2023
16 points (100.0% liked)

Programming

17476 readers
261 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]



founded 1 year ago
MODERATORS
 

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.

top 10 comments
sorted by: hot top controversial new old
[–] [email protected] 4 points 1 year ago

Hated it every time I used it in every codebase. Dogshit APIs that suddenly change dramatically every major version

[–] [email protected] 4 points 1 year ago (2 children)

Also, storybook is shit. Use... that drop in replacement that's name escapes me but is 1000x better

[–] WheeGeetheCat 3 points 1 year ago

hahaha I really want to know what you're talking about!

[–] bbigras 1 points 1 year ago
[–] [email protected] 3 points 1 year ago

Your services, that your components, use need to be mockable. Then you can reuse your components in storyboard with mocked interactions and in your productive app with actual service interactions. That way you can also write tests for them.

[–] AlecSadler 3 points 1 year ago

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.

[–] [email protected] 2 points 1 year ago

I worked on a team that did, and it was the second-worst application I've ever touched.

[–] [email protected] 2 points 1 year ago* (last edited 1 year ago)

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.

[–] [email protected] 2 points 1 year ago

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.

[–] [email protected] 2 points 1 year ago

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.