Undo That Jumps to the Wrong Place — Designing Edit History You Can Trust

The history stack itself

We need a container for the commands. It has three requirements: cap the depth and drop the oldest, invalidate the "redo" side when a new action follows an undo, and let the outside world observe the current position.

export class History {
  private done: Command[] = [];   // executed (shrinks on undo)
  private undone: Command[] = []; // undone (shrinks on redo)
  private listeners = new Set<() => void>();
 
  constructor(private readonly maxDepth = 100) {}
 
  push(cmd: Command): void {
    cmd.do();
    // Fold into the previous step if it can coalesce (see below)
    const prev = this.done[this.done.length - 1];
    const merged = prev && cmd.coalesceWith?.(prev);
    if (merged) {
      this.done[this.done.length - 1] = merged;
    } else {
      this.done.push(cmd);
      if (this.done.length > this.maxDepth) this.done.shift(); // drop oldest at cap
    }
    this.undone = []; // a new action invalidates the redo history
    this.emit();
  }
 
  undo(): void {
    const cmd = this.done.pop();
    if (!cmd) return;
    cmd.undo();
    this.undone.push(cmd);
    this.emit();
  }
 
  redo(): void {
    const cmd = this.undone.pop();
    if (!cmd) return;
    cmd.do();
    this.done.push(cmd);
    this.emit();
  }
 
  canUndo(): boolean { return this.done.length > 0; }
  canRedo(): boolean { return this.undone.length > 0; }
  peekUndoLabel(): string | null {
    return this.done[this.done.length - 1]?.label ?? null;
  }
 
  subscribe(fn: () => void): () => void {
    this.listeners.add(fn);
    return () => this.listeners.delete(fn);
  }
  private emit(): void { this.listeners.forEach((fn) => fn()); }
}

The bug behind that opening review was the missing undone = []. If the redo history lingers after the user makes a new edit, the next undo wanders into the old branch. From the user's seat, it looks like it "jumped five steps back." Undo must always be a single path.

Coalescing rapid tweaks into one step

When someone drags a brightness slider, the value changes dozens of times while their finger is moving. Push each as its own step and undo becomes a chore — tapping it thirty times before the brightness change is finally gone.

So we fold same-kind consecutive commands into one step. Two axes decide it: same target and same kind, and arriving within a set time of the previous step. We put a time boundary in because if the user lifts their finger, waits, and then moves it again, that's a different intent.

export function coalesceByTime(
  prevAt: number,
  nowAt: number,
  windowMs = 400,
): boolean {
  return nowAt - prevAt <= windowMs; // within 400ms counts as the same step
}

That's why History.push calls coalesceWith — to slip this folding in. After merging, the history keeps a single "Adjust brightness" step, and one undo returns you to before the adjustment. The first move after lifting your finger becomes a separate step. How you place that boundary makes undo's granularity feel remarkably natural.

Measured on my own app, coalescing slider actions cut the steps stacked during a ten-second color tweak from about 90 on average to 1. History stays shallow, and it matches the user's expectation that one tap should take them back.

Wiring it to React state

Keep History outside React and feed the UI through subscription. With useSyncExternalStore, button enabled/disabled state and labels follow history changes cleanly.

import { useSyncExternalStore } from "react";
 
export function useHistory(history: History) {
  const snapshot = useSyncExternalStore(
    (cb) => history.subscribe(cb),
    () => ({
      canUndo: history.canUndo(),
      canRedo: history.canRedo(),
      undoLabel: history.peekUndoLabel(),
    }),
  );
  return snapshot;
}

On the screen side, never mutate state directly — always change it through a command. Whether you can hold that line is what separates an undo that works from one that doesn't. A single back door where "this edit didn't go through a command" creates an inconsistency: that one thing can't be undone.

function ColorButton({ history, store }: Props) {
  const { canUndo, undoLabel } = useHistory(history);
  return (
    <>
      <Pressable onPress={() => history.push(changeColorCommand(store, next))}>
        <Text>Change color</Text>
      </Pressable>
      <Pressable disabled={!canUndo} onPress={() => history.undo()}>
        <Text>{undoLabel ? `Undo ${undoLabel}` : "Undo"}</Text>
      </Pressable>
    </>
  );
}

Keeping history across sessions

The app slips into the background mid-edit, the OS reclaims its memory, and the user comes back to an empty history. That's one of the most deflating moments in an editing app — and it's where the command approach shows its weakness. Commands hold functions, so you can't serialize them as they are.

The fix is to switch to snapshots only for persistence. Save the current state plus snapshots of the last few steps, with a cap. Limiting to the recent steps rather than the full history is the trade between storage and restore speed.

// Call on background transition. Keep only the last N steps of state.
export async function persistHistory(
  storage: AsyncStorageLike,
  key: string,
  states: EditorState[], // state right after each step (newest last)
  keep = 20,
): Promise<void> {
  const recent = states.slice(-keep);
  await storage.setItem(key, JSON.stringify({ v: 1, states: recent }));
}
 
export async function restoreHistory(
  storage: AsyncStorageLike,
  key: string,
): Promise<EditorState[] | null> {
  const raw = await storage.getItem(key);
  if (!raw) return null;
  const parsed = JSON.parse(raw);
  if (parsed?.v !== 1) return null; // silently drop a mismatched schema version
  return parsed.states as EditorState[];
}

Do the save once, at the moment AppState moves to background, so you don't block the main thread. Writing on every edit lets high-frequency actions jam the writes. And on restore, check the schema version (v) and drop it if it doesn't match. Forcing an old format to load is planting your next crash yourself.

This two-tier setup — commands while running, snapshots for saving — is why I said up front that the two aren't rivals. You reach for lightness and recoverability in the moment each one fits.

Handling actions you can't take back

Not every action can be undone. A post to the server, an export to the photo library, a purchase — side effects that reach the outside world can't be reversed by your app's history alone. Force them into undo and you get the worst kind of mismatch: "I undid it, but it already sent."

The practical move is to treat an irreversible action as a boundary in the history. Make it explicit that you can't go back past it, and commit the history right before crossing.

export class History {
  // ...added to the above...
  commitBarrier(): void {
    // Nothing before here can be undone. Clear history to set a baseline.
    this.done = [];
    this.undone = [];
    this.emit();
  }
}

Call commitBarrier() right after a photo export or a server send, and the user gets a consistent sense that "only from here on can I undo." Don't let something irreversible pretend to be reversible. That, to me, is the foundation of an editing experience people trust.

Undo/redo isn't a flashy feature. But whether a user can move their hands without fear of mistakes rests on how you design this one thing. Start by picking a single edit action in your app and carving it out as a command. Stop stacking whole states; hold only the diff. That first step is the entrance to an editing experience you can run for a long time.

I hope it helps with your own build. Thank you for reading.