[imports]: Want some kind of imperative API (bugzilla: 25319)

[hayatoito]

Title: [imports]: Want some kind of imperative API (bugzilla: 25319)

Migrated from: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25319

---

comment: 0
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25319#c0
Morrita Hajime wrote on 2014-04-10 23:18:35 +0000.

It would be nice to have a set of imperative API to

• load import dynamically
• list loaded imports

---

comment: 1
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25319#c1
Dan McDougall wrote on 2014-09-08 14:57:42 +0000.

I just wanted to add that this will be a very important feature for applications that wish to cache web components in browser storage (e.g. IndexedDB) or load web components via a WebSocket connection. It also allows for making changes to web components (say, changing the element name or inserting additional stylesheets) before they get loaded which would be a killer feature.

My Use Case:

Personally, I just need a mechanism that would allow me to load a web component via a WebSocket without requiring a separate GET request. My application (Gate One) gets embedded into other web pages directly (no iframe) and it loads/synchronizes all of its assets (JS, CSS, and now HTML templates) over a single WebSocket connection. It caches assets via IndexedDB (with localStorage fallback) and only re-downloads them when a file gets changed on the server. That asset synchronization works incredibly well: It's much faster than individual GET requests and more flexible and efficient than concatenation. However, there's no way for me to take advantage of web components (currently) using that same mechanism. If I could download a web component over the WebSocket and load it into the page somehow that would solve the problem.

Even if I could provide a data::URI as the 'href' attribute to a link tag that would work. I'd just create the data::URI from the cached web component on-the-fly so the inefficiency of base64 encoding would be moot.

---

comment: 2
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25319#c2
Travis Leithead [MSFT] wrote on 2015-04-16 20:00:56 +0000.

Rough sketch:

Promise importDocument(DOMString url);

Different from XHR due to processing of subresources in the context of the current global.

[TakayoshiKochi]

Let me close this issue as we do not spend time on HTML Imports moving forward.

You can do it with creating <link rel=import> element dynamically today.
(listing is left unresolved, though it could be done in server-side parsing and dumping it as a list of `, maybe)