Flow
Choosing how to save a whole list
1Whole list or one change?
Only whole-list saves can safely skip an older save.
2Every state or just the newest?
Every state means lining saves up. Newest only means waiting a moment and sending the latest.
3Check the server's answer
A server error does not make the request fail on its own.
4Number each list
Lets the server refuse an older list no matter what order things arrive in.
The chore list on my shift schedule page had two ways of talking to the server, and only one of them could say "gone".
Saving sent one request per chore. Deleting sent a separate delete request. Nothing waited for anything to finish. The first chore commit of the day reads like deleted chores weren't staying deleted, but the diff doesn't show why.
One request that can say "gone"
All three chore commits that day start from the same file and do the same first thing. They drop the per-chore loop and the delete call. A save now sends the whole list in one request, and deleting a chore just means taking it out of the list and saving. The server can tell a chore is gone because it's missing.
A request about one item can only say what that item looks like. It can't say the item is gone, so delete needed its own call, and every place that removes a chore had to remember it. A whole list says both.
When the older list lands last
The catch: a whole list replaces everything. If I delete a chore and then edit another one quickly, two lists are on the way. The first version just sends and forgets. If the older list lands last, the deleted chore comes back. That assumes the server swaps in whatever list arrives. I can't see the server side in these diffs.
Single file, or newest only
The second version lines saves up. Each one waits for the one before it to finish, then goes. A failed save doesn't block the next one. Every list gets sent, in order. It's slow under a burst of clicks, but I think it's right.
The third version sends only the newest list. It waits a moment, cancels any save still going, and sends the latest. That only works because each save is a whole list, so an old one is worthless.
It has holes. It hands back the promise from the last save, not this one.
So awaiting a save can finish before that save has even started.
Cancelling also only stops the browser from waiting. The server may still apply the old list. Errors are thrown away.
Status codes nobody reads
No version checks whether the server said OK. A server error looks like a success. None came with a test.
A version number the server can check
I'd rather put a number on each list and let the server refuse an older one. Then lining up or dropping saves is only about traffic. That's my plan, not what these commits do.
The test I'd write first: slow the first save down, delete a chore, edit another, and see which list the server keeps.