Re: [w3c/webcomponents] CSS Modules (#759)

Thanks for your kind replies.

If I add some context to my own usage :

A] It is important to await async functions

```javascript
arr = ['a'];

function resolveAfter (value, ms) {
  return new Promise(f => setTimeout(() => f(value), ms));
}

async function addB() {
  arr = [...arr, await resolveAfter('b', 100)];
}

async function addC() {
  arr = [...arr, await resolveAfter('c', 50)];
}

await addB(); // <------- It is important to await async functions
await addC(); // <------- It is important to await async functions

// immediately...
console.log(arr); // ['a', 'b', 'c'] <------- as expected
```

The litigious code :
```javascript
document.adoptedStyleSheets = [...document.adoptedStyleSheets, await import('./style.css')];
```
... was expected to be part of an async function, and this function was expected to be awaited, as its ancestors, until we reach the main function.

```javascript
// deep code

const style = async () => {
  document.adoptedStyleSheets = [...document.adoptedStyleSheets, await import('./style.css')];
}
await style();  // <------- I do await in 99.99% of my code
```

-----

B]  The only case I authorize myself to not await an async function is... the main.

```javascript
// index.js

const main = async () => {
  // ...
} 
main();  // <------- I do *not* await at top level
```

A developer can still use the litigious code in the main function.
In this specific case, developer might experience race conditions. 
Result seems strongly related to the very nature of async / await and how the developer masters it. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/759#issuecomment-521217324