Sidebar & URLS
Storybook’s sidebar lists all your stories grouped by component. When you have many components, you may also wish to group those components. To do so, you can add the
/ separator to the
title of your CSF file, and Storybook will group the stories into groups based on common prefixes:
We recommend using a nesting scheme that mirrors the filesystem path of the components. For example, if you have a file
components/modals/Alert.js, name the CSF file
components/modals/Alert.stories.js and title it
By default, Storybook will treat your top-level nodes as “roots”. Roots are displayed in the UI as “sections” of the hierarchy. Lower level groups will show up as folders:
If you’d prefer to show top-level nodes as folders rather than roots, you can set the
sidebar.showRoots option to
By default, Storybook generates an
id for each story based on the component title and the story name. This
id in particular is used in the URL for each story, and that URL can serve as a permalink (primarily when you publish your Storybook).
Consider the following story:
Storybook's ID-generation logic will give this the
foo-bar--baz, so the link would be
It is possible to manually set the story's id, which is helpful if you want to rename stories without breaking permalinks. Suppose you want to change the position in the hierarchy to
OtherFoo/Bar and the story name to
Moo. Here's how to do that:
Storybook will prioritize the
id over the title for ID generation if provided and prioritize the
story.name over the export key for display.
Storybook 6.4 introduced CSF 3.0 as an experimental feature, allowing you to write stories more compactly. Suppose you're already using this format to write your stories. In that case, you can omit the
title element from the default export and allow Storybook automatically infer it based on the file's physical location. For example, given the following configuration and story:
When Storybook loads, the story can show up in the sidebar as
Starting with Storybook 6.5, story titles generated automatically no longer rely on Lodash's startCase.
Instead, the file name casing is preserved, allowing additional control over the story title. For example,
components/My Component will be defined as
If you need, you can revert to the previous pattern by adding the following configuration:
In addition to improvements to the story file name casing, a new heuristic was introduced, removing redundant names in case the filename has the same name as the directory name, or if it's called
index.stories.js|ts. For example, before
components/MyComponent/MyComponent.stories.js was defined as
Components/MyComponent/MyComponent in the sidebar. Now it will be defined as
If you need to preserve the naming scheme, you can add the
title element to the default export. For example:
Additionally, if you customize your Storybook to load your stories based on a configuration object, including a
titlePrefix, Storybook automatically prefixes all titles to matching stories. For example, assuming you have the following configuration:
When Storybook generates the titles for all matching stories, they'll retain the
Story Indexers are usually responsible of crawling through your filesystem on your given glob path, and retrieve the stories that match that glob, afterwards Storybook analyzes these stories and create entries for these stories in the
index.json is used to populate the sidebar links based on the
title retrieved for each story from the story file.
For CSF, it is either auto generated or retrieved from the meta configuration.
While for "Docs Only" pages, that title resides in the
title attribute of the
Meta tag. If the
title attribute does not exist, Storybook indexer will be looking for the
of attribute to retrieve a CSF story and get the title from there.
Typically Storybook provides indexing capabilities for files that end with
.(story|stories).@(js|ts|jsx|tsx|mdx). If you feel the need to include stories that have different naming convention, e.g.
20478, you will need to introduce a new story indexer.
Another example listed below for indexing
.html files which is already implemented by one of our community addons