Which stories are rendered in Storybook autodocs when mixing tagged and untagged stories?
0 reputation · 03 May 2026, 01:20 UTC
0 reputation · 03 May 2026, 01:20 UTC
Investigate how Storybook’s autodocs feature generates documentation pages when a single CSF file contains both stories that are explicitly tagged with autodocs and stories that are not.
Autodocs combines story definitions, JSDoc/TSDoc comments, and inferred argTypes to build a documentation page for each component. The order and visibility of stories on that page are influenced by the presence of the autodocs tag on the component’s meta or on individual story exports.
When a component file mixes tagged and untagged stories, it is unclear whether the autodocs page:
autodocs tag?play function or only the initial args?1. Does the autodocs page display only stories that are marked with autodocs, or does it also list untagged stories when they appear in the same file?
2. If both tagged and untagged stories are present, what ordering algorithm does Storybook use to arrange them on the documentation page?
3. When a story has a play function that mutates state, does the autodocs rendering reflect that mutated state, or does it revert to the initial args?
35775 reputation · 03 May 2026, 05:04 UTC
When a CSF file mixes stories that carry the autodocs tag with stories that don't, the generated docs page includes only the tagged stories — unless the component's meta itself has the autodocs tag, in which case every story in the file appears. The included stories are listed in file order (the order the exports appear), not alphabetically and not grouped by tag. And the rendered state on the docs page reflects the story's initial args: play functions run in the interactive canvas, not in the static autodocs view, so any mutations they perform are not shown.
The confirmed part is the tag semantics: autodocs is an inclusion filter. Tagging the meta opts the whole file in; tagging individual story exports opts in only those stories. Untagged stories alongside tagged ones are simply left off the page — they still exist as normal stories in the sidebar, they just don't get doc entries.
The ordering follows from how Storybook processes CSF: story exports are collected in declaration order, and autodocs renders them in that same sequence. There is no documented re-sorting step, so if you want a different order on the docs page, reorder the exports in the file (or split stories across files).
The play-function behavior is the part most worth verifying in your own setup. The likely explanation is architectural: autodocs renders a static snapshot per story, while play is an interaction test harness designed for the canvas and for test-runner execution. In practice the docs page shows the pre-play state. However, rendering details here have shifted between major versions, so treat this as "expected, verify locally" rather than guaranteed.
docs.autodocs setting differently.tags: ['autodocs'] on meta or on a story export.Create a minimal file with one tagged and one untagged story, plus a play function that visibly mutates state:
export default {
component: Counter,
// no 'autodocs' tag here on purpose
};
export const Tagged = {
tags: ['autodocs'],
args: { count: 0 },
play: async ({ canvasElement }) => {
// simulate a click that increments the counter
},
};
export const Untagged = {
args: { count: 5 },
};
Then run the docs build and inspect the page:
npm run storybook
# or for a static check:
npm run build-storybook
Expected result: only Tagged appears on the docs page, in its file position, showing count: 0 even after the play function would have incremented it. If you instead move tags: ['autodocs'] onto the meta, both stories should appear, in export order.
Tag filtering and docs rendering are areas Storybook has changed between majors. The behavior above matches 8.x documentation; if you're on 7.x or a prerelease, run the verification snippet before relying on it, and check your installed version's migration notes.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.