--- title: Autosave slug: autosave kind: pattern summary: The system persists changes as they are made and reports the save state continuously, so "have I saved?" stops being a question anyone has to hold. problem: >- Explicit save puts the burden of durability on the person doing the work. They must remember to press a button, and every moment between the edit and the press is work that a closed laptop or a stray click can destroy. family: [edit, capture] data_shape: [record] principles: [friction, consistency, orientation] interaction: [editing] density: low complexity: medium status: stable visibility: public use_when: - The work is composition — notes, descriptions, drafts — where a partial state is still valuable. - Sessions are long enough that losing them matters. - Each field is independently meaningful, so saving one at a time cannot corrupt the record. avoid_when: - A partially-entered record is invalid or dangerous — a payment, a booking, anything that fires side effects. - Other people see the record live and would read half-finished edits as final. - The edit is a transaction across several fields that must land together. alternatives: - slug: unsaved-changes-guard when: The record must be saved as a whole, so explicit save is correct and the risk needs managing instead. - slug: inline-editing when: You want per-field commit on a list or table rather than continuous background saving. ask_leo: | Make this form save automatically instead of requiring a Save button. - Save a field when it loses focus, and after a short pause in typing — roughly a second — rather than on every keystroke. - Show the save state continuously in one fixed place: "Saving…", then "Saved", with the time of the last save. Never leave the state ambiguous. - Never move focus, reorder, reformat or re-render the field the person is editing as a result of a save completing. - If a save fails, say so clearly, keep the person's text exactly as typed, and retry. Never silently discard an edit, and never let a failed save look like a successful one. - Keep a version history so autosave does not mean overwriting the only copy, and offer a way back to an earlier version. - If two people can edit the same record, detect the conflict on save and show both versions rather than letting the last write win silently. - Do not autosave a record that triggers side effects when it changes. Those need an explicit, deliberate action. related: - title: Unsaved Changes Guard url: /patterns/unsaved-changes-guard summary: What you build instead when the record must be saved as a whole. - title: Inline Editing url: /patterns/inline-editing summary: The per-field sibling — edit where the value lives, commit on blur. --- ## Anatomy ``` ┌───────────────────────────────────────────────┐ │ Job notes Saved 14:32 ✓ │ ← one fixed place, │ ┌───────────────────────────────────────────┐ │ always says something │ │ Site access is via the rear gate… │ │ │ └───────────────────────────────────────────┘ │ └───────────────────────────────────────────────┘ states: idle → "Saving…" → "Saved 14:32" ↘ "Couldn't save — retrying" (text kept) ``` - **A single, permanent status location.** It must never be blank; "Saved 14:32" when nothing is happening is part of the pattern, because absence of a message is indistinguishable from a failure. - **Debounce, then commit on blur.** Per-keystroke saving is expensive and produces a useless version history. - **Never touch the field being edited.** The most damaging autosave bug is a save response that re-renders and eats a cursor or three characters. ## Why it works It deletes an entire category of user obligation. With explicit save, durability is a task the person must perform; with autosave it is a property of the system. Everything that used to hang off that obligation — the guard dialog, the beforeunload handler, the "you have unsaved changes" state — stops being needed. The status indicator is what makes it trustworthy rather than merely convenient. People will not stop worrying about saving because you removed the button; they stop because the screen tells them, continuously, that it is handled. ## What it costs you Autosave is not free. It buys durability by taking on three obligations that explicit save did not have: - **Version history.** Continuous saving means there is no "before". Without history, autosave converts "I forgot to save" into "I overwrote it", which is worse because it is silent. - **Conflict handling.** Two people editing one record, both saving constantly, produces a last-write-wins race that neither of them can see. - **Honest failure.** A failed save must be visible and must not lose the text. A silent failure with a green indicator is the worst possible outcome — the person has been told their work is safe when it is not. If you cannot take on those three, explicit save with a [guard](/patterns/unsaved-changes-guard) is the more honest design. ## Getting it wrong - **Saving on every keystroke**, which floods the server and makes history useless. - **Re-rendering the active field** on save, eating the cursor or characters. - **A blank status area** when idle, so silence means both "fine" and "broken". - **Autosaving something with side effects.** A half-typed email subject that sends, a booking that provisionally holds a slot — this is the failure that actually hurts customers. - **No version history**, so the record has exactly one state, forever, and it is whatever was last typed. ## Exemplars **Google Docs** is the canonical implementation and, importantly, ships all three obligations: continuous status, full version history, and real-time conflict resolution. It is a good reminder that the visible part of autosave is the smallest part. **Notion** shows the pattern applied per block, which keeps the save unit small and the conflict surface narrow. **Linear's issue description** demonstrates the boundary well — the description autosaves, but the state transitions that notify people are explicit actions. Composition autosaves; consequences do not. The extractable rule: **autosave what is composed, and require an explicit action for anything that has consequences.** The distinction is not the field type, it is whether saving does something a person cannot take back.