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 ?

[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.

[Ankur Bawiskar]

@Fred Jean 

yes sometimes it's require to stop form submission using onSubmit validation and there you need Synchronous GlideAjax.

But you can always move the validation from onSubmit to onChange of variable and throw error and form won't be submitted.

Synchronous GlideAjax don't work in portal.

Refer these links for workaround/solution on how to use Synchronous GlideAjax in onSubmit

How To: Async GlideAjax in an onSubmit script

Asynchronous onSubmit Catalog/Client Scripts in ServiceNow

If my response helped please mark it correct and close the thread so that it benefits future readers.

[Fred Jean]

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

[Ankur Bawiskar]

@Fred Jean 

onSubmit with Synchronous is mostly used to validate if user is allowed to submit form or not.

Well not all customers prefer onSubmit validation and giving a bad UI experience to let them fill everything and then stop the submission.

I have seen some customers preferring onSubmit due to some requirement but most of the times I have recommended onChange validation on variable or field to handle this.

Now that the platform doesn't allow you have other ways to achieve that if it's still required.

If my response helped please mark it correct and close the thread so that it benefits future readers.