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

> `import template from 'my-template.html' as HTMLTemplateElement;`

@rniwa, that's an interesting idea. It reminds me of what webpack loaders do with their `thing-loader!` prefixes. This would also let the different import types recommended here exist simultaneously. Specifically, template / document fragment -style imports, which have almost new no semantics to define, could be implemented quickly and wouldn't prevent the document-style import from making it in once all the details are worked out:

```js
import x from 'y.html' as Document;
```

I think this syntax would be really useful if there was a way to hook into this and customize how raw data fetched by the loader were handled at runtime - i.e. a define a function that converts ArrayBuffers to something representing a module record. Maybe `Symbol.importer`? I think it would be necessary to import your importer [1] for the concept of 'referencing an import in an import statement' to make any sense [2]:

```js
import png from './my-png-importer.js';
import x from 'x.png' as png;

assert(x instanceof Image); // maybe this importer creates Image instances?
assert(png[Symbol.importer](someArrayBuffer).default instanceof Image); // whatever, it's a function.
```

`DocumentFragment[Symbol.importer]`, `HTMLTemplateElement[Symbol.importer]`, `Document[Symbol.importer]`, and others could all then be implemented independently once they're defined. Also, the actual module specifier is unaffected, so the loader can still statically determine the location of dependencies or continue to do whatever the loader spec folks want it to, assuming that's still a thing.

[1]: Or, it would have to be defined on the global scope before the module is executed, like `HTMLTemplateElement` and other browser globals are.
[2]: Yes, I would rather import importers than add another global registry. :)

-- 
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-310822801