DCE and html modules imports

[sashafirsov]

This is a conversation teaser, would be implemented in @epa-wg/custom-element, as TypeScript plugin to render typings and IDE support, as NPM module build target.

Goals

• support imports in DCE with declarative syntax

Provide functional pairing to JS modules imports with import default, particular/list of DCE , DCE tags mapping to local context.

• DCE imports to JS/TS modules

DCE exports compatible with imports by JS/TS code, DCE class as subject for export for further inheritance, use, registering tag, etc.

• CE import from DCE

As DCE works only on markup level, import semantics would be in registering of imported CE class to locally scoped registry.

• IDE syntax / suggestion / docs

When DCE imported as a tag in HTML, it should have full support as a code source with ability to jump to definition, docs on tag and parameters( name, description, def value, doc links ), validation on allowed/prohibited, attributes, attributes value by type.

Syntax

parity with JS import:

• default import

CE JS: import MyElement from "./my-element.js"

DCE from JS: import MyElement from "./my-element.html"

DCE from DCE

<custom-element tag="my-element" src="my-element.html"></custom-element>

CE from DCE

<custom-element tag="my-element" src="./my-element.js"></custom-element>

While JS import always expect the class as resolved module value, the DCE is content-type sensitive. If defined as attribute, it treates as a hint for build transformation. application/javascript would resolve module as CE, others would be treated as DCE DOM sources (SVG, HTML, XSLT,...)

• named import

CE JS: import {Element1, Element2 } from "./my-element.js"

DCE from JS: import {"id-1" as Element1, "id-2" as Element2} from "./my-element.html"

id is used for imported HTML as tag assumes to use registry, while import in JS does not use it.

DCE from DCE

<custom-element tag="element-1" src="my-element.html#id1"></custom-element>
<custom-element tag="element-2" src="my-element.html#id2"></custom-element>

implementation notes

• Typescript import plugin would generate the code to load DCE class without tag registration from HTML file or its part.
• DCE code would load the DOM from URL or DOM part if #id defined.
• IDE support is done by manifest and IDE-specific JSON generation

[mildred]

I believe it should be possible to import in a declarative manner in HTML (no JS) multiple components with a single statement.

Also, I believe that relative links (src and href attributes) defined in custom element should link to resources relative to the custom element file, and not to the file that includes the custom element. For example, if in /docs/page.html I include a custom element defined in /navbar.html, the links defined in the navbar should be relative to / and not to /docs.

edit: I suggested <template src=...> for this very purpose:

• Add src attribute to <template> to load a template from file whatwg/html#10571

[sashafirsov]

DCE modular development & distributable libs - implementation notes.

@mildred ,

it should be possible to import in a declarative manner in HTML (no JS) multiple components with a single statement.

true, if the tags would be the subject for export from the package/lib.

Thinking aloud...

For syntax similar to proposed by you <template src=...>, with importmap which defines the symbolic name for package/lib root, the template ID is the subject for export.
For now it would require the inline DCE instead of tags use. I.e.

<custom-element>
    <custom-element src="lib#id1" tag="tag-1"></custom-element>
    <tag-1></tag-1> ...     <tag-1></tag-1> 
</custom-element>

would become

<custom-element>
    <custom-element src="lib#id1" ></custom-element> ... <custom-element src="lib#id1" ></custom-element>
</custom-element>

which is obviously verbose, but would be even more verbose for inline defined DCE.

The multiple imports meant to match the exported DCE (tags?) with locally used tags. Something like key-value pairs.

<custom-element>
       <import-tags src="lib" tag-1="lib-tag" tag-2="another-tag"></import-tags>
       <!-- translated to -->
       <custom-element tag="tag-1" src="lib#lib-tag"          ></custom-element>
       <custom-element tag="tag-2" src="lib#another-tag" ></custom-element>
</custom-element>

have to think about the tag names as the subject for export.

[mildred]

I was more thinking around the lines of defunct HTML imports where there would be a library.html that defines various custom elements you can then use. So you only have to include the library file and not all of the individual components on all your pages.

[sashafirsov]

right, that is the concept which is materialized by custom-element
https://unpkg.com/@epa-wg/[email protected]/demo/external-template.html

But when it came to actual library development with multiple components just load external template into local tag is not sufficient. Besides, the import via custom-element tag is quite verbose. The import-tags is more alligned with JS import syntax convenience.