await at module top level workaround

[sidewayss]

This issue is a reminder for 2029 to either:

• remove the noAwait code that supports the lack of the await at module top level.
• or kick the can down the road another few years.

Quite to my surprise, I came up with a way to work around this limitation while maintaining external template files and not totally butchering the code. The main consequence for users is that if they need to access the layout of the element during page load, they need to wait for BaseElement.promises[element].

The workaround doesn't use async or await, so it's widely compatible. Still, it's more code and it's a bit convoluted, so removing it is a good plan. The template files are tiny, so fetching them synchronously is not much of a bottleneck.

Unfortunately, this is a compiler issue, not a run-time issue, and this try/catch block throws an uncatchable exception (using input-num as an example):

let template, noAwait;
try {
    template = await getTemplate("number");
} catch {
    template = "number";
    noAwait  = true;
}

So the await code has to disappear completely in order to work on iOS/Safari 14, for example. Instead the code now looks like this:

const
template = "number",
noAwait  = true;

The 2029 replacement is:

template = await getTemplate("number");

Where noAwait is never declared.

[sidewayss]

After adding the template attribute to BaseElement, this is moot. The new attribute requires not using await because attributeChangedCallback() must run prior to the attribute being available, and the attribute provides the base template filename.

So I'm closing this.