[templates] Is a global registry of template processors the right idea?

[domenic]

The alternative, in my view, is requiring imperative code to instantiate templates given processors, as in the API at https://github.com/domenic/template-parts#the-templateinstantiate-method or similar. (Inspired by our previous discussions.)

This would require libraries and frameworks to come up with their own, possibly fragmented syntax for doing declarative templating. But it seems harsh to force another global registry on people given how much complaining we get around the global registry of element names in custom elements. There it was unavoidable, but here it seems pretty avoidable.

Maybe we should have both, i.e. have an underlying imperative API and then if you want to use a global registry that the browser provides, you can? The idea being that more advanced frameworks would then be able to take advantage of the functionality here without necessarily locking themselves into the browser-supplied global registry.

[rniwa]

We think the ability to specify a template type declaratively in HTML is important so that the user of a template library doesn't need to specify it every time creating a template instance.

Supporting the both is fine. Alternatively, we can support a scope at a shadow tree level.

[Jamesernator]

Why was the global registry of Custom Elements unavoidable? The fact it exists is one of the reasons I still avoid custom elements for the most part. I can't see why it wouldn't be possible to have shadowRoot.customElements in addition to window.customElements.

Regardless I think template types shouldn't make the same mistake as otherwise there's going to be an even higher chance of namespace collisions for distributed templates given names like for-each/if/etc will almost certainly be commonplace.

[rniwa]

Yeah, I think having a template type registry at a shadow root level is highly desirable.

[domenic]

At TPAC, we decided that for v1, there would be no global registry, so if you want to use purely declarative syntax, you'll need to accept the default processor. Assigning to @rniwa to update the proposal in that direction (perhaps by pulling some stuff out into a separate v2 document).

[cdata]

In experimenting with polyfills for this feature, I found it most convenient to specify the template processor when HTMLTemplateElement.prototype.createInstance is invoked, similarly to what @domenic demonstrated in his Template Parts proposal. E.g., template.createInstance(myProcessor, optionalValues).