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

For the HMR use-case callbacks can be dealt with by defining all of them and having them delegate to the new definition. It certainly would be nice if that wasn't necessary though. For attributes this could also be addressed with a wild-card option.

What are the hazards of allowing re-definition of elements? Could we add an option to `define()` that allows a replacement? This would help a little, though it doesn't actually give anyone HMR, that still needs to be implemented on a custom basis, IMO.

We recently got a limited form of HMR working within Google by patching `customElements.define` to pass a duplicate definition back to the originally defined class, which can then patch itself as it sees fit. LitElement's implementation then updates styles and re-renders templates. That's the custom part. I do wonder if there could be a standard class-level callback for redefinition, ie:

```js
class MyElement {
  static observedAttributes = [...];

  static redefine(newClass) {
    ...
  }
}
```

-- 
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-524948016