Protect an Angular editor from losing unsaved changes

• Use a typed functional CanDeactivateFn.
• Keep the component contract smaller than the component implementation.
• Return the asynchronous confirmation result to the Router.
• Do not subscribe inside the guard.
• Mark the form pristine only after a successful save.
• Do not treat an in-progress save as equivalent to persisted work.

1. Define a small interface exposing whether the editor can leave.
2. Let the component answer immediately when no unsaved changes exist.
3. Delegate confirmation UI to an injected service.
4. Return the result from the functional guard without manual navigation.
5. Test real navigation with RouterTestingHarness for all outcomes.

import {CanDeactivateFn} from '@angular/router';
import {Observable, of} from 'rxjs';
import {inject} from '@angular/core';

export interface PendingChanges {
  canLeave(): boolean | Observable<boolean>;
}

export const pendingChangesGuard: CanDeactivateFn<PendingChanges> = component =>
  component.canLeave();

export class ProfileEditor implements PendingChanges {
  private readonly confirmation = inject(LeaveConfirmation);
  readonly form = buildProfileForm();
  saving = false;

  canLeave(): boolean | Observable<boolean> {
    if (!this.form.dirty) return true;
    return this.confirmation.confirm(
      'You have unsaved changes. Leave this page?',
    );
  }

  save(): void {
    this.saving = true;
    this.api.save(this.form.getRawValue()).subscribe({
      next: () => { this.form.markAsPristine(); this.saving = false; },
      error: () => { this.saving = false; },
    });
  }
}

The guard decision is O(1); user-perceived latency depends on the confirmation UI and save operation.

• A failed save leaves the form dirty.
• A route replacement or browser back action goes through the same Angular guard.
• Closing the browser tab needs a separate beforeunload policy with limited custom UI.
• An active save remains protected until success marks the form pristine; a richer UI may disable navigation while saving.

• Navigate with a clean form and verify the confirmation service is not called.
• Reject confirmation and verify both URL and editor remain unchanged.
• Fail a save and verify a later navigation still prompts.
• Resolve confirmation asynchronously and verify the Router waits for it.

• Subscribing in the guard returns before the decision exists.
• Calling Router.navigate from the guard creates competing navigation.
• Marking pristine before the server confirms loses the warning on failure.
• Using only beforeunload misses in-application route navigation.