Client-side code should not use synchronous AJAX ; Really ?

[Fred Jean]

Hello,

It is a well known, and I believe accepted, good practice to avoid synchronous AJAX in client script.  This is for reasons such as UI responsiveness and perf bottleneck. And having such synchronous AJAX will trigger Healthscan findings.

While reviewing such Healthscan findings where a catalog client script was using a synchronous call, I discussed the topic with the script developer to know if there was any reason to do so.

The reason I was given was to avoid the user from submitting the form before we get the Ajax answer to update other form fields.  (yes, the user would have to be very quick or the network very slow, but it can happen).  So here we want to avoid submission of incomplete or inconsistant data.

So then I thought, doesn't this actually also apply to like 90% of the client scripts using AJAX calls ? Don't we mostly use AJAX to update other fields ? Isn't it an issue most of the time if a form is submitted before the script and AJAX does its job ? So, isn't it actually a good thing to have synchronous calls and get the form blocked (yes I know there are other ways to achieve this) ?

What do you think ?

[Fred Jean]

I know all that, but having he UI freeze is actually what was wanted here.

Of course we could have alternatives by adding controls on the onSubmit script, but that makes things more complex and could actually require also AJAX calls on that onSubmit (and here it would necessarily be synchronous).

[M Iftikhar]

@Fred Jean,

synchronous AJAX does exist for a reason, and I see your point that in some scenarios you really can’t proceed at all without the data. As the spec itself says, while async is best most of the time, sync calls are there for those rare cases where user interaction must be paused until the server responds. Your logic makes sense in that context.

Thanks & Regards,
Muhammad Iftikhar

If my response helped, please mark it as the accepted solution so others can benefit as well.

[Fred Jean]

You say "in some scenarios", but my point that it might actually "in most scenarios"". I mean when would we actually be happy that a form gets submitted before having the other fields be set by the AJAX call ? So async might not actually be best "most of the time".

[Daniel Madsen]

Hi Fred

I believe @M Iftikhar provided a good and helpful response. You can use the scratchpad to preload any values that you know up front is going to be used eventually to prevent or limit the times the client has to contact the server to get the values while the user is filling out the form. If you need to get some values dynamically using ajax, disable the possibility to submit the form while the data is being recieved, and enable it once the data has been recieved. This way you can keep the asyncronous approach, while ensuring that data will be submitted correctly.

Best regards

Daniel Madsen

[Fred Jean]

Scratchpad is not an option here (Catalog client script + this is about retrieving data depending on a field value).

I know about the possibility to disable the form submission, and I agree this is a cleaner approach, but it adds complexity. My point was that we would actually need that most of the time and doing the call synchronously achieves the same purpose.