Every state, not just the happy one

Technology

Storybook renders a component outside the application, one file per state. Loading, empty, error, the string four times longer than the mock, the disabled variant nobody navigates to on purpose. Those states get built because building them in isolation is the only reliable way to see them.

It matters most on a design system several teams consume, where a component has to hold up inside applications its author will never open. The stories become the contract between the people building components and the people using them.

Monogram logo

States

What a story is for, and when it is overhead

  1. A story is an addressable state

    Loading, empty, error, permission denied, text four times longer than the mock: states a running application will not show you on demand. A story is a URL that renders exactly one of them, which is how they get designed and reviewed rather than discovered by a user.

  2. The stories double as the test fixtures

    Play functions drive real interaction against a story, and the same files feed accessibility checks and visual regression snapshots. The fixtures you would have written for component tests already exist, so the catalog and the test suite stop being two separate maintenance jobs.

  3. It is a second application to keep alive

    Storybook has its own build, its own mocks, and its own deploy, and stories rot the moment nobody develops against them. On a design system consumed by several teams it repays that; on a marketing site with fifteen components it does not. No case study here lists it.