Autodocs and DocsPage

Purpose and Scope

Autodocs is Storybook's automatic documentation path: it turns the same stories developers use for isolated UI development into component documentation pages. In the reader-facing docs, Storybook describes this as transforming stories into living documentation by inferring metadata such as args, argTypes, and parameters, then positioning the generated page at the root level of the component tree in the sidebar. This fits the repository's public purpose: Storybook is presented as a frontend workshop for building UI components and pages in isolation, used for UI development, testing, and documentation. Sources: README.md

A DocsPage is the generated documentation view that users browse alongside stories. It is useful because it keeps examples, controls, argument tables, and descriptive context close to the component states that validate them. Instead of maintaining a separate design-system site by hand, teams author stories, add comments and metadata, and let Storybook assemble a readable page. When the generated page is not enough, MDX and Doc Blocks extend the same surface with long-form prose, embedded stories, custom sections, and framework-specific guidance.

Relevant Source Files

• README.md - Establishes Storybook as a frontend workshop for isolated UI development, testing, and documentation, and points readers to the public documentation site.
• package.json - Shows the monorepo package/workspace layout that includes code, addons, frameworks, builders, renderers, presets, and scripts, which is the architecture in which docs features are packaged and exercised.
• code/frameworks/angular-vite/template/stories/basics/README.mdx - Demonstrates an MDX documentation page using the docs-blocks Meta component to place a docs entry in the Storybook hierarchy.
• code/frameworks/angular-vite/template/stories/core/README.mdx - Demonstrates another framework-template MDX page for Storybook-native examples, showing that documentation pages can sit directly beside example stories.
• code/frameworks/angular-vite/template/stories/others/ngx-translate/README.mdx - Shows authored MDX documentation with a Meta title, explanatory prose, links, and TypeScript snippets for a framework-specific integration topic.
• code/frameworks/angular/template/stories/basics/README.mdx - Provides the same docs-page pattern for the Angular Webpack template.
• code/frameworks/angular/template/stories/core/README.mdx - Provides the same native-feature docs-page pattern for the Angular Webpack template.
• code/frameworks/angular/template/stories/others/ngx-translate/README.mdx - Shows the Angular Webpack version of a richer integration docs page using MDX and docs blocks.

Core Concepts

A story is the atomic input to Autodocs. Each story models a meaningful component state: for example, a primary button, a loading page, or a localized widget. Autodocs reads those stories as examples and combines them with component metadata. Args describe the input values a story supplies; argTypes describe the shape, controls, and documentation for those inputs; parameters carry configuration consumed by Storybook and addons. The result is a page that explains what the component is, shows how it behaves, and exposes the inputs that readers can inspect or modify.

Tags control whether automatic documentation is generated. The official Autodocs flow describes Autodocs as configured through tags, so the practical authoring model is to opt a component, group, or project into docs generation rather than write a page from scratch for every component. A typical CSF story file can use a default export with a component, title, tags, args, argTypes, and parameters. Storybook then has enough information to place the component in the sidebar, render its examples, and generate the corresponding documentation page.

const meta = {
  component: Button,
  tags: ['autodocs'],
  args: { primary: true },
};
 
export default meta;
 
export const Primary = {};

How Stories Become Documentation

Autodocs starts from the story index that Storybook already uses for browsing. The get-started docs explain that a stories file defines all stories for a component and that each story receives a sidebar item rendered in an isolated preview iframe. Autodocs builds on that navigation model: the component's stories remain usable as individual examples, while the DocsPage collects them into a higher-level documentation destination. This means a component author can keep the source of truth in one place, then serve both interactive exploration and reference documentation from it.

The generated page is assembled from multiple kinds of source information. Story exports provide examples. Args provide the initial state for each example. ArgTypes feed control metadata and props-style tables. Parameters customize behavior for the docs page and for addons that participate in rendering. Comments and framework metadata can enrich names, descriptions, and property tables when the framework integration can extract them. The important design point is that documentation quality improves as the story file becomes more explicit, typed, and representative of real component usage.

MDX, Doc Blocks, and DocsPage Customization

Autodocs is not the only documentation mode. The repository templates include MDX files that import Meta from @storybook/addon-docs/blocks and declare a title. That pattern is the authored-docs counterpart to generated DocsPage output: MDX lets a team decide the page structure directly while still using Storybook's documentation primitives. The Angular and Angular Vite templates place README.mdx files under template story directories, which shows that docs pages can live beside framework examples and can participate in the same Storybook sidebar hierarchy. Sources: code/frameworks/angular-vite/template/stories/basics/README.mdx, code/frameworks/angular-vite/template/stories/core/README.mdx, code/frameworks/angular/template/stories/basics/README.mdx, code/frameworks/angular/template/stories/core/README.mdx

import { Meta } from '@storybook/addon-docs/blocks';
 
<Meta title='stories / frameworks / angular / basics / README' />
 
# Examples for Angular features

Richer MDX pages can combine prose, links, and executable examples. The ngx-translate template pages describe a framework-specific integration, link to the decorators documentation, and include TypeScript snippets for configuring Angular providers through Storybook decorators. That is a useful model for deciding when to move beyond Autodocs: use generated DocsPage output for component API and example coverage, then use MDX when the reader needs setup context, tradeoffs, integration instructions, or a multi-step explanation. Sources: code/frameworks/angular-vite/template/stories/others/ngx-translate/README.mdx, code/frameworks/angular/template/stories/others/ngx-translate/README.mdx

System-to-Code Mapping

The docs feature area lives within a monorepo that separates top-level coordination from implementation packages. The root package declares workspaces for code, addons, builders, frameworks, renderers, presets, libraries, and scripts. That layout matters because DocsPage generation is not a standalone website generator; it depends on renderer integrations to understand components, builders to compile the preview, addons and doc blocks to render documentation UI, and framework templates to demonstrate supported authoring patterns. Sources: package.json

Practical Authoring Flow

Start with stories that cover the component states readers actually need to understand. Add clear args so each example communicates intent without hidden setup. Add argTypes when controls, default values, or table descriptions need to be clearer than what inference can provide. Add parameters when the generated page, layout, or addon behavior needs local customization. Then enable Autodocs with tags so the DocsPage appears automatically in the sidebar near the component's stories.

After the generated page exists, review it as a consumer rather than as the component author. Check whether the story names read like examples, whether the controls table explains meaningful inputs, and whether the examples cover edge cases rather than only happy paths. If readers need installation notes, provider setup, localization context, or framework-specific caveats, add an MDX page or customize the docs composition with Doc Blocks. The framework README.mdx examples in the repository show this pattern: concise generated-style pages for basics, and longer authored pages for integrations.

Next Steps

Use Autodocs as the default path for component reference pages, especially when stories already model the important states and args. Reach for MDX and Doc Blocks when the documentation needs a narrative, a guide, or integration-specific setup. To continue through the docs system, read the pages on MDX Documentation, Doc Blocks and Code Panel, Args and Arg Types, Parameters, and Component Story Format. Those topics explain the metadata and authoring surfaces that make generated DocsPage output more accurate and useful.