UI Component Explorers: How to Preview and Capture Component States

A component explorer lets you render a UI component outside the application around it, so you can inspect meaningful states independently. In Storybook, each saved variation is a story: define its inputs with args, select it in the sidebar, adjust bounded values with Controls, and capture the rendered story for visual comparison. Use stories for reproducible previews; use visual tests when you need to compare rendered pixels against an accepted baseline.

This guide builds that workflow around Storybook: choose useful states, make them discoverable, capture and review changes, and troubleshoot common sources of noisy or misleading screenshots. It also explains where Figma links and a screenshot API fit.

1. What a component explorer does

A component explorer is an isolated sandbox alongside an application. It renders components apart from application business logic and app context, making a component’s supported variations independently inspectable. Storybook describes this as isolating UI concerns from business logic and app context.^{Storybook: Component explorers}

A story records a component with a particular set of inputs or setup. For example, a button might have stories for its primary and secondary variants, disabled state, and a loading state. The story is both a reusable preview and a useful unit for documentation and testing. Select a story in Storybook’s sidebar to render it in the preview iframe.

Keep the distinction clear:

Preview: a person selects a story and inspects the rendered component.
Visual test: tooling captures rendered pixels and compares them with a known baseline.
Markup snapshot: a test compares rendered markup. It checks a different output from a pixel comparison and can catch different problems.

A screenshot does not establish that every interaction works or that the component is accessible. Pair visual review with interaction and accessibility checks where those matter.

2. Choose states worth preserving

Start with states that help a teammate understand, use, or review the component. Depending on the component, useful examples may include:

Default and alternate variants.
Loading, empty, and error content.
Disabled, selected, expanded, or checked states.
Long or missing text, unusually large values, or other boundary inputs.
Relevant responsive sizes or themes.
States that require a user action, such as a menu after opening or a field after validation.

These are prompts, not a requirement that every component implement every state. Prefer a small set of intentional, named examples over many indistinguishable stories. A story should make the state and the inputs that produce it understandable to someone who did not write the component.

3. Create stories and explore them with Controls

In Storybook, stories define component examples, commonly with args. Controls can edit those arguments and update the preview in real time. Storybook can infer controls, and argTypes can describe or constrain them. For a finite choice such as primary or secondary, a radio or select control is clearer and safer than free-form text.^{Storybook: Controls}

Here is a minimal CSF-style example for a React button. Adjust the import path and component props to match your project and installed Storybook version.

import type { Meta, StoryObj } from '@storybook/react';
import { Button } from './Button';

const meta = {
  title: 'Components/Button',
  component: Button,
  args: {
    children: 'Save changes',
    variant: 'primary',
    disabled: false,
  },
  argTypes: {
    variant: {
      control: { type: 'radio' },
      options: ['primary', 'secondary'],
    },
    disabled: { control: 'boolean' },
    children: { control: 'text' },
  },
} satisfies Meta<typeof Button>;

export default meta;
type Story = StoryObj<typeof meta>;

export const Primary: Story = {};
export const Secondary: Story = {
  args: { variant: 'secondary' },
};
export const Disabled: Story = {
  args: { disabled: true },
};

Give stories names that communicate what a reviewer should see. Use Controls for safe input exploration, then save recurring or important combinations as named stories so they can be revisited and included in visual checks.

Use interaction steps for action-driven states

Some states are reached through an action rather than a prop: opening a menu, typing into a search box, or submitting invalid input. Use Storybook’s interaction tooling to perform and debug those steps. Mock dependencies when a story would otherwise rely on application context, a network service, or backend data. Isolated mocks make the scenario repeatable and let you define edge cases without depending on production services.^{Storybook: Interaction testing}

For reliable capture, make the story reach its intended state deterministically. Avoid relying on a person to click through the preview immediately before a screenshot, or on live data that can change between runs.

4. Capture and review visual states

Storybook visual tests compare rendered pixels for stories with known baselines. With the documented Chromatic integration, a Visual Tests run sends stories to cloud browsers for snapshots, and changed pixels are highlighted for review. Accept a change as the new baseline when it is expected; when it is unexpected, fix the story or component and run the check again. The Storybook documentation recommends using the addon during development and running visual checks in CI before merge.^{Storybook: Visual testing}

Make the story deterministic. Set its data, props, and necessary mocks. Avoid state that depends on an uncontrolled service or timing.
Capture the stories that matter. Start with important components and states. Add the dimensions your team needs, such as theme, locale, viewport, forced-colors, or reduced-motion preference; these are choices, not universal coverage guarantees.
Run visual checks during development and in CI. Local feedback helps when changing a component; a CI check lets reviewers see the visual difference before merge.
Inspect changed pixels in context. Decide whether a difference is intended. A broad change may be a real design update, a broken style, a missing font, or an unstable rendering condition.
Update baselines deliberately. Accept the new rendering only after reviewing the change. If it is unexpected, fix the cause and rerun rather than recording the defect as expected output.

Storybook’s documented Chromatic visual-testing addon applies to Storybook 7.6 or later; confirm compatibility with your installed version because version requirements can change.^{Storybook: Visual testing integration}

Chromatic describes a Storybook workflow that runs visual, interaction, and accessibility tests on captured stories. Those checks complement one another: a pixel comparison is useful for appearance changes, while interaction and accessibility checks address other questions.^{Chromatic documentation}

