Support renaming, aliasing, or namespacing imported elements

[philipwalton]

I've heard this topic mentioned in external discussions, but I don't see any issues about it here, so I'm posting this to get it on the record.

One major complaint I've heard in regards to HTML Imports and Custom Elements as they're currently spec'ed is that they're global and can't be renamed on a per-project basis. I see two relatively common cases where this will be an issue:

• An app is using an <x-foo> component and wants to switch to a different component, also named <x-foo>, without upgrading their entire codebase all at once.
• An app wants to use the components <x-foo> and <x-bar>, yet both of them (somewhere in their dependency tree) import different components named <x-qux>.

ES2015 modules have a really good way of handling this -- the module definition is essentially anonymous until it's given a name at import time and module imports are local to the module importing them.

It seems like Custom Elements could (and arguably should) operate in a similar manner.

I'm aware Mozilla has expressed that they do not plan to implement HTML Imports, though I'm unaware if an alternate proposal has been presented.

[domenic]

If https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Constructor-Dmitry.md ends up being accepted, then all it takes is for component authors to start exporting classes, without calling document.registerElement themselves.

[bedeoverend]

@domenic for @philipwalton's second example, where an app uses two custom elements that both require different, but of the same name, components - would the constructor proposal above resolve that? Am I right in thinking it would then require a component author to take components as parameters in their constructors, a la dependency injection?

Is there also the possibility of simply using unique registries? Or more simply I guess on a unique document, rather than the global document. In which case an author could register the elements they depend on in their own document, and export their resulting component as a class.

[domenic]

It doesn't really solve the issue if they both must have the same name. Rather, it makes it easier for app authors to choose the names, thus avoiding any name collisions in the first place.

The sacrifice is that library authors cannot use innerHTML (since they don't know what tag name the app author will use) and cannot target subcomponents with CSS by tag name (for the same reason).

Is there also the possibility of simply using unique registries? Or more simply I guess on a unique document, rather than the global document.

@esprehn had some cool ideas along these lines, which partially helped solve the CSS problem (but still left innerHTML broken, as it always is in multi-document scenarios). I think it's promising.

[bedeoverend]

It would be great if could use separate registries. I mocked up a JSBin of it in action, where there are two my-element with different prototypes, though as you've said, innerHTML and CSS is still an issue. Should this even work, or is it just a hack that may break in the future?

Also, and perhaps this is a discussion for another thread, but in the above example I was forced to use an iframe, rather than something like document.implementation.createHTMLDocument as only in the iframe did the registry appear unique. Should creating a new HTMLDocument have a unique registry?

[domenic]

Should this even work, or is it just a hack that may break in the future?

Yeah, it should definitely work, although nothing about custom elements is final until we get a consensus spec sadly.

Should creating a new HTMLDocument have a unique registry?

Probably yes; see #236

[bedeoverend]

Thanks @domenic that clears it up a lot. Looks like it's best to just hold off on any of these until more of a consensus is reached on it. I'll keep an eye on #236, hopefully that'll help with unique registries.

[annevk]

Resolving this as a duplicate of #154.

[Vinnl]

@annevk #154 has been closed because it was mostly about registries, which this issue is not about. Would it be possible to re-open this issue? We're currently being bitten by this pretty hard.

[annevk]

@Vinnl at this point it's probably best to open a new issue to outline the problem. Note also that HTML Imports never went anywhere and the replacement idea (HTML modules) isn't really a thing yet.

[Vinnl]

@annevk Thanks for the update. I didn't realise HTML Imports were completely blown off - I guess that means we're stuck, since we're using Polymer which is still based on HTML imports and probably won't implement any aliasing/namespacing on that if it's dead.

[annevk]

https://github.com/w3c/webcomponents/blob/gh-pages/proposals/HTML-Imports-and-ES-Modules.md has some thoughts on the replacement, but that still seems some ways off. Everyone but Google basically wants to see if JavaScript modules end up changing the design space here.

[Vinnl]

Thanks for the link, we'll keep an eye on that and try to find a workaround to use until that settles down.

[matthewp]

@annevk Isn't that doc written by a Googler and is designed on top of the JS module system? Maybe you mean something else, that others are not interested in speccing HTML modules until JS modules have matured? Just trying to get a read on your opinion here. Thanks :)

[annevk]

Sorry, yeah, I suppose the new status quo is that Google is on board with exploring other solutions (though doesn't want to remove HTML Imports until others commit), but others want to wait until we have more experience with JavaScript modules. I think the minimum bar was getting them shipped in several browsers (which seems pretty close now).