Why is an isolated Storybook story often a more reliable screenshot target for visual regression than the same component rendered on a page of the running application?

## The two properties a screenshot target needs A visual regression check is only useful if a diff means something. That requires two properties of whatever you photograph. **Determinism.** Rendering the same commit twice must produce the same image. Any input that varies between runs — a timestamp, a random ordering, a personalised feed, an A/B bucket, an advert — turns into a pixel difference that no code change caused. **Attribution.** When a diff does appear, it must be cheap to trace to a cause. The narrower the render target, the shorter that trace. An isolated story is engineered for both. A live application page is engineered for neither, because a page's job is to show real, current, personalised content. ## Where a story's determinism comes from It comes from the *inputs*, not from the tool. A story declares its own props through `args`; there is no data fetch to resolve, no route to match, no authenticated session whose state leaks into rendering, no navigation history. The component is mounted directly with values written in the file, so the render is a pure function of the code plus those literals. That is a much stronger guarantee than "we pointed the browser at `/dashboard` and waited". On a real page, determinism would require pinning every upstream input — the API responses, the clock, the flags, the user record — which is most of the work of building a story in the first place, done less explicitly. It is worth being precise about the limit: story isolation removes *application-level* nondeterminism. Rendering-level variation — anything still in motion or still loading when the shutter fires — is a separate discipline and does not go away just because the target is a story. ## Where attribution comes from A story diff is scoped by construction. The image contains one component in one named state, so the failure report reads roughly "`Alert / Failure` changed" and the change is in that component, its styles, or something global that reaches it. Compare that with a full-page diff, which tells you that some rectangle of a composed page moved and leaves you to work out whether the cause was the component, its neighbour, a layout container, or the data. This matters most on a shared design system, where one primitive's padding change propagates into dozens of surfaces. Story-level capture shows you the primitive changed *and* which composed stories inherited it — a page-level suite would only show you a pile of moved pages. ## What you give up Isolation is a filter, and filters remove signal along with noise. What a story cannot show you: - **Composition.** The component sitting beside a sticky header, inside a constrained grid cell, or as a sibling of another component that competes for width. - **Real content.** Whatever the story's literals are is what gets rendered; production strings, locales and data volumes may be wildly different. - **The application's global environment.** The app's own resets, theme layer and container widths only reach the story if the Storybook preview was set up to load them — otherwise the two environments quietly diverge. So the honest framing in an interview is a layering answer, not a superiority answer: stories are the wide, cheap, high-attribution layer, and a handful of page-level visual checks exist specifically to catch the composition drift that stories structurally cannot see. ## The failure mode to name The classic anti-pattern is a team that screenshots real pages, gets diffs on most runs, and reacts by loosening comparison or by rubber-stamping every diff. Both responses convert the suite into a ritual: it still runs, still goes green, and no longer detects anything. The structural fix is to move the capture to a target that is deterministic by construction — which is exactly what a story is — and to accept a small number of deliberately maintained page-level checks rather than a large number of noisy ones.