This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 25319 - [imports]: Want some kind of imperative API
Summary: [imports]: Want some kind of imperative API
Status: RESOLVED MOVED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - Component Model (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 normal
Target Milestone: ---
Assignee: Dimitri Glazkov
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 23278
  Show dependency treegraph
 
Reported: 2014-04-10 23:18 UTC by Morrita Hajime
Modified: 2015-07-06 08:06 UTC (History)
5 users (show)

See Also:


Attachments

Description Morrita Hajime 2014-04-10 23:18:35 UTC
It would be nice to have a set of imperative API to

- load import dynamically
- list loaded imports
Comment 1 Dan McDougall 2014-09-08 14:57:42 UTC
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 Travis Leithead [MSFT] 2015-04-16 20:00:56 UTC
Rough sketch:

Promise<Document> importDocument(DOMString url);

Different from XHR due to processing of subresources in the context of the current global.
Comment 3 Hayato Ito 2015-07-06 08:06:37 UTC
Moved to https://github.com/w3c/webcomponents/issues/141