React · Forms · Agent skill
Autosave Status
Know what a save indicator should say while the user keeps typing and the server is still answering.
The problem
Autosave is usually built with a debounce and an isSaving flag. The flag turns off when a request finishes, and the label switches to “saved”. But if the user edited while that request was in flight, the server confirmed an older version. The screen says “saved” while the latest change exists only in memory, and the user has no reason to stay on the page.
Try it
Edit while it saves.
The example starts with the sequence that causes the problem: an edit, a save, another edit while it is in flight, and the server's confirmation. Continue with the buttons and compare what each indicator shows. The data is fictional and everything runs in this browser.
edit → save → edit → confirmed
isSaving flag
SavedShows “saved” whenever the last response succeeded.
Version model
Unsaved changes- on screen
- v2
- sending
- —
- confirmed
- v1
The flag says “saved”, but the server confirmed v1. v2 exists only in memory. Send another save to confirm it.
How it works
A small model counts versions instead of flags: the draft on screen, the version inside the request in flight, and the last version the server confirmed. The status is derived from those numbers, so “saved” can only appear when the confirmed version is the one on screen. The same pure JavaScript model runs the demo on this page and the CLI that replays edit/save sequences; the skill tells an agent how to use it to design or review an autosave implementation.
- 01 · Describe the scenario
- 02 · Replay it
- 03 · Compare with the code
Implementation decisions
- Derive the status from versions on every render instead of storing it, so it cannot drift from the data.
- Allow one save in flight per form. Order stays trivial, and TanStack Query v5 supports it directly with mutation scopes.
- Treat a failure as pending work, not as a final state: the draft stays on screen, marked “couldn’t save”, until a later save succeeds.
- Describe scenarios as plain JSON traces with the expected status after each step, so they can live next to the tests.
Verifiable result
In the included trace, the user edits while the first save is in flight. The flag-based indicator shows “saved” after the first response; the model shows “unsaved changes” until the second save confirms the latest version. The CLI returns exit code 1 for the flag-based expectations and 0 for the version-based ones.
The automated checks replay the three included traces, confirm the exit codes (0 for a matching trace, 1 for a mismatch, 2 for invalid input), reject impossible transitions such as a second save while one is in flight, and check that the model never mutates its input. Run npm run check:skill in the portfolio repository to reproduce them.
Limitations
The model covers one form in one tab, with one save in flight at a time. It does not handle other tabs, other devices, other users, or the order in which the server applies writes; those need versioning or conflict handling in the API. It says what the indicator should show; it does not test your code.
Installation and usage
Download and extract the package, then run the commands below from the extracted autosave-status folder. To use it with an agent, place that folder in your agent's supported skills directory and ask it to review your autosave flow with autosave-status. The CLI requires Node.js 18+ and has no package dependencies; this implementation was checked on Node.js 22.
node scripts/replay.mjs examples/edit-during-save.json
node scripts/replay.mjs examples/boolean-indicator.jsonExample agent request:
Use autosave-status to review the autosave in src/features/profile-form. Write a trace for editing while a save is in flight, compare it with what the code shows, and explain any mismatch. Do not change the code yet.