Nat Knight

#til #javascript #webdev #customelements

I was working on a custom element today that replaces a textarea with CodeMirror in the UI while still updating the textarea in the background so that it can be submitted in a form. I ran across a wild footgun in custom elements.

StackOverflow eventually provided the solution. There's a solution on stack overflow, but Danny Engleman wrote up a more thorough explanation.

When you're creating a custom element you do most of your setup in a method called connectedCallback. Here you can read the content of the custom element, replace it with different elements, set up callback handlers, etc.

Or so I thought.

You can read the attributes of the node just fine, but if you try to read its contents you'll find they aren't there. The reason is that the connectedCallback fires when the opening tag of the custom element is parsed, so the contents aren't in the DOM yet.

The solution is breathtakingly simple and silly: call setTimeout to defer initialization until after the DOM has been fully parsed.

export class MyCustomElement extends HTMLElement {
  initialize () {
    // Fancy custom element stuff goes here; you can safely access
    // `this.innerHTML` and stuff.
  }

  connectedCallback() {
    // Be sure to use an arrow function here or 'this' will be
    // messed up in `initialize.
    setTimeout(() => this.initialize(), 0)
  }
}