Optimistic Updates and Offline-First Patterns

Optimistic updates make applications feel instant — updating the UI immediately when the user takes an action, before the server confirms success. If the server returns an error, the update is rolled back. This pattern — update immediately, revert on failure — is the standard approach for mutation-heavy UIs where network latency would otherwise make every action feel sluggish. Combined with offline detection and a queued sync strategy, it produces an application that remains useful even when connectivity is intermittent.

Optimistic Update Patterns #

Error Recovery Strategy #

Complete Optimistic Update Implementation #

// ── Optimistic task store ─────────────────────────────────────────────────
@Injectable({ providedIn: 'root' })
export class TaskStore {
    private taskService = inject(TaskService);
    private toast       = inject(ToastService);

    private _tasks = signal<Task[]>([]);
    readonly tasks  = this._tasks.asReadonly();

    // ── Optimistic complete ───────────────────────────────────────────────
    completeOptimistic(id: string): void {
        // 1. Capture previous state for rollback
        const previous   = this._tasks();
        const prevStatus = previous.find(t => t._id === id)?.status;

        // 2. Apply optimistic update immediately
        this._tasks.update(tasks =>
            tasks.map(t => t._id === id
                ? { ...t, status: 'completed', completedAt: new Date().toISOString() }
                : t
            )
        );

        // 3. Send to server
        this.taskService.complete(id).subscribe({
            next: updated => {
                // Replace optimistic data with server-confirmed data
                this._tasks.update(tasks =>
                    tasks.map(t => t._id === id ? updated : t)
                );
            },
            error: err => {
                // 4. Rollback on failure
                this._tasks.set(previous);
                this.toast.error(`Failed to complete task: ${err.error?.message ?? 'Try again'}`);
            },
        });
    }

    // ── Optimistic delete ────────────────────────────────────────────────
    deleteOptimistic(id: string): void {
        const previous = this._tasks();
        const task     = previous.find(t => t._id === id);
        if (!task) return;

        // Optimistic removal
        this._tasks.update(tasks => tasks.filter(t => t._id !== id));

        this.taskService.delete(id).subscribe({
            error: err => {
                // Restore the item at its original position
                this._tasks.set(previous);
                this.toast.error('Failed to delete task');
            },
        });
    }

    // ── Optimistic create with temp ID ────────────────────────────────────
    createOptimistic(dto: CreateTaskDto): void {
        const tempId  = `temp_${Date.now()}`;
        const tempTask: Task = {
            _id:       tempId,
            title:     dto.title,
            status:    'pending',
            priority:  dto.priority ?? 'medium',
            tags:      dto.tags ?? [],
            user:      '',
            createdAt: new Date().toISOString(),
            updatedAt: new Date().toISOString(),
            _optimistic: true,   // flag for template to show pending indicator
        } as any;

        // Optimistic insert
        this._tasks.update(tasks => [tempTask, ...tasks]);

        this.taskService.create(dto).subscribe({
            next: created => {
                // Replace temp item with real item from server
                this._tasks.update(tasks =>
                    tasks.map(t => t._id === tempId ? created : t)
                );
                this.toast.success('Task created');
            },
            error: err => {
                // Remove the temp item
                this._tasks.update(tasks => tasks.filter(t => t._id !== tempId));
                this.toast.error('Failed to create task');
            },
        });
    }

    // ── Offline queue ─────────────────────────────────────────────────────
    private queue: Array<{ id: string; action: () => Observable<any> }> = [];
    private isOnline = signal(navigator.onLine);

    constructor() {
        window.addEventListener('online', () => {
            this.isOnline.set(true);
            this.flushQueue();
        });
        window.addEventListener('offline', () => this.isOnline.set(false));
    }

    queueOrExecute(dto: CreateTaskDto): void {
        if (this.isOnline()) {
            this.createOptimistic(dto);
            return;
        }

        // Offline: queue the operation
        const tempId  = `temp_${Date.now()}`;
        const tempTask = { ...dto, _id: tempId, _queued: true } as any;
        this._tasks.update(t => [tempTask, ...t]);

        this.queue.push({
            id: tempId,
            action: () => this.taskService.create(dto).pipe(
                tap(created => {
                    this._tasks.update(tasks =>
                        tasks.map(t => t._id === tempId ? created : t)
                    );
                }),
                catchError(err => {
                    this._tasks.update(tasks => tasks.filter(t => t._id !== tempId));
                    this.toast.error('Failed to sync task');
                    return EMPTY;
                })
            ),
        });
    }

