Converting asynch calls to synchronous ones. Help needed using "await"

[ubacher]

For  the scripting we do with Imatch there is no need for asynchronous calls. Using the asynchronous calls
just complicates scripting.

We should be able to convert asynchronous calls to synchronous ones by calling the await function.
Mario: could you please help us (me) figure out how to do this.
A sample script would be super.

[Mario]

I have never used await, sorry. I'm sure you can find of examples on how to use await on the net.
As I said, asynchronous is the normal and recommended way to deal with web service calls and similar. Blocking a JavaScript and waiting for a web service call to return a result is bad practice.  You are really fighting the system here instead of going with the flow...

I assume you want to do something like this:

1. IMWS.get(...)
2. Wait until the above function returns a result, blocking JavaScript from running.
3. Process what was returned from IMWS.get

You get exactly that with

1. IMWS.get(...).then(function(response)
{
  // 3. IMWS has processed the request, now process the data.
});

but without blocking JavaScript or fiddling with potential harmful concepts like async = false or await.

[ubacher]

I have looked at all my scripts and none of them will benefit from asynchronous processing.
I will not put an asynchronous request if I am not interested in the result. Means I will have to wait, one way or another,
for the result. Asynchronous calls just make the programming so much harder.

Asynchronous was designed so as to not block the user interface of a browser. Since my scripts are all
modal this is not an issue. 

But even in an interactive (non-modal) environment the asynchronous programming can get quite hairy. Every time
you issue an asynchronous call you have to consider which parts of the interface you have to block until the result comes in.
And when the result is in then unblock these again. Easy to forget part of that and thus run into trouble. Simplest example
is not letting the user exit until all calls have returned. If the user exits by closing the window you might end up with a
partially executed script - I assume there is a way around this - simple?

Since we are quite a few struggling with this I thought you would be more open to help us simplifying our scripting.

[Mario]

You cannot prevent a user from closing an App Panel or a modal app window. This is by intention.
Disabling user interface elements is easy to do. Check the samples provided with IMatch for several ways to do it. The comments in the scripts explain the details.

All web service (AJAX) calls are asynchronous by default in JavaScript for obvious reasons.
If you really need to break common practice and somehow make web service calls behave synchronous, well, whatever fits the bill. I would not bother, it's prone to fail.

Blocking your script will not prevent the user from closing IMatch or your modal window.
JavaScript cannot prevent the user from closing the browser, also for good reasons.
Or from pressing <F5> to reload your script!

I would need to add special endpoints to IMatch to allow scripts to prevent the user from leaving.
But this would cause all kinds of potential security vectors and pitfalls.

Did you try the async= false  option for jQuery AJAX calls. According to the documentation this should make the call blocking. I mentioned that above but you did not comment.

[Carlo Didier]

Or from pressing <F5> to reload your script!

Ouch! Hadn't even thought of that pitfall ...
I'll have to handle that case if I don't want my script to run several times in parallel because I inadvertently pressed F5 when the app panel had the focus ...

[ubacher]

Now I wonder: if I run the script as a modal app will F5 still be active? Only if a window is shown(asking for input, or progress bar), always,  or not at all?

And what will happen if F5 is pressed while in the middle of a script i.e. an incomplete state?

I just checked my list of scripts and fortunately there are only 4 which need to be programmed to be restartable in the middle or have a roll-back functionality.
Some other scripts will produce errors when initiated again and those I just need to handle appropriately.

[Mario]

App Panels and the modal window show the chromium browser So F5 will work in both.
Of course you can try that out easily enough by using a console.log("Hey!") as the first statement in your <script> section.

[thrinn]

I know this is an old topic, but as I just learned a bit about async/await  I want to share some resources I found helpful for understanding the concept.
https://javascript.info/async-await contains some concise and IMHO well written explanations of these JS language feature. Just skip the parts you are not interested in (e.g. about classes or thenables...).
https://hackernoon.com/6-reasons-why-javascripts-async-await-blows-promises-away-tutorial-c7ec10518dd9 was also helpful for me.
Of course, there is always the official MDN documentation https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function, but the keyword oriented approach is not ideal for learning.

[Carlo Didier]

Thorsten, that hackernoon.com link speaks right from my heart! It basically confirms all my remarks I made on that theme.