5. Keep the explorer useful to teammates

Organize stories by component and use concise names for variations.
Set a representative default story so opening a component gives a useful first view.
Use Controls for values that are useful to vary live, and constrain finite domains to valid options.
Include short usage guidance where a story catalogue alone does not explain intended use.
Keep edge cases and action-driven examples findable instead of hiding them in one-off local setup.
Review whether stories still represent supported behavior when the component API changes.

A story can also serve as a concrete example for someone using the component in application code. A tidy catalogue makes those examples easier to find and reuse.

6. Connect implementation stories with Figma when useful

Storybook can be connected to Figma so a design file links to a live implementation story. The documented workflow can link a story to a Figma component, variant, or instance. Its prerequisites include publishing the Storybook project on Chromatic, edit permission in Figma, and collaborator access in Chromatic.^{Storybook: Figma integration}

Figma component properties can expose controlled values such as visibility, text, instance swaps, and variants. Interactive components can switch between variants in prototypes—for example, hover to pressed or checked to unchecked. This is useful for design preview and discussion, but it does not replace a running coded component explorer or code-based visual regression checks.^{Figma: Interactive components}

7. Capture individual states outside a visual-testing service

For a one-off capture, open the exact story URL in a browser and use the browser’s screenshot capability or an approved browser automation tool. Capture the isolated preview after the story and its fonts and assets have loaded. Save the story identifier and relevant viewport or theme alongside the image so another reviewer can reproduce the state.

For a reusable regression workflow, prefer a visual-testing integration that captures stories and manages comparison against baselines. A loose collection of manually saved screenshots does not by itself tell you which version produced each image or highlight unexpected pixel changes.

8. Troubleshoot common problems

Symptom	Likely cause	What to do
The story shows the wrong state	Its args do not match the intended scenario, or the state depends on app context.	Set the needed args explicitly. Mock the context or dependency in the story and save the scenario under a clear name.
A Control allows invalid values	The input domain was inferred too broadly or is not described.	Define an appropriate control and finite `options` in `argTypes`; use a control suited to the value’s domain.
An interaction story is inconsistent	The action sequence or external dependency is not deterministic.	Use interaction tooling to inspect the steps, make the initial state explicit, and mock network or application dependencies.
A visual check reports unexpected differences	The component changed, or its rendering inputs differ from the baseline.	Inspect the highlighted change, verify story data and capture dimensions, and decide whether the change is expected before updating the baseline.
Screenshots differ between runs	Content, timing, fonts, assets, or selected environment dimensions may vary.	Stabilize the story inputs and dependencies, wait for the required content, and standardize the viewport and relevant theme or preference.
A design link is unavailable to a teammate	The documented integration has publishing or access prerequisites.	Check that the project is published on Chromatic and that the teammate has the required Figma edit permission and Chromatic collaborator access.
The visual-testing addon does not match the installed Storybook	The documented integration has a version requirement.	Check the current integration documentation and compatibility for the Storybook version installed in the project.

9. Performance, reliability, and cost considerations

Keep capture work focused

Start with the stories that protect important UI and cover meaningful states. Every additional state or rendering dimension creates another example to maintain and review. Add themes, locales, viewport sizes, or accessibility preferences where they answer a real review question rather than multiplying combinations automatically.

Make failures diagnosable

Keep story setup explicit and dependencies mocked where practical. When a comparison changes, reviewers need to distinguish an intended UI update from changed input data or an inconsistent environment. Run checks in development for quick feedback and in CI before merge for review visibility.

Choose a capture workflow that fits the job

A browser screenshot is sufficient for an ad hoc review. Baseline comparison and change highlighting are more useful when a team needs repeatable visual regression review. Hosted workflows can reduce the need to manage capture infrastructure, while they also introduce a service and its plan or access requirements. Check current product documentation and pricing before choosing a service; this guide makes no quantified speed or savings claims.

10. Or skip the browser setup

For a direct screenshot request, ScreenshotNeo is a website screenshot API and MCP server for developers. A single GET request can return a PNG, JPEG, WebP, or PDF. This is useful for capturing a public story URL or a rendered page; it does not replace Storybook stories or baseline review. See the ScreenshotNeo API documentation for parameters and response details.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
const image = Buffer.from(await res.arrayBuffer());
await import('node:fs/promises').then(({ writeFile }) => writeFile('shot.webp', image));

Replace the sample target with the URL of the specific page or story you can access. ScreenshotNeo removes cookie banners, newsletter popups, and chat widgets before the capture. Bot checks, blank pages, and failed loads are never billed. Its MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 screenshots. Sign up for 1,000 free screenshots a month, with no card required.

Frequently asked questions

Are stories only for visual testing?

No. Stories are reusable isolated previews and can support documentation and testing. Visual comparison is one use of them.

Does a passing screenshot comparison prove a component works?

No. It checks rendered appearance against a baseline. Use interaction and accessibility checks for behavior and accessibility questions.

Should every prop combination become a story?

No. Preserve meaningful states and scenarios. Use Controls to explore useful input variations, and save combinations that teammates need to revisit or test.

Can a Figma prototype replace the coded preview?

No. A prototype helps communicate design behavior; the component explorer renders the implementation, and visual tests compare its output.