Axon 911 Frontend DocsAxon 911 Frontend Docs
Axon 911 Frontend Docs
    Loading navigation…
U
User
Switch to light mode
  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 Dialog 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 Banner instead.
Incident saved to review queueSupervisor Dana Ortiz will review within 48 hours.
Reset zoom to 100%
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 Dialog.
  • Long policy text—use Banner or link to docs.
  • Errors that require field-level remediation—use inline validation and a Banner 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
  • Banner for persistent inline alerts.
  • Dialog 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