Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AJAX best practices?

news.ycombinator.com

Post reply on HN
Print view View original

11–20 of 20 posts

Re: AJAX best practices?

#11

Post by palish »

morris wrote: post #7
palish wrote: post #6

Earlier quoted context omitted.

Don't save again until the first save has been registered. If it times out, try again.

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…

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.

Re: AJAX best practices?

#12

Post by palish »

morris wrote: post #10
jey wrote: post #9

Earlier quoted context omitted.

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 so…

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.

Re: AJAX best practices?

#13

Post by morris »

palish wrote: post #12
morris wrote: post #10

Earlier quoted context omitted.

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 so…

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.

Re: AJAX best practices?

#14

Post by palish »

morris wrote: post #13
palish wrote: post #12

Earlier quoted context omitted.

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.

In that instance, you'd abort the previous request, create a new XmlHTTPRequest object (important step), then re-issue the request.

Re: AJAX best practices?

#15

Post by morris »

palish wrote: post #14
morris wrote: post #13

Earlier quoted context omitted.

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.

In that instance, you'd abort the previous request, create a new XmlHTTPRequest object (important step), then re-issue the request.

How does one abort the previous request unless a queue is being kept track of? Also, there could have been a few other requests made between the first save and the second save. Its definitely possible I'm just not understanding how XMLHTTPRequest objects work - please do explain if you think that is the case.

Also - I'm not necessarily using XMLHTTPRequest, I'm leaning towards dynamic scripting as my site will need this widget to run across several different subdomains - dynamic scripting doesn't have a lot of the nice status functionality that XMLHTTPRequest does...

Re: AJAX best practices?

#16

Post by palish »

morris wrote: post #15
palish wrote: post #14

Earlier quoted context omitted.

In that instance, you'd abort the previous request, create a new XmlHTTPRequest object (important step), then re-issue the request.

How does one abort the previous request unless a queue is being kept track of? Also, there could have been a few other requests made between the first save and the second save. Its definitely possible I'm just not understanding how XMLHTTPRequest objects work - please do explain if you think that is the case. Also - I'm not necessarily using XMLHTTPRequest, I'm leaning towards dynamic scripting as my site will need t…

Okay, here's an alternate method.

 When a user needs to save their note
  If the note is already saving
   Set note.saveAgain = true
  else
   Start the process of saving the note
 
 When the note has saved
  If note.saveAgain == true
   Set note.saveAgain = false
   Start the process of saving the note again
That doesn't require a queue. It also only saves the most up to date version.

Re: AJAX best practices?

#17

Post by morris »

palish wrote: post #16
morris wrote: post #15

Earlier quoted context omitted.

How does one abort the previous request unless a queue is being kept track of? Also, there could have been a few other requests made between the first save and the second save. Its definitely possible I'm just not understanding how XMLHTTPRequest objects work - please do explain if you think that is the case. Also - I'm not necessarily using XMLHTTPRequest, I'm leaning towards dynamic scripting as my site will need t…

Okay, here's an alternate method. When a user needs to save their note If the note is already saving Set note.saveAgain = true else Start the process of saving the note When the note has saved If note.saveAgain == true Set note.saveAgain = false Start the process of saving the note again That doesn't require a queue. It also only saves the most up to date version.

Cool.

Thanks again.

Re: AJAX best practices?

#18

Post by palish »

morris wrote: post #17
palish wrote: post #16

Earlier quoted context omitted.

Okay, here's an alternate method. When a user needs to save their note If the note is already saving Set note.saveAgain = true else Start the process of saving the note When the note has saved If note.saveAgain == true Set note.saveAgain = false Start the process of saving the note again That doesn't require a queue. It also only saves the most up to date version.

Cool. Thanks again.

I can has karma now?

Edit: How dare I ask to be compensated for my time. I should be ashamed of myself.

Re: AJAX best practices?

#20

Post by cpinto »

morris wrote: post #13
palish wrote: post #12

Earlier quoted context omitted.

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.

You should probably use some kind of versioning so that when you receive version 123 and the version in the database is 121, you won't commit 123 until you receive #122.

If the user deletes the note and the server receives the delete request before other modification deltas, simply ignore the deltas that arrive after the delete command.

In my opinion it's a lot more simple to solve this kind of problems on the server side of a web application.

Post reply on HN