    private flushQueue(): void {
        const pending = [...this.queue];
        this.queue    = [];
        from(pending).pipe(
            concatMap(item => item.action()),
        ).subscribe();
    }
}

// ── Template: visual feedback for optimistic state ────────────────────────
// In TaskCardComponent template:
// <div class="task-card"
//      [class.task-card--optimistic]="task._optimistic"
//      [class.task-card--queued]="task._queued">
//     <span *ngIf="task._optimistic" class="badge badge--saving">Saving...</span>
//     <span *ngIf="task._queued"    class="badge badge--queued">Queued (offline)</span>
// </div>

How It Works #

Step 1 — Snapshot Before Mutate Enables Clean Rollback #

Capturing const previous = this._tasks() before applying the optimistic update stores the entire state as a value (arrays and objects in signals are immutable by convention — update() returns new references). When the error handler calls this._tasks.set(previous), it restores exactly what the user saw before the action. This snapshot approach works regardless of how complex the update transformation was.

Step 2 — Temporary IDs Mark Unconfirmed Items #

Creating a temporary task with a temp_xyz ID allows the template to render it immediately and identify it later. When the server responds with the real task (including a MongoDB ObjectId), the store swaps temp_xyz for the real ID using tasks.map(t => t._id === tempId ? created : t). Components using trackBy: task._id will reuse the same DOM node since the ID changed — but the item data is updated in place.

Step 3 — Online/Offline Events Drive Queue Behaviour #

The browser fires window.ononline and window.onoffline events when network connectivity changes. The navigator.onLine property gives the current state on load. The offline queue accumulates operations while offline (with optimistic UI updates) and flushes them using concatMap (sequential, ordered) when the online event fires. concatMap ensures operations are applied to the server in the same order the user performed them.

Step 4 — Visual State Communicates Uncertainty to Users #

Optimistic items should be visually distinct from confirmed items. A “Saving…” badge, reduced opacity, or a spinning indicator tells the user “this looks right but is not yet confirmed.” This manages expectations — if a rollback occurs, the user understands why the item disappeared or changed back. Silently reverting without any visual indication feels like a bug.

Step 5 — Server Response Replaces Optimistic Data #

After a successful server response, always replace the optimistic data with the server-confirmed data. The server may have enriched the data (adding createdAt, default values, computed virtuals) or slightly modified it (trimming the title, normalising tags). Using the server’s response ensures the displayed data exactly matches what is in the database — preventing subtle inconsistencies from accumulated optimistic assumptions.

Common Mistakes #

Mistake 1 — Not capturing previous state before optimistic update #

❌ Wrong — cannot roll back without the previous state:

// Optimistic delete — no snapshot:
this._tasks.update(tasks => tasks.filter(t => t._id !== id));
// On error: cannot restore item — it is gone from the signal!

✅ Correct — snapshot first:

const previous = this._tasks();
this._tasks.update(tasks => tasks.filter(t => t._id !== id));
// On error:
this._tasks.set(previous);   // full restore

Mistake 2 — Using optimistic updates for high-risk operations #

❌ Wrong — optimistic payment processing shows “Payment successful” before server confirms:

this._balance.update(b => b - amount);  // show new balance immediately
this.paymentService.charge(amount).subscribe({
    error: () => this._balance.update(b => b + amount)  // rollback
    // Rollback after "Payment successful" is extremely confusing UX
});

✅ Correct — confirmed update for financial or irreversible operations:

this._processing.set(true);
this.paymentService.charge(amount).subscribe({
    next: () => { this._balance.update(b => b - amount); },
    error: () => { this.toast.error('Payment failed') },
    complete: () => this._processing.set(false),
});

Mistake 3 — Not providing visual feedback for queued offline operations #

❌ Wrong — offline task looks identical to confirmed task — user confused on reconnect:

<app-task-card [task]="task"></app-task-card>
<!-- No indication that this task has not been saved to the server -->

✅ Correct — show offline/queued state visually:

<app-task-card [task]="task" [class.task--queued]="task._queued"></app-task-card>
<!-- CSS: .task--queued { opacity: 0.7; border-left: 3px solid orange; } -->

Quick Reference #