Angular

Purpose and Scope

Storybook for Angular is the Angular-specific framework entry point for using Storybook as a frontend workshop: it lets teams build, test, and document Angular components in isolation while keeping the workflow close to a normal Angular application. In Storybook terminology, a framework is a package that provides out-of-the-box support for either a metaframework or a renderer-and-builder combination. Angular fits the renderer side of that model, with the official Angular documentation describing Angular builders and automatic documentation integration through Compodoc. Sources: docs/contribute/framework.mdx

The practical reader problem is usually not only installing a package. Angular projects already have application builders, dependency injection, module metadata, standalone APIs, assets, styles, and documentation conventions. The Angular framework page should be read as the bridge between the general Storybook workflow and Angular’s project model. Storybook’s framework guidance says a framework should make Storybook behave out of the box as similarly as possible to the target environment, while respecting the user’s existing project configuration. Sources: docs/contribute/framework.mdx

Relevant Source Files

• docs/contribute/framework.mdx — Defines what a Storybook framework is, explains the builder plus renderer model that includes Angular, and describes the expected responsibilities of framework packages, including documentation-first design and compatibility decisions.

Core Primitives

The first primitive is the Storybook framework package itself. The framework is a Node package, not merely a sample configuration, and the contribution guide describes framework packages as the unit that provides out-of-the-box support for a renderer and builder combination or for a metaframework. For Angular users, this means the Storybook configuration selects an Angular framework package, and that package owns the Angular-specific setup necessary for rendering components in the preview environment. Sources: docs/contribute/framework.mdx

The second primitive is the builder. The official Angular page identifies Webpack 5 as a requirement for the documented Angular framework flow, while the repository also contains Angular framework package readmes that point users back to the official Angular documentation. The general framework guidance is useful here because it separates renderer support from builder support: a renderer knows how Angular components are rendered, while a builder controls how Storybook compiles and serves the preview bundle. Sources: docs/contribute/framework.mdx

The third primitive is documentation extraction. Angular teams commonly rely on comments, inputs, outputs, and component metadata as part of their design-system documentation. The official Angular docs describe Compodoc integration for automatic documentation generation, so Storybook’s Angular setup should be understood as both a rendering environment and a documentation pipeline. That matters when deciding whether a story is only a visual example, whether it should feed Autodocs, and whether project documentation settings need to be adjusted before building a published Storybook.

Installation and First Run

Install Storybook from the root of an existing Angular project so the initializer can inspect the project and create the appropriate Storybook configuration. The official Angular docs show the standard command:

npm create storybook@latest

After installation, run the generated Storybook script from the Angular workspace and open the local development server. The first run should show the manager UI, the preview iframe, and any generated example stories. At this point the goal is to confirm that the framework package can compile the preview, load Angular component code, and render stories independently from the main application shell. If compilation fails, treat it as a project-integration problem first: check Angular version compatibility, builder expectations, TypeScript configuration, global styles, and assets before rewriting stories.

A useful first story should be small and representative. Pick a component with clear inputs and outputs rather than a whole routed page. Model a few states with args, then verify that Controls can update those args in the UI. This validates the core Angular renderer path without mixing in routing, HTTP, translation, or application-wide providers. Once that basic loop works, add decorators or application configuration that mirrors the providers your component actually needs.

Angular Configuration Model

Angular Storybook configuration has to account for Angular’s dependency injection and module boundaries. Components that depend on providers, imports, pipes, directives, or application-level configuration need those dependencies supplied in Storybook just as they would be supplied in an Angular app. The framework guidance says a framework should respect the user’s existing project configuration as much as possible, which is the key constraint: Storybook should adapt to the Angular workspace rather than require a separate miniature application that drifts from production behavior. Sources: docs/contribute/framework.mdx

For teams using standalone Angular APIs, configuration usually lives near the story or preview setup so that the rendered component receives the same providers it expects at runtime. For teams using NgModules, module metadata remains the natural way to provide imports and declarations for a story. The important practice is to keep story setup focused on the component’s contract. If every story imports the full application module, stories become slower, harder to reason about, and less useful as isolated examples.

Global concerns belong in shared preview configuration when they affect many stories. Examples include themes, locale providers, global CSS, translation defaults, or browser APIs that components assume exist. Local concerns belong on the component or story when they are part of one scenario. This split keeps the Storybook sidebar useful: the same component can show several states without repeating application boilerplate, while a special integration state can still override providers or parameters for that one story.

Compodoc and Documentation Integration

Compodoc is the Angular-specific documentation tool called out by the official Angular docs, and it is especially important when using Storybook as more than a visual sandbox. In an Angular Storybook, generated documentation can combine stories, component metadata, comments, props-style tables, and authored docs pages. Compodoc helps turn Angular source information into documentation data that Storybook can display, so readers should enable and maintain it when they want Autodocs-style output to reflect the actual component API.

The documentation workflow is iterative. During development, preview the docs mode to confirm that Angular metadata is being extracted as expected, that story names read well, and that examples demonstrate meaningful states. Before publishing, build the static Storybook and inspect the generated docs pages, not just the canvas stories. Broken documentation often points to missing metadata, missing comments, unsupported project structure, or a configuration mismatch between the Angular app and Storybook’s preview build.

System-to-Code Mapping

Compact Reference

Execution Flow

A healthy Angular Storybook flow starts with project detection during installation, continues with generated configuration, then moves into story authoring. Create or review the generated stories, run Storybook locally, and confirm that component rendering works before adding heavier application services. Next, introduce Angular-specific providers, imports, and decorators only where needed. Finally, enable documentation features, verify Compodoc output, and build a static Storybook for sharing with designers, QA, and other stakeholders.

When diagnosing issues, work from the outside inward. First confirm that the Angular and builder requirements match the documented support window. Then confirm that Storybook can compile a simple component. After that, add providers, styles, assets, and documentation generation one layer at a time. This mirrors the framework design principle from the repository source: framework packages exist to hide integration complexity, but they still need to account for framework versions, configuration differences, and realistic project behavior. Sources: docs/contribute/framework.mdx

Related Pages and Next Steps

Read the general installation and setup pages before deep Angular customization, then move to Component Story Format, args, decorators, and parameters to model real component states. For documentation-heavy Angular projects, continue with Autodocs, MDX, doc blocks, and build documentation. If you maintain a framework package rather than only consuming Angular Storybook, read the framework contribution guidance because it defines the package naming, compatibility, documentation, and implementation expectations behind Storybook framework integrations. Sources: docs/contribute/framework.mdx