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

> standard supporting HMR for Web Components in a way that we wouldn't need any polyfills

I think I like the idea of re-definitions, but not sure what the complexities are.

Userland code would be clean and nothing in a custom element class definition would need to be HMR-specific, because on re-definition the current elements' `disconnectedCallback`s are simply called and the elements would clean themselves up before being downgraded then upgraded into the new elements (carrying along existing own props for sake of simplicity).

HMR code would only need to re-define the element, outside of the class definition.

> This inconvenience is better to be addressed by the JS bundlers via polyfills

This puts a ton of complexity in the userland code, as @kyr0 describes. 

> Not allowing to redefine the custom element makes perfectly sense from the browser's point of view.

Trying to understand why. Seems like it was just easier to do it that way from an implementation perspective. What are the invariants @bathos?

> I would assume an HMR implementation to call the disconnectedCallback on the old component, remove all the markup from the DOM and then call manually the constructor and the connectedCallback on the new component.

That's basically what I'm imagining  a native redefinition feature would do.

-- 
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#issuecomment-560004604