Comments on: An Approach to Lazy Loading Custom Elements

By: Frederik Dohr

Frederik Dohr — Wed, 15 Feb 2023 09:16:41 +0000

I’d be interested to see an example of your iframes approach, Michael; care to put it in a CodePen or Gist? (The latter would allow for dedicated discussions.)

I sympathize with the HTML Import mourning, though I go back and forth on what it could or should have been.

By: Michael Ninin

Michael Ninin — Tue, 14 Feb 2023 06:21:27 +0000

I am still dreaming of html imports. Think of any landing sections in separate html files. The important thing for me is I want for them to be shown in Sources tab along with others. So fetch is not helpful. So I tried a dedicated custom element with iframes loading separate html files in it, and that element is grabbing their documents contents and move them into our main one. That is solving my issue with showing them in Sources tab. But races are killing me… It works like 15 times out of 16.(

By: Frederik Dohr

Frederik Dohr — Mon, 13 Feb 2023 20:27:21 +0000

Oh, I hadn't thought of :defined in this context; that's an excellent idea and much more elegant, thank you! I agree that an approach like that elems object can be advantageous in some scenarios (thus the cautionary aside in the introduction). In my case, I specifically didn't want to rely on bundlers or similar tooling though.

By: Molly Stewart-Gallus

Molly Stewart-Gallus — Mon, 13 Feb 2023 19:59:18 +0000

Why not use :not(:defined) to query for unloaded elements. I would also use a different sort of autoloader which is more easily WebPackable. Something like

const elems = {
  'my-elem': () => import('./my-elem.js')

}; // ... customElements.define(elem, await elemselem. default);`