25319 2014-04-10 23:18:35 +0000 [imports]: Want some kind of imperative API 2015-07-06 08:06:37 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - Component Model unspecified PC Linux RESOLVED MOVED P2 normal --- 23278 1 morrita dglazkov dominik mike public-webapps riskable travil public-webapps-bugzilla oldest_to_newest 103718 0 morrita 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 111171 1 riskable 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. 119577 2 travil 2015-04-16 20:00:56 +0000 Rough sketch: Promise<Document> importDocument(DOMString url); Different from XHR due to processing of subresources in the context of the current global. 121657 3 hayato 2015-07-06 08:06:37 +0000 Moved to https://github.com/w3c/webcomponents/issues/141