{"slug":"autosave","meta":{"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.\n\n- Save a field when it loses focus, and after a short pause in typing —\n  roughly a second — rather than on every keystroke.\n- Show the save state continuously in one fixed place: \"Saving…\", then\n  \"Saved\", with the time of the last save. Never leave the state ambiguous.\n- Never move focus, reorder, reformat or re-render the field the person is\n  editing as a result of a save completing.\n- If a save fails, say so clearly, keep the person's text exactly as typed,\n  and retry. Never silently discard an edit, and never let a failed save look\n  like a successful one.\n- Keep a version history so autosave does not mean overwriting the only copy,\n  and offer a way back to an earlier version.\n- If two people can edit the same record, detect the conflict on save and show\n  both versions rather than letting the last write win silently.\n- Do not autosave a record that triggers side effects when it changes. Those\n  need an explicit, deliberate action.\n","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."}]},"body":"## Anatomy\n\n```\n┌───────────────────────────────────────────────┐\n│ Job notes                    Saved 14:32 ✓    │ ← one fixed place,\n│ ┌───────────────────────────────────────────┐ │   always says something\n│ │ Site access is via the rear gate…         │ │\n│ └───────────────────────────────────────────┘ │\n└───────────────────────────────────────────────┘\n\n  states:  idle → \"Saving…\" → \"Saved 14:32\"\n                           ↘ \"Couldn't save — retrying\" (text kept)\n```\n\n- **A single, permanent status location.** It must never be blank; \"Saved\n  14:32\" when nothing is happening is part of the pattern, because absence of a\n  message is indistinguishable from a failure.\n- **Debounce, then commit on blur.** Per-keystroke saving is expensive and\n  produces a useless version history.\n- **Never touch the field being edited.** The most damaging autosave bug is a\n  save response that re-renders and eats a cursor or three characters.\n\n## Why it works\n\nIt deletes an entire category of user obligation. With explicit save, durability\nis a task the person must perform; with autosave it is a property of the system.\nEverything that used to hang off that obligation — the guard dialog, the\nbeforeunload handler, the \"you have unsaved changes\" state — stops being needed.\n\nThe status indicator is what makes it trustworthy rather than merely convenient.\nPeople will not stop worrying about saving because you removed the button; they\nstop because the screen tells them, continuously, that it is handled.\n\n## What it costs you\n\nAutosave is not free. It buys durability by taking on three obligations that\nexplicit save did not have:\n\n- **Version history.** Continuous saving means there is no \"before\". Without\n  history, autosave converts \"I forgot to save\" into \"I overwrote it\", which is\n  worse because it is silent.\n- **Conflict handling.** Two people editing one record, both saving constantly,\n  produces a last-write-wins race that neither of them can see.\n- **Honest failure.** A failed save must be visible and must not lose the text.\n  A silent failure with a green indicator is the worst possible outcome — the\n  person has been told their work is safe when it is not.\n\nIf you cannot take on those three, explicit save with a\n[guard](/patterns/unsaved-changes-guard) is the more honest design.\n\n## Getting it wrong\n\n- **Saving on every keystroke**, which floods the server and makes history\n  useless.\n- **Re-rendering the active field** on save, eating the cursor or characters.\n- **A blank status area** when idle, so silence means both \"fine\" and \"broken\".\n- **Autosaving something with side effects.** A half-typed email subject that\n  sends, a booking that provisionally holds a slot — this is the failure that\n  actually hurts customers.\n- **No version history**, so the record has exactly one state, forever, and it\n  is whatever was last typed.\n\n## Exemplars\n\n**Google Docs** is the canonical implementation and, importantly, ships all\nthree obligations: continuous status, full version history, and real-time\nconflict resolution. It is a good reminder that the visible part of autosave is\nthe smallest part.\n\n**Notion** shows the pattern applied per block, which keeps the save unit small\nand the conflict surface narrow.\n\n**Linear's issue description** demonstrates the boundary well — the description\nautosaves, but the state transitions that notify people are explicit actions.\nComposition autosaves; consequences do not.\n\nThe extractable rule: **autosave what is composed, and require an explicit\naction for anything that has consequences.** The distinction is not the field\ntype, it is whether saving does something a person cannot take back.\n"}