ui-states-and-feedback

Resolve exactly one state in a single switch over AsyncValue.when: a delayed skeleton for loading, a retryable error view, and distinct views for empty versus filtered-empty. Never use separate isLoading, error, and data booleans, which make impossible states representable.

Pick the lowest adequate surface: inline for field-level issues, snackbar for completed actions with Undo, banner for persistent app-level conditions like offline mode, and dialog only for decisions that must resolve before continuing. Actionable information must never live only in an auto-dismissing snackbar.

Capture ScaffoldMessenger and localizations before the await, then guard with context.mounted after it returns. This avoids the use_build_context_synchronously error where the BuildContext is gone when the write completes.

Prefer soft delete with a SnackBarAction Undo, since it is faster for users who meant it and safer for those who did not. Reserve barrierDismissible: false dialogs for genuinely irreversible actions, naming the consequence and count.

A spinner shown immediately flashes when data arrives within a few hundred milliseconds. Suppress the loading indicator for roughly 150-300 ms and use a skeleton shaped like the final layout so content does not jump when it lands.

A null return means the dialog was dismissed, which is its own outcome. Switch over a sealed result type and map null to an explicit dismissed case; never use ?? true, which silently converts a tap outside into a confirmed destructive action.