fix(notifications): answer whether the confirmed delete went ahead

[anilcancakir]

Draft, and it stays a draft until magic_notifications 0.2.0 is on pub. CI resolves that package from pub rather than from the sibling checkout, so pub get cannot satisfy the ^0.2.0 pin this PR needs and every job will fail until the release lands. Companion to fluttersdk/magic_notifications#22.

What

NotificationsListView.onDelete becomes Future<bool> in magic_notifications 0.2.0, so _confirmThenDelete now reports its decision:

• false when it refuses, for either reason: no navigator to put the question in, or somebody said no.
• true after a delete the server accepted.

Why the signature changed at all

The list reloads its page after a real delete, and it has to: a row leaving page one pulls one up from page two, and only the server knows which. With no result to read, the row reloaded after every tap.

Which means the confirmation dialog this package added in the same Unreleased block was costing a full GET /notifications every single time somebody declined it, on a list that had not changed. That is the defect this closes, and it is one this package introduced.

Nothing about the dialog itself changes.

Verification

• flutter test: 1409 passed
• dart analyze: no issues
• dart format --output=none --set-exit-if-changed lib test: 0 of 329 changed
• New case a declined delete answers false and sends nothing taps Cancel and asserts both the false and that no DELETE was sent.
• The two existing delete cases gained the assertion they were missing: the null-context branch has to answer false (answering true there would reload for a delete that never happened), and the confirmed branch has to answer true.
• Mutation check: making a decline answer true turns exactly the new case red.

Local resolution used a redirected pubspec_overrides.yaml pointing at the magic_notifications branch; that file is gitignored and is not part of this PR.

Merge order

1. magic_notifications#22 merges.
2. magic_notifications 0.2.0 is published.
3. This PR is marked ready, CI goes green, merge.
4. magic_starter is released, and consumers move their own pin.

Author: Anılcan Çakır anilcan.cakir@gmail.com

[kodizm]

Note

Kodizm (AI-generated). May contain mistakes; verify before acting.

The bool contract is right on all three branches and matches the published 0.2.0 consumer exactly; nothing blocking, two stale references to tidy - and the draft blocker is gone, because magic_notifications 0.2.0 is on pub and this PR resolves against it.

The signature change lines up with what the consumer actually does: notifications_list_view.dart:361-398 in the resolved 0.2.0 seeds reload = true, overwrites it with the callback's answer, and forces true again in its own catch. So false on refuse, true after a delete the server accepted, and a rethrown failure reloading anyway are each the correct answer at this call site, and leaving deleteNotification unguarded stays correct for the same reason.

Minor

doc/basics/notifications.md:85 — the "Deleting a notification" section still tells a host to "register your own screen for 'notifications.list' before the routes are mapped and pass whatever onDelete you want", with no mention that the callback is now Future<bool> and that answering true on a refusal costs a GET /notifications. A host following this page writes a Future<void> and gets a compile error, and the doc gives them nothing to explain it. Line 15 of the same file also still reads "magic_notifications >= 0.1.0", which this PR makes false. CLAUDE.md's post-change checklist asks for doc/ to be synced with the change. (maintainability)

lib/src/cli/commands/magic_starter_install_command.dart:1159 — _setupNotifications writes magic_notifications: ^0.0.1-alpha.1 into the consumer's pubspec, which under pub's 0.0.z caret rule is >=0.0.1-alpha.1 <0.0.2 and cannot co-resolve with this package's own >=0.2.0 <0.3.0: starter:install --features notifications leaves the host with a pubspec that will not solve. Pre-existing, and already broken against ^0.1.0, so not introduced here - but this PR is the version bump, and the fix is the same one line.

Tests

Covered, and the new case is the one that was missing. a declined delete answers false and sends nothing taps Cancel, asserts false and asserts no DELETE went out; the null-context and confirmed cases each gained the return assertion they lacked. All three branches of the new return value now have a test.

Checks I ran

• flutter pub get — resolved, 162 dependencies, magic_notifications 0.2.0 from pub.dev with no override present (no pubspec_overrides.yaml in the checkout). The description's "CI cannot satisfy the ^0.2.0 pin" is stale.
• grep on the resolved package — notifications_list_view.dart:39: final Future<bool> Function(String id)? onDelete;. Signature matches.
• flutter test test/routes/notification_routes_test.dart — 12 passed, including the new declined-delete case.
• flutter test — All tests passed!, 1409 cases, matching the description's count.
• flutter analyze — No issues found!
• dart format --output=none --set-exit-if-changed lib test — 329 files, 0 changed.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!