# Stable stories

Make a screenshot change only when the component changes.

## Use predictable data
Replace random names, generated IDs, current dates, and live counts with fixtures. Give your component a fixed date or clock through props or a test provider. Avoid depending on the current timezone or the timing of a live request.

```ts
export const Example = {
  args: {
    name: 'Alex Example',
    updatedAt: '2026-01-15T12:00:00Z',
    notificationCount: 3,
  },
};
```

## Bundle assets and mock services
Keep fonts and images in the static build where possible. Mock API requests with your normal Storybook mocking setup. Verify the static build, because a working development server can hide missing assets or environment variables.

If a request is intentionally external, allow its host in project settings and ensure it works without your local credentials. A changing remote image still causes a visual change even when the request is allowed.

## Wait for the state you want
Use Storybook loaders and play functions to put the component into a deliberate state before capture. Resolve asynchronous work instead of adding a long arbitrary delay. A small `framecheck.delay` can help with a known settling interval, but should not mask a missing asset or an endless loading state.

Framecheck disables animations and waits for rendering to settle. Canvas, timers, custom animation systems, and live data can still require fixture or component changes.

## Keep state isolated
Stories should not depend on which story ran before them. Reset mocked data and avoid sharing mutable state across examples. Test both the story alone and the full static Storybook.

## Diagnose a noisy result
Compare the changed pixels, check missing fonts and blocked hosts, inspect story errors, and look at the Unstable group. If only a deliberate live area changes, consider [ignore regions](/ignore-regions/). For a temporarily unreliable story, use [quarantine](/unstable-stories/) while fixing it.