Design undo and redo

Requirements exploration

Undo looks like a two-line feature: keep a list of old states, go back one when the user presses Cmd+Z. That version works in a to-do app demo. It breaks in a real editor the first time a user drags a shape (60 history entries for one drag), types a sentence (one entry per letter), or presses undo while a teammate is editing (the teammate's work disappears). So the first five minutes go to questions whose answers change the design.

Questions to ask first

• Whose changes does undo reverse? Mine only, or the last change anyone made? In a shared document the answer is always "mine", and that one answer is the hardest part of the design.
• What is one step? A whole drag, or every pixel of it? A word, a sentence, or each letter? The browser reports about 60 pointermove events a second during a drag on a 60 Hz screen (more on faster screens), so grouping is not optional.
• What can't be undone? Sending an invite email, publishing a form, charging a card. These leave the browser, so we need a different answer for them.
• Does history survive a reload? Most editors say no. The document is safe on the server; the history is a convenience for the session.
• Does undo restore selection and scroll? Users expect the changed objects to be selected and visible after an undo, but they don't expect Cmd+Z to undo a scroll.
• How big can a document get? 50 cards on a board and 5,000 shapes on a canvas need different memory plans.
• Is this one editor or a shared module? Here it's shared, so the history module can't know what a card or a shape is.

Functional requirements

• Undo and redo every document change the user made: create, delete, move, resize, edit text, change a property, reorder.
• Group events into steps the user would name: one drag is one step, a burst of typing is one step, "Align 12 shapes" is one step.
• Shortcuts: Cmd+Z and Cmd+Shift+Z on macOS; Ctrl+Z, Ctrl+Y, and Ctrl+Shift+Z on Windows and Linux. Toolbar buttons and an Edit menu entry with the step's name, such as "Undo move card".
• Undo only your own changes when others edit the same document, without erasing theirs.
• Every undo and redo is saved to the server like any other edit.
• Actions with effects outside the document (emails, payments, publishing) get a short undo window instead of a history entry.

Non-functional requirements

A quick estimate shows why grouping and size matter from the start. A busy user makes about one meaningful edit every 10 seconds, or roughly 1,000 steps in a three-hour session. Without grouping, the same session produces tens of thousands of raw changes: a single 2-second drag alone is 120 pointermove updates. So the 200-step limit covers about the last half hour of real work, which is what people actually undo.

Out of scope

• Version history ("restore this document as it was last Tuesday"). It's a server feature with stored snapshots, not session undo, though the two can share ideas.
• The text editor's own internal undo. A rich-text editor like ProseMirror or Lexical keeps its own history; we'll decide how it plugs in, but not rebuild it. The rich-text editor guide covers it.
• The sync engine itself. We assume edits already flow to the server as operations; the Figma and Google Docs guides cover how.

What makes undo hard

Before picking any data structure, name the properties of the problem. Each one drives a later chapter, and an interviewer who hears them early knows you've built this before.

• Events are not steps. The browser speaks in keydown, input, and pointermove events. The user thinks in actions: "I moved the card", "I typed a title". Someone has to turn hundreds of events into a handful of named steps.
• Undo is a write. Pressing undo changes the document. That change must be saved, synced to other people, and checked by the server, just like the original edit. The server may refuse it.
• The document is shared. Between your edit and your undo, teammates may have changed the same objects. Undo has to reverse your change without destroying theirs, and sometimes it can't do both.
• Not everything belongs in history. Selection, scroll, zoom, open panels, and the current route all change constantly. Recording them makes undo useless. Ignoring them makes undo disorienting.
• Some effects leave the browser. An email that was sent can't be pulled back by popping a stack. Those actions need a time window or a compensating action instead.
• History grows without end. A three-hour session can produce about 1,000 steps, and tens of thousands of raw changes. Without a budget, history quietly becomes the biggest object in the tab.
• Several things own the keyboard. A focused text field has the browser's own undo stack. A rich-text editor has its own. The app has one more. Cmd+Z must go to the right one.
• It's a shared module. The history can't know what a card, a shape, or a form field is. It must work on any document that can describe its changes.

Notice what's missing from that list: drawing the buttons. The visible part of undo is two icons and a shortcut. Almost all the design work is in deciding what to record, how to keep it small and valid, and how it travels to the server and to other people. The rest of the guide takes these properties one at a time, starting with the most basic one: what a history entry stores.

Snapshots or operations: how to remember the past

The first real decision is what one history entry stores, and there are two families. Snapshots store what the whole document looked like. Operations store what changed and how to reverse it. Everything else (memory, server saves, multiplayer) follows from this choice.

The naive version and where it breaks

The simplest undo deep-copies the document before each change with structuredClone(doc) and pushes the copy onto a stack. Undo pops the stack and swaps the copy in. It's correct by construction, and for a form builder with 30 fields it's fine: each copy is a few kilobytes.

Now take the canvas. 5,000 shapes at about 300 bytes of JSON each is 1.5 MB per copy, and in the JavaScript heap objects take more room than their JSON text. 200 steps is over 300 MB of history to move three shapes now and then. Each copy also costs several milliseconds of cloning on every edit, and with multiplayer, swapping in an old copy erases every change a teammate made since.

Getting inverses for free with Immer patches

Hand-writing an inverse for every action is where command-based undo goes wrong. Immer, the library behind Redux Toolkit's reducers, can record changes as you make them. produceWithPatches runs your ordinary mutating code on a draft and returns three things: the next state, the forward patches, and the inverse patches.

A patch is a plain object describing one change, in a format close to JSON Patch (RFC 6902), except that path is an array of keys instead of a string. applyPatches(state, patches) replays a list of them. The feature is opt-in since Immer 6: call enablePatches() once at startup.

import { enablePatches, produceWithPatches, applyPatches } from "immer";

enablePatches(); // once, at startup

const [next, redo, undo] = produceWithPatches(doc, (draft) => {
  draft.shapes["s1"].x = 100;
  draft.shapes["s2"].x = 140;
});
// redo: [{ op: "replace", path: ["shapes", "s1", "x"], value: 100 }, ...]
// undo: [{ op: "replace", path: ["shapes", "s1", "x"], value: 0 }, ...]

history.push({ label: "Move 2 shapes", redo, undo });
setDoc(next);

// Later, when the user presses Cmd+Z:
const entry = history.undo();
if (entry) setDoc((d) => applyPatches(d, entry.undo));

Patches give us the size of operations with the convenience of snapshots, with two cautions. First, patches into arrays use indexes (["cards", 3]), and an index goes stale as soon as anything is inserted before it. That's why the document should be normalized: objects in maps keyed by stable ids, with order stored as a separate field such as a fractional position, as the normalization lesson and the kanban board guide explain.

Second, a delete's inverse is an add patch carrying the whole object. Deleting 500 shapes produces about 150 KB of inverse, which matters for the memory budget later.

The history stack: past, present, and future

With operations chosen, the history itself is two stacks around the document. Past holds the steps you can undo, newest on top. Future holds the steps you've undone and can redo. The document itself is the present.

Undo moves the top of past to the top of future and applies its inverse ops; redo moves it back and applies its forward ops. The Redux docs describe the same shape (past, present, future) for snapshot-based undo. With operations, the present is simply the live document.

type Entry = { id: string; label: string; redo: Op[]; undo: Op[] };
type History = { past: Entry[]; future: Entry[] };

function record(h: History, e: Entry): History {
  return { past: [...h.past, e], future: [] }; // a new edit clears redo
}

function undo(h: History, apply: (ops: Op[]) => void): History {
  const e = h.past.at(-1);
  if (!e) return h;
  apply(e.undo);
  return { past: h.past.slice(0, -1), future: [...h.future, e] };
}

function redo(h: History, apply: (ops: Op[]) => void): History {
  const e = h.future.at(-1);
  if (!e) return h;
  apply(e.redo);
  return { past: [...h.past, e], future: h.future.slice(0, -1) };
}

Try it below. Make a few edits, undo some, then make a new edit and watch the future stack empty. Switch the model to see what each entry would cost on a 5,000-shape canvas, turn grouping on and off, and lower the limit to watch the oldest entries fall off.

What clears the redo stack

The rule "a new edit clears redo" needs care about what counts as a new edit. Get it wrong one way and redo vanishes when the user just clicked somewhere. Get it wrong the other way and redo replays a change on top of a document it no longer fits.

Branching history, and why most apps throw the branch away

Say you make edits A, B, C, D, undo twice back to B, then make edit E. C and D are now on a branch nobody can reach with undo and redo. Most editors discard them, and users rarely notice. But it does lose work: a user who undid a little too far and then nudged something has lost C and D for good.

What counts as one undo step

Users undo intentions, not events. If one drag records 60 entries, the user presses Cmd+Z 60 times to move a card back, and decides undo is broken. If a whole minute of typing is one entry, one undo wipes a paragraph. Grouping decides where one step ends and the next begins.

A drag as one step

On pointerdown the board opens a transaction labelled "Move card". Each pointermove updates the card's position in the document so other views and collaborators see it move, but the history records nothing yet. On pointerup the transaction commits one entry whose undo is "x back to where it started" and whose redo is "x to where it ended".

On Escape or pointercancel (the browser took the pointer for a scroll, or the window lost focus) the transaction cancels: it applies the inverse and records nothing. Held arrow-key nudges work the same way, closing the group about 500 ms after the last key, as the Figma guide describes.

How two entries merge

Merging two operation entries is mechanical. The forward ops run in order, so the merged redo is the first entry's redo followed by the second's. Undo runs backwards, so the merged undo is the second entry's undo followed by the first's. If both entries set the same field, compact them (keep only the last new value and the first old value), which turns 60 position updates into one pair.

function merge(a: Entry, b: Entry): Entry {
  return {
    ...a,
    redo: compact([...a.redo, ...b.redo]),  // a then b
    undo: compact([...b.undo, ...a.undo]),  // undo b first, then a
  };
}

// A later "replace" of the same field overwrites the earlier one.
function compact(ops: Op[]): Op[] {
  const out: Op[] = [];
  let seen = new Map<string, number>(); // path -> index in out
  for (const op of ops) {
    const key = op.path.join("/");
    const i = seen.get(key);
    if (op.op === "replace" && i !== undefined) {
      out[i] = op; // nothing in between touched this path
      continue;
    }
    // Adds, removes, and writes to a parent or child path are barriers.
    const overlaps = [...seen.keys()].some((k) => k.startsWith(key + "/") || key.startsWith(k + "/"));
    if (op.op !== "replace" || overlaps) seen = new Map();
    if (op.op === "replace") seen.set(key, out.length);
    out.push(op);
  }
  return out;
}

Rules for typing

• Start a new step if more than 500 ms passed since the last keystroke.
• Start a new step after a word boundary: the first letter typed after a space, punctuation, or newline.
• Start a new step when the kind changes: typing after deleting, or deleting after typing.
• Start a new step when the caret jumps somewhere not adjacent to the last edit.
• Cap a group at about 2 seconds or 100 characters, so continuous fast typing still produces several steps.

The recorder as a state machine

Transactions, coalescing, and applying undo all touch the same stacks, and bugs hide where they overlap: an undo pressed in the middle of a drag, or the ops that undo itself applies being recorded as a brand new edit. Modelling the recorder as a small state machine, as the state machines lesson recommends, makes those cases explicit. While undo or redo is applying, recording is off. While a transaction is open, undo first cancels it.

What is undoable, and what isn't

Undo promises "put it back the way it was". That promise only holds for state the app fully controls. So for every kind of state, decide: is it a step, is it restored alongside a step, or is it outside history entirely?

Selection deserves a closer look. If selection changes were steps, a user who clicked around five shapes and then pressed undo would get five useless undos before anything in the document changed. But if undo ignores selection completely, undoing a delete brings back a shape the user can't find.

The middle path: each entry stores selectionBefore and selectionAfter. Undo restores selectionBefore, redo restores selectionAfter, and either one scrolls the restored objects into view if they're outside the viewport.

Edits on another page

A canvas with several pages, or a form builder with several steps, raises a question: if my last edit was on page 2 and I'm now on page 3, what does undo do? One history per page means undo only reverses what's on the current page. That's predictable, but surprising when you just made a change and switched pages.

One history per document means undo can change something you can't see, so it must switch to page 2 first and select the restored objects. Design tools commonly keep one history per document and bring the change into view, and this design does the same. Either way, switching pages is never a step.

Actions with effects outside the document

Some actions on the board reach the outside world: inviting a teammate sends an email, and publishing a form makes it public. A history entry can't recall an email. Pretending otherwise is the worst outcome: undo shows the invite gone, and the email is already in the teammate's inbox.

Keeping history inside a memory budget

History has no natural end: a designer working for three hours can make about 1,000 steps. Operations keep most steps tiny, but a few are large. Deleting 500 shapes stores all 500 so undo can restore them (about 150 KB), and pasting a big table into the form builder can be more. Without limits, history becomes the largest thing in the tab, and nobody notices until a laptop starts swapping.

Two limits, not one

A limit on entries alone (keep 200) is what most libraries offer, and it's a good start. But 200 tiny moves is about 60 KB, while 200 big deletes is about 30 MB. So the history keeps two limits: a maximum number of entries (200) and a maximum estimated size in bytes (20 MB).

When either limit is exceeded, the oldest entries are dropped until both fit. The oldest end is the right one to cut: users undo recent mistakes, almost never something from an hour ago.

const MAX_ENTRIES = 200;
const MAX_BYTES = 20 * 1024 * 1024;

// Estimated once, when the entry is committed.
function estimateBytes(e: Entry): number {
  return 2 * (JSON.stringify(e.redo).length + JSON.stringify(e.undo).length);
}

function enforceLimits(h: HistoryState) {
  while (h.past.length > MAX_ENTRIES || h.bytes > MAX_BYTES) {
    const dropped = h.past.shift();
    if (!dropped) break;
    h.bytes -= dropped.bytes;
  }
}

Making big entries smaller

• Store references, not payloads. An image added to the canvas keeps its asset id in the op, never the bytes. The file stays on the server (and in the HTTP cache), so the entry is 200 bytes instead of 2 MB.
• Compact before storing. Fold repeated replaces of the same field when a group commits, as in the grouping chapter. A run of 40 arrow-key nudges on 3 shapes, coalesced into one step, shrinks from 120 ops to 3.
• Tombstones instead of copies. If deleted objects stay in the document as tombstones, the undo of a delete is "set deleted to false", not a full copy of the object. That moves the cost into the document, where it's shared with sync and version history.
• Compress old entries, maybe. Entries older than the last 20 could be serialized and compressed with the CompressionStream API. It's asynchronous and rarely worth the complexity when ops are already small; try the other three first.

Lifecycle and leaks

Keep one history per open document, in a Map keyed by document id, and delete it when the document closes. A history that outlives its document holds every deleted object forever. Entries must hold plain data only: no DOM nodes, no component instances, no closures over the old document. Any of those keeps far more memory alive than the entry's size suggests, and the byte estimate can't see it.

Keys, buttons, and screen readers

Most undo happens from the keyboard, in bursts: people press Cmd+Z four or five times quickly and watch. So the shortcut has to be right on every platform, it has to go to the right history, and the result has to be visible and announced.

The shortcuts by platform

// userAgentData.platform is "macOS"; navigator.platform is "MacIntel".
const isMac = /mac|iphone|ipad/i.test(
  navigator.userAgentData?.platform ?? navigator.platform,
);

function onKeyDown(e: KeyboardEvent) {
  if (e.isComposing || e.altKey) return;    // IME input, other shortcuts
  const mod = isMac ? e.metaKey : e.ctrlKey;
  if (!mod) return;
  const key = e.key.toLowerCase();          // Shift may report "Z"
  const isUndo = key === "z" && !e.shiftKey;
  const isRedo = (key === "z" && e.shiftKey) || (!isMac && key === "y");
  if (!isUndo && !isRedo) return;
  if (isNativeTextField(e.target)) return;  // let the browser's undo run
  e.preventDefault();
  if (isUndo) history.undo(); else history.redo();
}

window.addEventListener("keydown", onKeyDown);

Native text fields have their own undo

Every input and textarea keeps its own undo stack, managed by the browser. If focus is in the form builder's "Field label" input and the user presses Cmd+Z, they mean "undo my last few letters", not "undo the field I added a minute ago". That native stack is fragile: values set from JavaScript (input.value = ...) are not on it, and they can break it.

The deprecated document.execCommand() is the one API whose edits (insertText, for example) land on the native stack, as MDN notes, and execCommand("undo") undoes the last step on that stack. Neither is a base for an app's history, which is one more reason to keep the native stack short-lived.

Editable elements get one more signal. When the user picks Edit, Undo from the browser's menu or the context menu, there's no keydown at all. Instead the browser fires a beforeinput event whose inputType is historyUndo or historyRedo (from the Input Events specification) on the focused input, textarea, or contenteditable element.

The specification makes these two input types cancelable, so ProseMirror and CodeMirror listen for them, cancel the browser's undo, and run their own history. Check event.cancelable before relying on preventDefault(), since MDN warns that some beforeinput events can't be cancelled. The event never fires on non-editable elements, so a canvas whose focus sits on a plain element must offer its own Edit menu and buttons.

Buttons, labels, and the Edit menu

• Name the step. The tooltip and menu item say "Undo move card" and "Redo rename field", read from the top entry's label. Users undo with more confidence when they know what will happen.
• Disabled state. When canUndo is false, the button is disabled. Prefer aria-disabled="true" over the disabled attribute inside a toolbar, so keyboard and screen reader users can still find the button and hear why it does nothing.
• Shortcut hints. Show Cmd+Z or Ctrl+Z in the tooltip for the user's platform, and set aria-keyshortcuts on the button.
• Show the change. After an undo, restore the selection, scroll the objects into view, and briefly highlight them. An undo that happens off-screen looks like a broken button.

Announcing undo to screen readers

A sighted user sees the card jump back. A screen reader user hears nothing unless we say it. After each undo or redo, write a short message to a polite live region (an element with role="status" whose text changes are read aloud): "Undid move card", "Redid delete 3 shapes".

When the user presses undo five times in a second, announce only the last one, after about 150 ms of quiet, or the reader queues five messages. If undo removes the element that had focus (undoing "Add card"), move focus to a sensible neighbor, such as the previous card or the column, never to the page body. The screen readers and keyboard navigation lessons cover live regions and focus in depth.

Undo meets autosave and the server

Every edit in our editors autosaves. That turns undo from a local trick into a distributed one: the user's undo has to reach the server, other tabs, and other people, and the server can refuse it.

To the server, undo is just another edit

When the user undoes "Move card to Done", the history applies the inverse ops locally, and they go to the same outbox that sends every other edit: "set card 42's column to Doing, position a3". The server doesn't need an undo endpoint and doesn't need to know where the ops came from. That keeps one write path, one set of permission checks, and one conflict policy. It also means undoing right after an autosave simply triggers another save, which is correct: the document really changed again.

When the server refuses an undo

The undo's ops can fail like any edit: an admin locked the card, a teammate deleted the column the card would return to, or the user's role changed to viewer. Because the ops were applied optimistically, the client rolls them back when the server says no.

The question is what happens to the history entry. It's no longer valid, so it's dropped from the redo stack (where the undo had moved it), and the user is told why: "Couldn't undo move: the Doing column was deleted by Ana."

Ordering: undo must never overtake its edit

Fast users undo before the original edit has been saved. If the undo's ops took a different path, or were sent in parallel, the server could apply "move back" first and "move" second, leaving the card in the wrong column while the client shows it correctly. Sending everything through one ordered outbox, each batch with the version it was based on, rules this out.

A good outbox also cancels out pairs that never left. If "move" is still queued when its undo arrives, both can be dropped before sending.

Should history survive a reload?

Most editors drop history on reload, and users accept it, because the document itself is safe on the server. Persisting history is possible: write entries to IndexedDB as they're committed, keyed by document id, and load them on open. The trap is staleness: by the time the user returns, teammates may have changed the document many times, so old inverse ops no longer fit.

Store the document version with each entry, and on load keep only entries whose version is still current, or run them through the same transform as remote edits (next chapter). For most products the honest answer is no persisted undo, plus server-side version history for anything older. The IndexedDB lesson covers the storage side if you do need it, for example for an offline-first editor.

Undo when other people are editing

Up to 10 people edit the same document. Ana moves card 42 to Done, a second later Ben renames it, and then Ana presses Cmd+Z. She means "put my card back", not "undo whatever happened last" (Ben's rename), and certainly not "restore the board as it was before my move", which also erases Ben's rename and everything else since.

The operational transformation lesson calls this intention preservation: an operation should keep doing what its author meant, even after others' operations land around it. Try the three answers below and watch what happens to Ben's work.

Two kinds of data, two ways to stay valid

Properties of objects with ids (a card's column, a shape's fill, a field's label) need no position math. The op says "set card 42's column", and card 42 is card 42 no matter what others did. The only question at undo time is whether someone changed the same property after you.

The Figma guide works through that case and its redo rule: record the redo values at the moment of undo, so undo then redo always leaves the document unchanged. That guide writes your old value back anyway. For kanban cards and form fields we pick the other reasonable policy: skip any property someone else changed since your step, and say so ("Ben renamed this card after your change, so the name wasn't undone"). If nothing in the step still applies, skip the whole step, so the next Cmd+Z does something useful.

Positions in sequences (characters in a text, items in a list ordered by index) need transformation. Your inverse "delete 4 characters at 10" was correct when you typed them. If Ben inserts 5 characters at position 3 afterwards, the same text now sits at 15. Every remote op that arrives must shift the positions in your stored entries, both undo and redo, using the same transform function operational transformation uses for sync (the OT lesson covers how it's written).

With a CRDT such as Yjs, characters have stable ids instead of indexes, so an inverse refers to ids and never goes stale. Yjs ships a selective UndoManager: by default it tracks only local changes made without an explicit transaction origin (network providers usually tag remote updates with themselves as the origin), you can choose other trackedOrigins, and it merges changes made within its captureTimeout of 500 ms.

type TextOp =
  | { type: "insert"; at: number; text: string }
  | { type: "delete"; at: number; length: number };

// Shift a stored op so it still targets the same text after a remote op.
function shiftAgainst(op: TextOp, remote: TextOp): TextOp {
  if (remote.type === "insert" && remote.at <= op.at) {
    return { ...op, at: op.at + remote.text.length };
  }
  if (remote.type === "delete" && remote.at < op.at) {
    const removedBefore = Math.min(remote.length, op.at - remote.at);
    return { ...op, at: op.at - removedBefore };
  }
  return op; // remote op is after ours: no change
}

// On every remote op, rebase both stacks.
function onRemoteOp(remote: TextOp) {
  for (const e of [...history.past, ...history.future]) {
    e.undo = e.undo.map((op) => shiftAgainst(op, remote));
    e.redo = e.redo.map((op) => shiftAgainst(op, remote));
  }
}

Edge cases

• The object was deleted by someone else. Undoing your move of card 42 after Ben deleted it would resurrect a card he removed on purpose. Skip it and say why.
• Your undo depends on someone else's work. You added a card to a column Ben created; Ben then undoes the column. Your card goes with it (or moves to a fallback column, if the board has that rule). When you then undo "Add card", there is nothing left to undo: skip.
• Rebasing cost. Shifting 200 entries for every remote op is cheap for text (a few microseconds each), but batch it: apply remote ops in one pass per animation frame, not one pass per op.
• Remote ops never clear your redo. They adjust it, like the undo stack.

Architecture, data model, and the history API

Now put the pieces together. The goal from the requirements was one module that the canvas, the kanban board, and the form builder all reuse. That forces a clear line: the history module knows about entries, groups, limits, and stacks; it knows nothing about cards or shapes. Everything domain-specific sits behind a small adapter each editor provides.

Two boundaries matter most. First, the history manager sits beside the document store, not inside it. The store applies ops from three sources (local edits, undo and redo, and remote users), but only local edits add entries, and remote ops only rebase them.

Second, the outbox doesn't know about undo at all. That's what keeps one write path to the server: undo ops and normal ops are indistinguishable once they leave the history manager.

How data moves

Follow one edit and its undo end to end. A local edit flows from gesture to command to store, and the store reports it to history (as a labelled entry) and to the outbox (as ops). An undo flows from the shortcut to history, which hands the inverse ops through the adapter to the store, and the store sends them to the outbox like any edit. A remote op flows from the socket through the outbox to the store, and then to history, which rebases its entries against it.

Main thread, tabs, and lifetimes

The history manager runs on the main thread, next to the store. Its work per keypress is tiny (move one entry between two arrays, hand a few ops to the store), so a Web Worker would only add a message round trip to every undo. The expensive parts, rendering 500 restored shapes or transforming text, happen in the store and the view anyway.

Two tabs open on the same document each get their own history. To each other they're simply two collaborators: tab B's edits arrive at tab A as remote ops, rebase A's entries, and never appear in A's undo stack. That falls out of the design for free, with no BroadcastChannel coordination of stacks. The history is created when a document opens and dropped when it closes, so switching between ten documents in a session never stacks up ten histories in memory.

The history data model

Inside that architecture, the history module stores plain data. Each entry is a labelled pair of op lists plus the context needed to restore the user's view. The state around it tracks the stacks, the open group, and the byte count for the budget.

type Op = { op: "add" | "remove" | "replace"; path: (string | number)[]; value?: unknown };

type HistoryEntry = {
  id: string;
  label: string;              // "Move card", shown as "Undo move card"
  redo: Op[];                 // forward ops, in order
  undo: Op[];                 // inverse ops, in reverse order
  selectionBefore: string[];  // object ids to reselect after undo
  selectionAfter: string[];   // ... and after redo
  pageId?: string;            // where to navigate to show the change
  baseVersion: number;        // document version when recorded
  bytes: number;              // estimated once, for the budget
  createdAt: number;          // for time-based coalescing
  mergeKey?: string;          // "type:card-42:title" merges with the same key
};

type HistoryState = {
  past: HistoryEntry[];       // newest last
  future: HistoryEntry[];     // next redo last
  open: { label: string; redo: Op[]; undo: Op[] } | null; // a transaction
  mode: "idle" | "grouping" | "applying";
  bytes: number;
  limits: { maxEntries: number; maxBytes: number; mergeWindowMs: number };
};

A few fields earn their place. label is stored, not computed, because by the time the user hovers the Undo button the objects it names may have changed. baseVersion lets a persisted or rebased entry be checked against the current document, and selectionBefore and selectionAfter hold ids, never DOM nodes, so entries stay plain data.

mergeKey is how coalescing knows that two edits belong together. Keystrokes in the same card title share a key such as type:card-42:title, so typing in a different card always starts a new step, even within 500 ms.

The API every editor uses

interface History {
  // Recording
  push(entry: { label: string; redo: Op[]; undo: Op[]; mergeKey?: string }): void;
  begin(label: string): void;          // open a transaction (a gesture)
  commit(): void;                      // close it as one entry
  cancel(): void;                      // roll it back, record nothing
  group<T>(label: string, fn: () => T): T; // begin + fn + commit, or cancel on throw
  checkpoint(): void;                  // the next push never merges

  // Moving
  undo(): HistoryEntry | null;
  redo(): HistoryEntry | null;
  clear(): void;                       // on document close or reset

  // Reading, for buttons, menus, and tests
  canUndo(): boolean;
  canRedo(): boolean;
  undoLabel(): string | null;          // "Move card"
  redoLabel(): string | null;
  subscribe(listener: () => void): () => void;
}

Each editor creates its history with an adapter: createHistory({ apply, rebase, stillApplies, limits }). The canvas adapter applies Immer patches to its store and rebases text ops; the form builder's adapter only applies patches, because it has no shared text. That's the whole reuse story: three editors, one module, three small adapters.

Plugging into Redux and Zustand

Both libraries already have a pattern for wrapping state updates, and that's where recording belongs. In Redux, a middleware (or Redux Toolkit's Immer-powered reducers with patches enabled) can capture patches for actions marked undoable. In Zustand, a store middleware wraps set.

Ready-made libraries exist: redux-undo wraps a reducer with past, present, and future snapshots, and zundo adds a temporal middleware to Zustand. Both are snapshot-based and single-user, which makes them a good fit for the form builder alone and a poor fit for the shared canvas.

import { create } from "zustand";
import { enablePatches, produceWithPatches } from "immer";

enablePatches();

// Inside a Zustand store: every recorded update goes through `edit`.
const useBoard = create<BoardState>()((set, get) => ({
  doc: initialDoc,
  edit(label: string, recipe: (draft: Doc) => void) {
    const [next, redo, undo] = produceWithPatches(get().doc, recipe);
    if (redo.length === 0) return;     // nothing changed: no entry
    set({ doc: next });
    history.push({ label, redo, undo });
    outbox.send(redo);
  },
}));

// A component:
useBoard.getState().edit("Move card", (d) => {
  d.cards["42"].columnId = "done";
});

Testing, performance, and observability

Undo bugs are silent. A wrong inverse doesn't throw; it leaves the document a little different from before, and the user finds out days later. So the most important tests aren't examples but properties that must hold for every sequence of edits.

Property tests: do, then undo, returns the same document

A property test generates hundreds of random inputs and checks a rule for each one. Libraries like fast-check generate random sequences of edits, run them, and when a rule fails, shrink the sequence to the smallest one that still fails, which is usually two or three steps that point straight at the bug.

import fc from "fast-check";

const anEdit = fc.oneof(
  fc.record({ kind: fc.constant("move"), id: fc.constantFrom("a", "b", "c"), x: fc.integer() }),
  fc.record({ kind: fc.constant("rename"), id: fc.constantFrom("a", "b", "c"), name: fc.string() }),
  fc.record({ kind: fc.constant("delete"), id: fc.constantFrom("a", "b", "c") }),
);

test("undoing every edit restores the start", () => {
  fc.assert(fc.property(fc.array(anEdit, { maxLength: 50 }), (edits) => {
    const editor = createTestEditor(seedDoc);
    for (const e of edits) editor.run(e);
    while (editor.history.canUndo()) editor.history.undo();
    expect(editor.doc()).toEqual(seedDoc);

    while (editor.history.canRedo()) editor.history.redo();
    expect(editor.doc()).toEqual(runWithoutHistory(seedDoc, edits));
  }));
});

• Grouping rules, with fake timers: keystrokes 100 ms apart merge, a 600 ms pause splits, a space starts a new step, cancel() records nothing.
• Limits: after 250 pushes there are 200 entries, and the oldest are the ones gone; a single entry over the byte budget is still kept.
• Multiplayer convergence: two simulated clients make random edits and random undos, exchange ops in random order, and must end with identical documents in which neither user's surviving edits were reverted by the other's undo.
• Keyboard routing, in an end-to-end test: Cmd+Z inside a focused input changes the input, not the board; outside it, the board changes and the live region says what was undone.

Making undo feel instant

Our target was under 50 ms from key press to paint. Most steps touch a few objects and take well under a millisecond to apply. The slow cases are big: undoing a delete of 500 shapes re-inserts 500 objects. Three rules keep those fast.

• Apply all of an entry's ops in one store update and notify subscribers once. 500 separate updates mean 500 re-renders; one update means one.
• Subscribe narrowly. Components select their own object by id, so undoing a move of card 42 re-renders card 42 and its column, not the whole board. Normalized data makes that possible.
• Keep held keys cheap. A held Cmd+Z repeats about 10 to 30 times a second. Each undo must finish well inside a frame, and announcements wait for a quiet moment, as the keyboard chapter described.

What to measure in production

• Undo and redo counts per session, and the labels most often undone: a feature that gets undone a lot is often a confusing feature.
• Skipped or failed undos with their reason (deleted by someone else, rejected by the server, changed by someone else). A rising rate means the conflict policy needs work.
• History size at the 95th percentile, in entries and estimated bytes, and how often the byte budget drops entries.
• Time to apply an undo, as a performance.measure, with the entry's op count.

Running it in the interview

Undo is a feature question, so the interviewer expects depth on a few mechanisms rather than a tour of a whole app. In 45 minutes you won't cover everything in this guide. Pick the parts that show judgment, and say out loud what you're leaving out.

A strong opening sounds like this: "Before I draw anything: is this document shared, and do edits save to a server? If yes, I'll store operations with inverses rather than snapshots, undo only the local user's steps, and treat every undo as a normal edit to the server. Let me start with the stacks and then show how a drag becomes one step." In three sentences you've shown that you know the two hardest constraints and have a plan for the next 40 minutes.

Interviewers for a hard feature question often push on one area until you reach the edge of what you know. Expect them to pick the multiplayer case or the server rejection case. Stay concrete: name the card, the two users, the positions, and what each client shows at each moment. A worked example beats a general claim every time.

Follow-up questions to expect

Common mistakes

• Starting with structuredClone snapshots and never revisiting them once the document size and collaborators come up.
• Recording every pointermove or keystroke as a step.
• Treating undo as local-only, so the next reload brings the change back.
• Global undo in a shared document, or stale inverses that overwrite a teammate's work.
• Taking over Cmd+Z inside native text fields.
• Putting outside effects such as emails on the undo stack.
• No limit on history, or a limit on entries only.