Prepared Docs

Prepared Docs

⌘K

    Loading navigation…

User

  1. Components
  2. Snackbar
  3. Usage

Snackbar

Usage

Overview

Snackbar delivers lightweight, transient feedback—save confirmations, background-job completions, non-blocking errors—without stealing focus the way a Modal does. Position and duration should respect operator concentration; stack height must stay manageable in incident-heavy shifts where a dozen events might fire in a minute. The mental model is "short acknowledgement that disappears on its own"; if the message must be seen until resolved, reach for Callout instead.

Incident saved to review queue

Supervisor Dana Ortiz will review within 48 hours.

View

When to use

  • Confirmations that don't need acknowledgment to proceed ("Saved", "Copied").
  • Background task results operators can act on optionally via an inline action link.
  • Soft errors where a retry is the natural next step and the rest of the console should stay usable.

When not to use

  • Critical safety decisions—use Modal.
  • Long policy text—use Callout or link to docs.
  • Errors that require field-level remediation—use inline validation and a Callout summary.

Types

  • Success, Error, Warning, Info, Default. Match the semantic variant to the condition faithfully; don't use Error for marketing emphasis.

Positioning

  • Place snackbars away from primary incident indicators operators watch continuously; test against real dispatch layouts, including dual-monitor setups.
  • A single position per region is the baseline; avoid sprinkling snackbars in every corner of the page.

Content guidelines

  • Titles short; descriptions add detail; actions are verb-led ("Retry", "View log"). Localize via formatMessage.
  • Do not expose secrets or PII in snackbar copy. Assume screen sharing during demos.

Behavior and states

  • Duration. Short durations for confirmations; longer for warnings. Infinite duration is valid only when close is mandatory and justified.
  • Stacking. Limit concurrent snackbars. Older confirmations may auto-dismiss when new critical errors arrive—define policy per feature.
  • Undo. Offer an undo action only when the implementation truly supports reversal.

Best practices

Do

  • Keep snackbars away from regions operators stare at constantly.
  • Update the underlying UI state alongside an error snackbar so the failure is visible beyond the toast.

Don't

  • Stack so many snackbars that operators can't read them. Batch or summarize instead.
  • Rely on a snackbar as the only error surface for failed saves.

Accessibility

Timed dismissal should not remove critical messages before screen reader users can reach them—extend duration or persist the message for important Error types per policy. Action links must be keyboard focusable. See Accessibility for the full contract.

Related Components

  • Callout for persistent inline alerts.
  • Modal for blocking confirmations.
  • Progress for long-running operations with progress bars.

Previous

Slider / Accessibility

Next

Snackbar / API and Development

On this page

Overview
When to use
When not to use
Types
Positioning
Content guidelines
Behavior and states
Best practices
Accessibility
Related Components