Memento pattern explained with examples

Intent and the problem it solves

Intent: without violating encapsulation, capture and externalize an object's internal state so that the object can be restored to this state later. Memento is one of the behavioral patterns in the Gang of Four (GoF) book.

Imagine a drawing app where a shape has a position, size, color and a list of private, derived values used for rendering. You want an undo button. The undo manager could copy the shape's fields itself, but then it must know every private field, and every time the shape class changes, the undo manager breaks. Making all fields public just for undo would let any code put the shape into an invalid state.

Memento solves this by letting the shape itself produce a snapshot. Only the shape knows what is inside the snapshot and how to restore from it. The undo manager treats snapshots as opaque objects: it stores them in a list and hands one back when the user presses undo.

Structure and participants

The key idea is two interfaces: a wide one for the originator, which can read the saved state, and a narrow one for everyone else, which can only hold the memento.

TypeScript implementation

The memento class uses JavaScript private fields (#state), so the caretaker cannot read the stored data from the memento object. Reading goes through the static method EditorMemento.read, which only the editor calls. In a real project, put the memento class in the same module as the editor and do not export it, so other modules can hold mementos but never open them.

type EditorState = { text: string; cursor: number };

class EditorMemento {
  readonly #state: EditorState;
  constructor(state: EditorState) {
    this.#state = { ...state }; // copy, so later edits do not change the snapshot
  }
  static read(m: EditorMemento): EditorState {
    return { ...m.#state };
  }
}

class Editor {
  private state: EditorState = { text: "", cursor: 0 };
  type(words: string) {
    const text = this.state.text + words;
    this.state = { text, cursor: text.length };
  }
  get text() { return this.state.text; }
  save(): EditorMemento { return new EditorMemento(this.state); }
  restore(m: EditorMemento) { this.state = EditorMemento.read(m); }
}

class History {
  private stack: EditorMemento[] = [];
  constructor(private editor: Editor) {}
  backup() { this.stack.push(this.editor.save()); }
  undo() { const m = this.stack.pop(); if (m) this.editor.restore(m); }
}

const editor = new Editor();
const history = new History(editor);
history.backup(); editor.type("Hello");
history.backup(); editor.type(" world");
console.log(editor.text); // Hello world
history.undo();
console.log(editor.text); // Hello
history.undo();
console.log(JSON.stringify(editor.text)); // ""

History is the caretaker. It calls backup() before each change and undo() to go back, but it never sees text or cursor. If you later add a selection range to EditorState, History does not change.

Memento vs Command for undo

There are two common ways to implement undo, and they are often combined:

A practical compromise: store commands for most steps and a full memento every N steps, or store only the part of the state that a command changes.

When to use it and when not to

• Use it for undo, redo, checkpoints, save games and "cancel" buttons on forms that should roll back edits.
• Use it for transactions in memory: snapshot before a risky operation and restore if it fails.
• Use it when the caretaker must not depend on the originator's internal fields.
• Do not use it when the state is very large and changes often, unless you limit the history length or store only differences.
• Do not add the full ceremony when the state is already a plain immutable value. With immutable data, an old value is already a snapshot, and keeping a list of previous values is enough.

Real-world uses

• The browser History API: history.pushState(state, "", url) stores a state object for each history entry, and the popstate event hands it back when the user navigates.
• Redux and similar stores keep immutable state snapshots, which tools use for time-travel debugging.
• SQL databases support SAVEPOINT inside a transaction, so work can be rolled back to a named point.
• Text editors, graphics programs and games save snapshots for undo, autosave and save slots.

Related patterns