[w3c/webcomponents] JavaScript bundlers, HMR and customElement.define() (#829)

Hi,

I'm working on [SpringType](https://github.com/springtype-org/springtype), a TypeScript-based pure web component framework.

An important part of the developer experience is HMR, hot module replacement, so that code changes in web components are detected, re-transpiled and injected in the current developers browser context on the fly.

It's all shiny and just some LoC away until it comes to re-defining the web component constructor in the browser context. By the means of the current spec and impl it seems to be impossible to do so, because 1+n calls to `window.customElements.define()` with the same element name but different constructor function aren't allowed.

That is kind of sad because it would be amazing to be able to patch a whole DOM tree on the fly. It seems like I'm not the only one having this issue.. In fact even the webpack guys are using some hack to get around this:

https://github.com/aruntk/wc-loader/blob/master/src/index.js#L19

They seem to just use a different element name each time they re-register a web component when HMR comes into play. But this comes with nasty side-effects, like CSS selectors would return "wrong" / different results as they wouldn't match as probably expected...

Basically, I could just do a whole page reload each time I detect a code change of a web component, but well, this is an arguments against web components in general... to be forced to do a page reload in times of HMR and Virtual DOM algorithms isn't very cool :)

I just wanted to ask what the status of the debate is towards this?

Thank you! :)

-- 
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/829