Re: [w3c/webcomponents] HTML Modules (#645)

> - normal script imports don't return promises, so I don't think any of these imports should either. You can import img from "./x.png" as Image if waiting for that import suits you; otherwise you can always create a new Image and wait for its onload as you can today. No need to reinvent that wheel.
>
> Actually, thinking of async imports, it could actually be supported with custom importers. Suppose import ... as X calls a function with this signature:
> 
> ```js
> X[Symbol.importer] = function (url)
> {
>  // return a promise when the import is done
> }
> ```

I wasn't clear but yes, this is exactly what I was going for there. Also, just to be more specific with regards to:

> If there's some way to actually resolve with a promise, then you could implement imports which return a promise.

I didn't mean to imply every custom importer should produce a promise as its module record's the default export, but that the promise that the importer returns would itself resolve to the module record representing object. (Nicely covered by your examples for `X` and `JSON`.) So, I think we're on the same page. :)

---

Also, to correct the example I made earlier,

```js
png[Symbol.importer](someArrayBuffer).then(m => assert(m.default instanceof Image));
```

should really be

```js
fetch(someURL)
  .then(response => response.arrayBuffer())
  .then(png[Symbol.importer])
  .then(mod => assert(mod.default instanceof Image));
```

to get the same effect as

```js
import(someUrl).then(m => /* do stuff */);
```

while using a 'custom importer'.

-- 
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/645#issuecomment-310875625