[w3c/webcomponents] Custom Element - untrackable upgrade (#671)

AFAIK there is no way to know when an element would be upgraded to a CE, if not using timers or rAF to verify it's `instanceof` its own defined class.

```js
class TestCase extends HTMLElement {
  static get observedAttributes() { return ['with']; }
  attributeChangedCallback() {
    console.log('%cI have attributes', 'font-weight: bold');
  }
  connectedCallback() {
    console.log('%cI am live', 'font-weight: bold');
  }
}
customElements.define('test-case', TestCase);

const tp = document.createElement('template');
tp.innerHTML = '<test-case with="attribute"></test-case>';

const target = tp.content.firstChild;
const check = mate => console[target instanceof TestCase ? 'info' : 'warn'](mate);

// imagine I'd like to parse `target`
// without compromising its functionality
// and reacting once it gets promoted
// right before connectedCallback or attributeChangedCallback
// basically what V0 createdCallback was doing

check('sync template'); // fails
customElements.whenDefined('test-case').then(() => {
  check('async template');  // fails

  // triggers attribute and conected
  document.body.appendChild(target);

  check('sync live'); // OK
  customElements.whenDefined('test-case').then(() => {
    check('async live');  // OK
    console.log(target.outerHTML);
  });
});
```

Specially when it comes to interact with templates, something both _hyper_ and _lit_ HTML libraries do, it's fairly impossible to behave properly with parsed attributes and/or trust the prototype.

Is there any event or planned callback that would solve this? The `constructor` is not good enough and third parts libraries can only know, through the node name and the registry, if the node is a Custom Element, but these libraries have no way to understand when such node will behave like one.

Patching `connectedCallback` and `attributeChangedCallback` directly on the node feels wrong and it's a very dirty approach.

Thanks for any sort of clarification/plan/idea/hint .. you name it.


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