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.

  • ashtefere@lemmy.world
    link
    fedilink
    arrow-up
    6
    ·
    1 year ago

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

  • rororo@lemmy.world
    link
    fedilink
    arrow-up
    4
    ·
    1 year ago

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

  • macniel@feddit.de
    link
    fedilink
    arrow-up
    3
    ·
    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@sh.itjust.works
    link
    fedilink
    arrow-up
    3
    ·
    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.

  • edongmusk@lemmy.world
    link
    fedilink
    arrow-up
    2
    ·
    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.

  • pastelmind@programming.dev
    link
    fedilink
    arrow-up
    2
    ·
    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.

  • WhatAmLemmy@lemmy.world
    link
    fedilink
    arrow-up
    2
    ·
    edit-2
    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.