Skip to content

v0.11.0 — Undo and redo for the session

Choose a tag to compare

@lina-berger lina-berger released this 17 Aug 12:12
· 71 commits to main since this release
bb9d8d6

Undo and redo, for the session

A misclick — a wrong edit, a deleted record — used to be recoverable only by
"save as", closing without saving and reopening the last saved copy, and
manually copying the old values back in by hand. Since the file is the
database, there was no history to fall back on inside a session.

The decision

Every create, edit and delete now goes onto an in-memory undo stack —
Ctrl/Cmd+Z undoes it, Ctrl/Cmd+Y (Ctrl/Cmd+Shift+Z also works) redoes it, and
the same two actions sit as buttons in the file bar for anyone who prefers a
click. This covers every path that changes data: the record form, AI-proposed
changes, CSV import, JSON import, the wizard, and merging a copy that came
back.

Two things were deliberately decided this way rather than the more ambitious
alternative:

  • The history lives in the tab's memory only, capped at 50 steps. It is
    never written into the embedded data block — a version history that
    travels with the file would be a second, competing source of truth, and
    this template's one rule is that the file's payload is the only truth.
    Saving does not clear the stack and does not persist it either; closing
    the tab or reopening the file loses it, same as any unsaved state.
  • A new change clears the redo stack, like any editor — going back three
    steps and then typing something new makes the three you undid unreachable,
    rather than leaving a branching history nobody asked for.

Storage cost is a stack of object references into the record set, not deep
copies — arrays are rebuilt on each change but untouched records stay shared
by reference, so the overhead for 50 steps is a few KB for ordinary fields.
The one case worth knowing: repeatedly editing an attachment field on the
same record keeps up to 50 different attachment byte-strings alive at once
until the stack rolls over, bounded by the existing attachment budget (4 MB
per file). Negligible for text, enum and number fields, which is the common
case.

What changes for existing tools

Nothing to configure — the two buttons and the shortcuts are always there.
Typing in a text field still gets the browser's own field-level undo; the
shortcut only takes over once focus moves outside a text input, so the two
never fight over the same keystroke.

What's deliberately not in this release

No undo for settings changes (theme, branding, AI configuration) — scope was
records and entities only. No visual toast on undo/redo — the button's
enabled/disabled state already signals whether there's anything to step
through, and a toast on every keystroke felt like noise rather than
feedback. No persistent version history across saves or sessions — that is
a different feature with a different set of trade-offs, not a bigger version
of this one.