I'd like to implement a note-taking system, with an auto-save feature (say, set by a timer). If the requests that go out to the server are received out of order, the wrong state will be auto-saved.
Right - so this would amount to creating queue? Nevermind, I see what you're saying... This is a very specific instance of something pretty general though. Lets say the user edits a note and then deletes it. Do I have the delete action wait for any saves that went out complete first? As the system gets more and more complex it would be something of a pain to try to work out dependencies every time I want to add a new feature.
Yes, queue up the deltas, then only send the full set of deltas every time the timer fires. This will also prevent you from hammering your server with a stream of requests backing up.
Now, lets say I want to stay away from auto-save... The app I'm working on will actually be a widget on the side of the main site and so I'm not confident the user will pay enough attention to know if his/her info has been saved before they navigate to another page. In this case, can I still avoid a queue? I'd want every action a user takes (adding a note, editing it, deleting it) to result in a server request and some spinny wheel notification that the request is being processed. By the way, thank you both for your help!
You don't need a queue.. Just issue the commands as the user makes them. Each command should be separate from every other command, so that order doesn't matter.
I think order does matter - lets say a user types in 'hello' and then saves the note, then quickly changes his/her mind and types in 'hello world' and saves the note. Now the backend will save the version of the note which it receives last, which could be 'hello' depending on network lag.
No, you don't wait. You delete it immediately.. If the delete command arrives before the edit command, the edit command will simply fail, which is fine.