Could you show how to do that?
This sort of stuff is ready above my JS comfort zone
I learned how to do invoke Snap! blocks from JavaScript from this Snap! discussion 3 years ago: https://github.com/jmoenig/Snap/issues/1938
So in this case instead of the await I would do something like
navigator.serial.requestPort().then((port) => {
// do more JavaScript and then invoke the Snap! block as described in the 3-year old issue.
}
#Woosh 
There is a real-world example of calling an asynchronous JS function and receiving the result. The "SVG:costume" from HTMLDialog project is the simplest example.
"When ready" reporter can be extended to handle timeout.
Async JS function handled this way, must conform to this pattern.
let res = false;
...
//return result
res = someResult;
...
//failure
res=true;
...
return ()=> res;
There is also an idea to return
let res;
let done = false;
...
//return result
res = someResult;
done = true;
...
//failure
done=true;
...
return ()=> new List( [ () => done, () => res]);
See "clip 2 costume"@send anything to clipboard project.
Note that this example isn't of a JavaScript asynchronous function but the technique described will work for asynchronous functions as well.
Compared the "callback" scheme I mentioned this one does have the overhead of repeat until (which I'm guessing has about the same cost and effect as wait until). Perhaps someone who knows the Snap! internals can comment on what that cost is.
Regarding error handling, the callback scheme works best if there are two callbacks: a normal value and an error result. I would improve your example by returning the error message instead of the value true and then testing if the delayedResult is text. This way the user can learn what the error was.
An advantage of the when ready scheme is that there is no dependence upon Snap!'s internals to invoke the command input from within JavaScript.
Yes, it can be built this way and is even compatible with "Catch errors" library
Because Web Serial reader stream already uses
const { value, done } = await reader.read()
so maybe the second approach can be better.