Files
superset2/docs/developer_docs_versioned_docs/version-6.1.0/testing/storybook.md
Claude Code cbcfd9599f docs: cut 6.1.0 versions for docs, admin_docs, developer_docs, components
Snapshots all four versioned Docusaurus sections at v6.1.0. Built on
top of the version-cutting tooling work in chore/docs-cut-6.1.0-versions
so the snapshot benefits from:

- Auto-gen refresh before snapshotting (database pages from engine
  spec metadata, API reference from openapi.json, component pages
  from Storybook stories) — captured at the SHA we cut from rather
  than whatever happened to be on disk.
- Data-import freeze: country list, feature flag table, database
  diagnostics, and component metadata are copied into snapshot-local
  `_versioned_data/` dirs so the historical version doesn't silently
  mutate when the source files change.
- Depth-aware import-path rewriter that handles deeply-nested
  component MDX files referencing `../../../src/` from the snapshot.

Versioning behavior: `lastVersion` stays at `current` for every
section, so the canonical URLs (`/docs/...`, `/admin-docs/...`,
`/developer-docs/...`, `/components/...`) continue to render content
from master. The `current` version is consistently labeled "Next"
with an `unreleased` banner, and `6.1.0` is a historical pin
accessible only via its explicit version segment.

Component playground: previously `disabled: true` in versions-config.json,
now enabled and versioned. The plugin block in docusaurus.config.ts
was already gated only by the `disabled` flag, so no other code
changes were needed to bring it back online.

The frozen `databases.json` in the snapshot is the canonical 80-database
artifact from the latest committed state in master (preserved by the
generator's input-hash cache), not a fallback regenerated from a
local Flask environment.
2026-05-13 17:15:46 -07:00

3.0 KiB

title, sidebar_position
title sidebar_position
Storybook 5

Storybook

Superset uses Storybook for developing and testing UI components in isolation. Storybook provides a sandbox to build components independently, outside of the main application.

Public Storybook

A public Storybook with components from the master branch is available at:

apache-superset.github.io/superset-ui

Running Locally

Main Superset Storybook

To run the main Superset Storybook locally:

cd superset-frontend

# Start Storybook (opens at http://localhost:6006)
npm run storybook

# Build static Storybook
npm run build-storybook

@superset-ui Package Storybook

The @superset-ui packages have a separate Storybook for component library development:

cd superset-frontend

# Install dependencies and bootstrap packages
npm ci && npm run bootstrap

# Start the @superset-ui Storybook (opens at http://localhost:9001)
cd packages/superset-ui-demo
npm run storybook

Adding Stories

To an Existing Package

If stories already exist for the package, extend the examples array in the package's story file:

storybook/stories/<package>/index.js

To a New Package

  1. Add package dependencies:

    npm install <package>
    
  2. Create a story folder matching the package name:

    mkdir storybook/stories/superset-ui-<package>/
    
  3. Create an index.js file with the story configuration:

    export default {
      examples: [
        {
          storyPath: '@superset-ui/package',
          storyName: 'My Story',
          renderStory: () => <MyComponent />,
        },
      ],
    };
    

    Use the | separator for nested stories:

    storyPath: '@superset-ui/package|Category|Subcategory'
    

Best Practices

  • Isolate components: Stories should render components in isolation, without application context
  • Show variations: Create stories for different states, sizes, and configurations
  • Document props: Use Storybook's controls to expose configurable props
  • Test edge cases: Include stories for loading states, error states, and empty states