todo-app/lib/ui/confirm.dart
Krzysztof Rudnicki e103261bc8 Confirm before deleting a note
Both delete paths -- the per-note actions sheet and the detail screen -- deleted
immediately, with no confirmation and no undo. With a pointer that is merely
risky: you have to travel to the control and press it. With a keyboard it is
one Tab away from a Return you were about to press anyway, and the note is gone
with nothing to recover it.

The confirmation is built so the SAFE option is what a reflexive keypress hits:
Cancel is autofocused, Escape dismisses as "no", and the destructive button is
error-coloured but deliberately not the default action. Escape is bound
explicitly rather than relying on the barrier, because the desktop surface here
is a Chrome --app window where that cannot be assumed -- and a confirmation the
keyboard cannot back out of is worse than no confirmation at all.

The actions sheet also gains isScrollControlled. Default bottom sheets cap at
9/16 of the viewport, i.e. ~432px on a 768px screen, and this sheet's height
grows with the note title and its chip rows -- so Delete could be clipped out of
reach on the very screen this app is used on.

The two existing delete tests correctly failed once confirmation landed; both
now go through the dialog, and each gains a cancel-keeps-the-note counterpart so
the negative path is covered too. 204 tests, 100% line coverage held.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-07-30 16:31:15 +02:00

85 lines
2.7 KiB
Dart

/// Confirmation for destructive actions.
library;
import 'package:flutter/material.dart';
import 'package:flutter/services.dart';
/// Asks the user to confirm a destructive action, returning true if they do.
///
/// Exists because "delete note" had no confirmation and no undo on either
/// path: the actions sheet and the detail screen both deleted immediately.
/// With a pointer that is merely risky — you have to travel to the control and
/// press it. With a keyboard it is one Tab away from a Return you were about
/// to press anyway, and the note is gone with nothing to recover it.
///
/// Defaults are chosen so the *safe* option is what a reflexive keypress hits:
/// Cancel is autofocused, and Escape dismisses. The destructive button is
/// styled with the error color but is deliberately not the default action.
///
/// Returns false when dismissed by Escape, by the barrier, or by Cancel.
Future<bool> confirmDestructive(
BuildContext context, {
required String title,
required String message,
String confirmLabel = 'Delete',
String cancelLabel = 'Cancel',
}) async {
final confirmed = await showDialog<bool>(
context: context,
builder: (dialogContext) => _ConfirmDialog(
title: title,
message: message,
confirmLabel: confirmLabel,
cancelLabel: cancelLabel,
),
);
return confirmed ?? false;
}
class _ConfirmDialog extends StatelessWidget {
const _ConfirmDialog({
required this.title,
required this.message,
required this.confirmLabel,
required this.cancelLabel,
});
final String title;
final String message;
final String confirmLabel;
final String cancelLabel;
@override
Widget build(BuildContext context) {
return CallbackShortcuts(
// Escape dismisses as "no". Flutter's own barrier handles this on most
// platforms, but the desktop surface here is a Chrome `--app` window
// where that cannot be assumed, and a confirmation the keyboard cannot
// back out of is worse than no confirmation at all.
bindings: {
const SingleActivator(LogicalKeyboardKey.escape): () =>
Navigator.of(context).pop(false),
},
child: AlertDialog(
title: Text(title),
content: Text(message),
actions: [
TextButton(
// Autofocused so the reflexive Return presses Cancel, not Delete.
autofocus: true,
onPressed: () => Navigator.of(context).pop(false),
child: Text(cancelLabel),
),
TextButton(
style: TextButton.styleFrom(
foregroundColor: Theme.of(context).colorScheme.error,
),
onPressed: () => Navigator.of(context).pop(true),
child: Text(confirmLabel),
),
],
),
);
}
}