ScaffoldMessenger in Flutter: SnackBars That Survive Navigation

A user deletes an item and you need to say “Deleted — Undo?” in under a second. That’s the SnackBar, and the widget that owns it is ScaffoldMessenger (docs.flutter.dev).

The One-Liner You’ll Use Everywhere

ScaffoldMessenger.of(context).showSnackBar(
  const SnackBar(content: Text('Message deleted')),
);

ScaffoldMessenger.of(context) looks up the nearest messenger — which MaterialApp installs for the whole app — so the call works from anywhere below it. This is a deliberate upgrade from the old Scaffold.of(context).showSnackBar(), which broke whenever you called it from a context above the Scaffold (a classic bug: calling it from the same build that creates the Scaffold).

Actions: Making SnackBars Useful

A SnackBar with an action turns information into recovery:

final messenger = ScaffoldMessenger.of(context);
messenger.showSnackBar(
  SnackBar(
    content: const Text('Report archived'),
    duration: const Duration(seconds: 4),
    action: SnackBarAction(
      label: 'UNDO',
      onPressed: () => _restore(report),
    ),
  ),
);

SnackBarAction keeps its own styling (it doesn’t inherit the snackbar’s inverse colors), so it stays legible on the elevated surface. The default duration is Duration(seconds: 4) — bump undo flows to 6–8 seconds so users can finish reading before it slides away.

Queueing and Replacement

Only one snackbar shows at a time. Calling showSnackBar while another is visible queues it. When you’d rather replace than queue — rapid-fire status updates — clear first:

final messenger = ScaffoldMessenger.of(context);
messenger.hideCurrentSnackBar(); // drop the pending one
messenger.showSnackBar(const SnackBar(content: Text('Syncing…')));

clearSnackBars() empties the entire queue, which is the right call in dispose-style teardown or when a route change makes old messages irrelevant.

Surviving Route Changes

This is ScaffoldMessenger’s reason for existing. Because the messenger lives above the Navigator, a snackbar shown on screen A continues animating after you push screen B — no more messages vanishing mid-animation because the Scaffold that owned them was disposed. Conversely, each Scaffold (in a nested-messenger setup, e.g. per-tab scaffolds) can host its own messenger so messages stay scoped to the right visual region:

ScaffoldMessenger( // scoped to this tab only
  child: Scaffold(
    body: TabBarView(...),
  ),
)

Accessibility and Design Rules

Material’s guidance is short: snackbars are for low-priority, transient messages — never for errors that need action (use a banner or dialog), and never as the only channel for critical information. Announce nothing extra manually: the SnackBar content is exposed to semantics, so keep the copy self-contained (“Saved”, not “It worked”).

Find the messenger, show the message, and let ScaffoldMessenger outlive the screen that created it — snackbars stop disappearing before users can act.