DCE modular development & distributable libs

[sashafirsov]

modules, packages, dependencies

• DCE module is a HTML, SVG, MathML, XML, or XSLT file.
• The module file is a container for single or multiple templates or resources.
• Package or library is a set of modules and associated resources
• distributed as sub-folder in web app, on CDN or on NPM repository

dependencies mechanics

DCE as any another programming language module would need to

• expose its components (export)
• load the templates from another library
• reference own resources as in same module as within own library

Web standards come up with solution for JavaScript modules: importmap. Which logic and API is sufficient for DCE modular needs.

static import

The static import in JS modules matches the use of src attribute in custom-element.

<custom-element src="XXX"></custom-element>

access to resolved URL

The access for other than DCE modules resources like images would need the resolved URL available in template. The import.meta.resolve(path) given the resolved URL for consumption by JS. In custom-element the implementation does not provide the direct access to JavaScript for security and performance reasons. Instead, $module-url reserved variable is injected by template loader. This variable can be used as base-url to resolve relative path by location-element.

But location-element is a reflection of Location and not aware of import map for package resolution.

module-url implements the import.meta.resolve( path ) API and exposes it in named data slice.

<module-url slice="lib-url" src="lib-root/embed-lib.html#embed-relative-hash"></module-url>
<if test="//lib-url/@error">
      <p>error: <b>{//lib-url/@error}</b></p>

</if>
<img src="{//img-url}" alt=""/>

Relative path( started with dot .) is resolved by URL API with module url as the base, the symbolic names and absolute URLs are resolved by import.meta.resolve( path ) .

Internally the xml:base attribute is set on dce-root to be used by module-url as the resolution base for relative path. It can be used for troubleshooting in dev tools.

[sashafirsov]

tag definitions overlap

Till the scoped registriess are in place, DCE embedding with same tag names are going to be in conflict. But even with scoped registry, the library concept as coherent web components collection can not be solved without namespase scope introduced.

Possible solution

• override the tag with either container-specific prefix|namespace and the occurrences in template.
• implement the namespace scope for compoments withing same library/package.

work around

use the guideline for prefixing the library components. Not reliable, still only way as of now without scoped and namespaced registry.