Opinion requested: should stories only be about different args for 1 component

[thobas-dnvgl]

I inherited a project using Storybook and I have a (philosophical?) question.

My understanding is that stories are to be kind of unique and demo some args (props in React) variants for a specific component (like a Button).

Taking a Button as example again, one would create a story where there is a trash icon and its color would be red with the text "Delete" (just an example, provided that the component is that configurable), another where the button has no icon and the text is replaced with a spinner, another story for the disabled state, etc.

In the project I am now working on, some stories are actually showing a grid of several state of the Button component. The root component of the following Button story is actually a Grid and not the Button. It also means that for this story it makes no sense to show/use the arg table:

What do you think of this? Is it ok? Should I remove those stories that try to do to many things and focus on story showing only one instance of the component?

[dosubot[bot]]

Hi @thobas-dnvgl! I'm Dosu and I’m helping the storybook team.

It's totally valid to have both single-instance stories (showing one variant of a component with specific args) and composite/grid stories (showing multiple states together) in Storybook. The most common and recommended pattern is to use single-instance stories for each variant, which works best with Storybook's controls, documentation, and automated testing features. This keeps your stories focused, makes the ArgsTable meaningful, and helps with maintainability and discoverability [docs].

However, composite/grid stories are also supported and can be useful for visual comparison or design review, especially when you want to see many states at once. Storybook maintainers have said it's fine to have a story that renders multiple variants, and recent versions even let you tag these stories so they don't clutter the sidebar or test runs [discussion].

If you keep the grid stories, consider tagging them (e.g., ["!dev", "!test"]) so they don't interfere with your main story navigation or automated workflows. But for most use cases, it's best to focus on single-instance stories for each variant and use composite/grid stories as a supplement, not a replacement.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[thobas-dnvgl]

Ok AI, you win, this is actually a good answer.