Undo/Redo History Toolbar with Jump-to-Any-State

A genuinely correct undo/redo implementation is a specific, well-understood pattern — not a stack of "reverse operations" that has to be carefully written for every possible action type. This snippet implements the simpler, more robust version: an array of full state snapshots, plus a single integer pointer into that array. Every operation — undo, redo, or jumping to an arbitrary point in history — reduces to nothing more than moving the pointer and re-rendering.

Why snapshots, not "reverse operations"

A tempting alternative design stores each action as an *inverse* operation (e.g. "delete the last shape" as the undo for "add a shape") — but this requires writing and maintaining a correct inverse for every single action type in the app, and inverses can be genuinely hard to get right for complex or composite actions. Storing a full snapshot of the *entire relevant state* after every action sidesteps this completely: undoing is never "run the opposite operation," it's simply "look at what the state used to be, one step back," which is trivially correct by construction no matter how complex an individual action was.

The pointer, not the array length, defines "where you are"

pointer is a separate integer tracking the currently-displayed index into history, distinct from the array's own length. undo() and redo() do nothing more than decrement or increment pointer (bounded at the array's edges) and call render() — there's no separate "apply the inverse" logic, because render() always just displays whatever full snapshot lives at history[pointer].

Why a new action must discard the "future" branch

pushState() calls history.slice(0, pointer + 1) *before* appending the new state — this is the detail that makes branching behave correctly. If a user undoes three steps and then performs a brand-new action, the three steps they'd undone past are no longer reachable via redo; they represent an abandoned timeline the new action has now diverged from. Without this truncation, the old "future" states would linger in the array past the new action, and redo could jump to a state that's no longer consistent with what's actually been done since.

Jumping to an arbitrary history entry is not a special case

The history list lets a user click any past entry and jump straight to it — implemented as nothing more than setting pointer directly to that entry's index and calling render(), the exact same two operations undo()/redo() perform. This is a direct consequence of the pointer-into-an-array design: there's no meaningful difference between "move the pointer back one step" and "move the pointer back five steps," so no separate jump-specific logic is needed at all.