Undo isn't the
opposite of do.

Why undo breaks

A stack of previous states is the mental model everyone has. push(state) on every change, pop() to go back. It works for a counter. It dies in a real app — and it dies in five specific, visible ways. Every design in this course is an attempt to fix some of them, and every design keeps at least one.

The Unit Ladder

Before architecture, pick the unit of reversibility. From finest to coarsest:

The unit you pick is the answer your user hears when they press ⌘Z. Press undo after dragging a card: they expect the card to return — not the drag-shadow to jump 3 pixels left. The dashboard's unit is the transaction: one committed gesture.

Full snapshots — the Memento

The classic: before every change, copy the entire state tree and push it on the history stack. Undo = pop and restore. It's the Memento pattern — originator produces a snapshot, caretaker stores the stack. You already know it; that's the problem: it's the design people ship without choosing.

// Design 1 — full snapshots. Simple, and wrong at scale.
let past: DashboardState[] = [];
let future: DashboardState[] = [];

function commit(next: DashboardState) {
  past.push(current);            // whole tree, every time
  if (past.length > 50) past.shift();
  future = [];
  current = next;
}

function undo() {
  if (!past.length) return;
  future.push(current);
  current = past.pop()!;         // restore a full copy
}

Where it dies

Immer patches — store the delta

Don't store the tree — store the difference. Immer runs your reducer inside a proxy that records every mutation as a minimal, JSON-serializable patch: {op, path, value}. You get inverse patches for free: undo = apply inverse patches, redo = apply patches. Memory now scales with the change, not the state.

import { produceWithPatches, applyPatches, enablePatches } from "immer";
enablePatches();                       // required since Immer v6

const [next, patches, inversePatches] = produceWithPatches(
  state,
  draft => { draft.cards[3].column = "done"; }
);
// patches        = [{ op: "replace", path: ["cards",3,"column"], value: "done" }]
// inversePatches = [{ op: "replace", path: ["cards",3,"column"], value: "todo" }]
//           — the undo operation, generated, minimal, serializable ✨

function undo() {
  state = applyPatches(state, history.pop()!.inverse);   // apply the inverse
}
function redo() {
  state = applyPatches(state, future.pop()!.patches);    // apply the delta
}

Where it dies

Commands + inverse — the Command pattern

Model each operation as an object: what it does, what undoes it, both callable. Undo = pop the history and call command.undo(). This is the Command pattern from GoF — and it's how ProseMirror (the editor engine behind rich-text UIs) builds its undo history: every edit is a step that can be inverted.

interface Command {
  do(): void;
  undo(): void;          // explicit inverse — you write it
}

class MoveCard implements Command {
  do()    { cards[this.id].column = this.to; }
  undo()  { cards[this.id].column = this.from; }   // its inverse
}
history.push(new MoveCard(id, from, to));

function undo() { history.pop()!.undo(); }

Where it dies

Transactional replay — forward-only history

Now the mental-model flip. Stop storing before-states or inverses. Store an append-only log of semantic events — what the user did — and treat the current state as a projection of the log. Undo isn't the opposite of do. Undo is do, shorter: re-project the state from the log up to N−1. Redo is the same operation at N+1. One engine, one code path, no inverses to maintain.

type Event = {
  txId: string;        // assigned at INTENT time (pointerdown)
  type: "card.moved" | "card.added" | ...;   // semantic, not structural
  payload: Json;       // plain data — no closures
  ts: number;
};

const log: Event[] = [];              // append-only
let cursor = -1;                      // projection position
let checkpoint = { index: -1, state: initial };   // rolling

function commit(e: Event) {
  log.push(e);                        // atomic publication: 1 intent = 1 append
  cursor = log.length - 1;
  if (log.length % CHECKPOINT_EVERY === 0) checkpoint = { index: cursor, state: state };
}
function project(to: number) {        // undo AND redo are this one function
  const from = checkpoint.index > to ? 0 : checkpoint.index;
  let s = from === 0 ? initial : checkpoint.state;
  for (const e of log.slice(from + 1, to + 1)) s = apply(s, e);   // forward only
  state = s; cursor = to;
}

The five mechanisms, and which failure each kills

React 19: why async made this urgent

Classic undo assumed synchronous, single-dispatch updates: click → reducer → state → history push. React 19's actions and transitions break that assumption by design. An action can await, overlap another action, and commit in two phases. That's failure 04 (late completions) turned into a first-class language feature.

const [isPending, startTransition] = useTransition();  // React 19

function onDrop(card, to) {
  const txId = crypto.randomUUID();        // intent time — before awaits
  startTransition(() => {
    dispatch({ type: "card.moved", txId, card, to });   // optimistic
  });
  await save({ txId, card, to });          // network — may resolve LATE
}

// completion handler, 800ms later:
if (history.headTxId === txId) commit(txId);   // still on top → publish
else /* user undid meanwhile */ discardOrReopen(txId);

The Lab — make the failures visible

A real drag-and-drop dashboard running all four engines. Drag cards between columns, add and delete, then switch engines and press undo. Watch memory, history depth, and the transaction timeline react live. Toggle the failure switches to see each design break exactly where the theory says it will.

Choosing your unit

The talk refuses to prescribe one pattern — and so does this course. The question that matters: what does your user expect ⌘Z to reverse? Answer it, then walk the ladder.