Browse Stories
Purpose and Scope
Browsing stories is the first practical skill after installing and running Storybook because it turns a set of component examples into a working development workshop. The source page frames this chapter as the step after learning that stories represent discrete component states, then shows how to use the running UI to move between examples, inspect rendering, adjust visual context, and review addon output. Readers should leave knowing where the sidebar, preview, toolbar, docs page, and addons panel fit into the everyday loop of building and verifying components. Sources: docs/get-started/browse-stories.mdx
Storybook’s browsing model starts with story files and ends in an isolated rendered example. A story file defines the available examples for a component, and each story becomes a selectable item in the sidebar. Selecting an item renders that state in the preview iframe, which keeps the component under inspection separate from the rest of the application shell. This separation is what makes the interface useful as a workshop: the reader can focus on one component state, compare it with neighboring states, and inspect behavior without navigating through the full product.
Relevant Source Files
- docs/get-started/browse-stories.mdx - Defines the Browse Stories documentation page, including sidebar and preview behavior, toolbar capabilities, Docs navigation, keyboard accessibility, and addon panel descriptions.
Sidebar and Preview
The sidebar is the primary navigation surface for a running Storybook. The documentation divides it into sidebar search, the story explorer, and a testing widget at the bottom. Search is for quickly locating a story by name when the tree grows large. The explorer is for browsing the component hierarchy and selecting an example directly. The testing widget is presented as a way to run component tests for all stories, connecting browsing with verification rather than treating the UI as a static catalog. Sources: docs/get-started/browse-stories.mdx
The preview area is where the selected story renders. The documentation specifically describes this as an isolated preview iframe, which is an important mental model for new users. The sidebar is not the component itself; it is the navigation and workflow frame. The selected story appears in the preview so that layout, visual state, interactions, and addon metadata can be inspected with minimal surrounding noise. When a story looks wrong, the next step is usually to switch nearby states, adjust toolbar settings, or open the relevant addon tab.
Keyboard navigation is part of the browsing workflow, not an afterthought. The page tells readers to open the Storybook menu to see available shortcuts and calls out fast movement between landmark regions. Pressing F6 and Shift plus F6 moves between the sidebar, toolbar, preview, and addons panel. That matters for accessibility and speed: a developer can move from finding a story, to adjusting the toolbar, to inspecting addon output without relying entirely on pointer navigation.
Toolbar Workflow
The toolbar contains built-in tools that change how the selected story renders in the Canvas. Zoom helps inspect fine detail by visually scaling the component. Background controls let the reader check whether a component still works across different visual contexts. Grid overlays make alignment issues easier to see. Measure toggles a measurement overlay for dimensions, while Outline displays bounding boxes to verify positioning. Viewport switches the rendered story into different dimensions and orientations, which is especially useful for responsive component development. Sources: docs/get-started/browse-stories.mdx
A useful browsing habit is to treat the toolbar as a sequence of questions. First, ask whether the component renders correctly in its default state. Next, use zoom, grid, measure, and outline to evaluate spacing and placement. Then change the background to test contrast and visual assumptions. Finally, use viewport options to see whether the component still works at sizes and orientations that match target devices. This keeps visual inspection repeatable instead of relying on a single default canvas view.
The page also points to the Docs view, which displays auto-generated documentation for components inferred from source code. In a running Storybook, this gives the reader a second way to understand the selected component: Canvas answers how the state looks and behaves, while Docs helps explain usage. The source page positions this as especially helpful for sharing reusable components with a team, such as in an application where consumers need examples and usage guidance alongside implementation work.
Addons Panel
Addons extend Storybook’s core functionality, and their output appears in the addons panel below the Canvas. The page describes each tab as a place for generated metadata, logs, or static analysis tied to the currently selected story. This means addon output is contextual: changing the selected story changes what the panel reports. A reader should browse stories with the panel open when debugging inputs, events, accessibility, or test behavior, because the panel complements what the preview visually displays. Sources: docs/get-started/browse-stories.mdx
Several built-in addon workflows are highlighted. Controls lets users change a component’s args dynamically and discover edge cases through alternate configurations. Actions logs callback-style outputs, such as confirming that a logout button triggers the expected callback in a Header story. Interactions provides a user interface for debugging interaction tests that use a play function. Accessibility helps identify accessibility violations in components. Visual Tests is introduced as a local development aid for pinpointing UI bugs. Together, these tabs make browsing an active diagnostic process.
Practical Browsing Flow
A practical first pass through a Storybook is simple. Start in the sidebar search when you already know the component or state name. Otherwise, expand the story explorer and select the most representative story for the component. Inspect the isolated preview, then use toolbar tools to check scale, background, alignment, measurements, outlines, and responsive dimensions. Open Docs when you need generated usage information. Finally, review addon tabs for controls, actions, interaction debugging, accessibility feedback, or visual test signals tied to the selected story.
When a Storybook becomes large, navigation choices matter. Search is faster for known targets, while the explorer is better for discovering adjacent component states. Keyboard shortcuts help experienced users move between the major regions quickly. The testing widget at the bottom of the sidebar gives a path from browsing to broad validation. Addon tabs narrow the investigation to a single selected story. These surfaces work together: the sidebar chooses the example, the preview renders it, the toolbar changes viewing context, and addons explain or test what happened.
Reference: UI Areas
| Area | What it is used for | Source-backed behavior |
|---|---|---|
| Sidebar search | Finding stories by name | The source page tells readers to try search to find a story by name. |
| Story explorer | Moving through stories | Clicking a story in the explorer renders it in the isolated preview iframe. |
| Testing widget | Running component tests | The widget at the bottom of the sidebar runs component tests for all stories. |
| Toolbar | Adjusting Canvas rendering | Zoom, background, grid, measure, outline, and viewport tools are listed. |
| Docs page | Reading generated usage documentation | Docs displays auto-generated component documentation inferred from source code. |
| Addons panel | Inspecting story-specific metadata and diagnostics | Tabs show generated metadata, logs, or static analysis for the selected story. |
Next Steps
After learning to browse, continue into story authoring and Storybook Essentials. The most direct next topic is writing stories, because browsing becomes more valuable when each component has clear states with meaningful names. Then learn Controls and Actions to make the addons panel more useful during everyday development. For visual inspection, follow the toolbar-related pages for backgrounds, viewport, measure, outline, and globals. For quality workflows, continue to interaction testing and accessibility testing so the testing widget and addon tabs connect to repeatable validation rather than manual inspection only.