Unsaved changes prompt

Problem Context

• The surface has editable values that can differ from the last saved record.
• A close, cancel, object switch, tab switch, mode switch, replace, or route action can remove the current edit buffer.
• The product can identify the object and at least a useful summary of changed fields.
• Users need to choose whether to keep editing, save first, review changes, or intentionally discard local edits.

Selection Rules

• Choose unsaved changes prompt when a user action inside the product would abandon or replace dirty local edits before they are saved.
• Use exit warning when the trigger is broader page, browser, route, reload, external-link, or sign-out departure rather than a focused editor close or object switch.
• Use autosave form when reliable background saving makes abandonment safe or when the main job is continuous progress persistence.
• Use autosave recovery when saving has already failed or become uncertain and users need retry, copy, compare, or restore evidence.
• Use draft state when the unsaved work is a durable unpublished object that can be resumed later from lists or deep links.
• Use confirmation dialog for explicit consequential commands such as Delete, Cancel application, or Discard draft; an unsaved changes prompt is specifically about dirty edit-buffer loss.
• Show the prompt only when dirty state is real; do not prompt for clean editors, read-only views, or recoverable drafts already saved elsewhere.
• If Save changes is offered, keep the prompt open or show a saving state until the save succeeds; do not close the editor after failed save.
• If Discard changes is offered, label it as discard and identify the affected object or fields.
• Offer Review changes when users may need to inspect field-level differences before deciding.

Required States

• Clean editor state with no prompt.
• Dirty editor state with changed-field tracking.
• Close, cancel, object switch, or mode switch attempted state.
• Prompt open with object name and changed-field summary.
• Review changes state showing before and after values or changed sections.
• Save in progress state that blocks duplicate close or switch actions.
• Save failed state that keeps the editor open with values intact.
• Saved and continue state that closes or switches after success.
• Discarded state that clears the dirty buffer intentionally.
• Keep editing state that returns focus and preserves values.

Interaction Contract

• Opening the prompt never clears the dirty values.
• Keep editing closes the prompt, preserves all local values, and returns focus to the editor or triggering control.
• Review changes shows what changed before the user saves or discards.
• Save changes sends the current dirty values once, disables duplicate save and discard while saving, and continues only after success.
• A failed save leaves the prompt or editor visible, explains the failure, and keeps the unsaved values editable.
• Discard changes requires a deliberate action and clears only the named dirty buffer.
• After save, discard, or reset to clean state, the same close or switch action does not prompt again.

Implementation Checklist

• Track dirty state from actual field values, not from opening an editor.
• Store changed field names, original values when safe to show, current values, target close or switch action, and save request state.
• Intercept close, cancel, record switch, tab switch, inline edit exit, modal dismissal, replacement, and route actions that would destroy the dirty buffer.
• Use explicit button labels such as Keep editing, Review changes, Save changes, and Discard changes.
• Make save idempotent or disable repeated save while a request is in flight.
• Keep values in memory and visible after save failure.
• Clear dirty state after confirmed save, explicit discard, reset, or successful autosave that truly covers the latest values.
• Test clean close, dirty close, object switch, failed save, double activation, discard, review, keyboard Escape, focus return, screen reader labels, and mobile dismissal gestures.

Common Generated-UI Mistakes

• Prompting when nothing changed.
• Using OK and Cancel labels that hide whether edits will be saved, discarded, or preserved.
• Closing after Save even when the save request failed.
• Discarding all editor state when only one embedded panel was dirty.
• Showing a warning but omitting a way to keep editing.
• Replacing the dirty object during a tab or record switch without a save or discard decision.
• Relying on a disappearing toast to say edits were not saved.

Critique Questions

• What exact object or fields are dirty?
• Which user actions can destroy or replace the dirty edit buffer?
• Can users inspect changed fields before deciding?
• Does Save complete before close, cancel, or switch continues?
• What happens when Save fails or the user activates Save twice?
• Does Keep editing preserve values and return focus predictably?
• Does the prompt disappear for clean state?