dynamically load web components

[Matt Bourne]

Sorry if this has been answered elsewhere.

How would you go about dynamically loading a web component - in response to a url route change for example?

Could you simply use javascript to write the html includes and then add the code to the page - would that execute?

[Eric Bidelman]

Hi Matt,

I just wrote an article on Custom Elements for html5rocks. "Instantiating custom

elements" is the section you want:

http://www.html5rocks.com/en/tutorials/webcomponents/customelements/#instantiating

I'm not 100% sure where the native implementation of HTML imports are in regards to dynamic imports. They're working on it. However, just have the include already on the page when it loads.

Btw, this is a great question for Stack Overflow :)

-Eric

Follow Polymer on Google+: plus.google.com/107187849809354688692
---
You received this message because you are subscribed to the Google Groups "Polymer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Matt Bourne]

Hi Eric

It seems there is a similar question on stack exchange 

http://stackoverflow.com/questions/21607663/dynamically-load-web-components-html-imports/21627702#21627702

I wonder if one of the devs could given an updated answer.

I understand that we can instantiate our custom elements just like normal elements at any time. The question is more around loading the html import for the element with all its css and js includes for example using ajax then when it's loaded add the polymer element.

Obviously in a heavy single page web app design I only want to load the slideshow element (for example) if it's actually needed. In my use case I want users to be able to choose between many quite rich elements (flipbook, map, gallery, slideshow) I only want to load those elements if they are used.

Matt

[Eric Bidelman]

Dynamic imports are now supported, but we haven't done a release yet that includes it.

+steve and +scott have a few demos they might be able to share. Both show dynamic/async imports.

Follow Polymer on Google+: plus.google.com/107187849809354688692

---
You received this message because you are subscribed to the Google Groups "Polymer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/edcd77c6-013a-4e98-bb36-1ea19ba3affa%40googlegroups.com.

[Jan Miksovsky]

It looks like dynamic HTML imports are now supported in both Canary (natively) and the polyfill.

From experimentation, it appears that <link> tags programmatically added to the page's light DOM load as expected. However, links added to a shadow subtree are not handled and have no effect.

Can someone please confirm if that analysis is correct?

I tried looking through the spec, which talks about links being associated with the document, but it doesn't specifically say that links in shadow DOM are ignored, so I wanted to check. I ask because I have a component that wants to dynamically load another, and it appears to be able to do so in its light DOM but not its shadow. This to some extent cracks the opacity of the component's internal workings, so I'd been hoping to keep the dynamic links completely within the component's shadow.

[Hajime Morrita]

On Thu, Apr 10, 2014 at 10:21 AM, Jan Miksovsky <j...@quickui.org> wrote:

It looks like dynamic HTML imports are now supported in both Canary (natively) and the polyfill.

From experimentation, it appears that <link> tags programmatically added to the page's light DOM load as expected. However, links added to a shadow subtree are not handled and have no effect.

Can someone please confirm if that analysis is correct?

I tried looking through the spec, which talks about links being associated with the document, but it doesn't specifically say that links in shadow DOM are ignored, so I wanted to check. I ask because I have a component that wants to dynamically load another, and it appears to be able to do so in its light DOM but not its shadow. This to some extent cracks the opacity of the component's internal workings, so I'd been hoping to keep the dynamic links completely within the component's shadow.

This is an interesting question. I filed https://crbug.com/362255 for tracking this.

Would you mind to explain how you intend to use <link rel=import> in Shadow DOM? We could possibly make this work, but I'm not sure if this should work. I don't see how it can be useful. In the context of dynamic loading, we can just put newly created <link> into document.head, cannot we?

Let's compare it to <link rel=stylesheet>. It works in Shadow DOM, and the style is applied to the scope (shadow tree). For imports though, it make less sense to bound it to the scope. Although we could imagine a scoped import whose styleheets are loaded into the Shadow Tree, its benefit isn't clear for me and it will introduce certain complexity to the design.

If it isn't scoped to Shadow DOM, it doesn't make sense to have it in Shadow DOM. Other things like <meta>, non-style <link>, <input>, etc. are hidden from global document scope when it is in Shadow DOM. The current behavior could be explained in this line.

What do you think?

--

morrita

On Friday, February 7, 2014 8:48:35 AM UTC-8, Eric Bidelman wrote:

Dynamic imports are now supported, but we haven't done a release yet that includes it.

+steve and +scott have a few demos they might be able to share. Both show dynamic/async imports.

On Fri, Feb 7, 2014 at 4:29 AM, Matt Bourne <matt...@gmail.com> wrote:

Hi Eric

It seems there is a similar question on stack exchange 

http://stackoverflow.com/questions/21607663/dynamically-load-web-components-html-imports/21627702#21627702

I wonder if one of the devs could given an updated answer.

I understand that we can instantiate our custom elements just like normal elements at any time. The question is more around loading the html import for the element with all its css and js includes for example using ajax then when it's loaded add the polymer element.

Obviously in a heavy single page web app design I only want to load the slideshow element (for example) if it's actually needed. In my use case I want users to be able to choose between many quite rich elements (flipbook, map, gallery, slideshow) I only want to load those elements if they are used.

Matt

Follow Polymer on Google+: plus.google.com/107187849809354688692
---
You received this message because you are subscribed to the Google Groups "Polymer" group.

To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/edcd77c6-013a-4e98-bb36-1ea19ba3affa%40googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

Follow Polymer on Google+: plus.google.com/107187849809354688692
---
You received this message because you are subscribed to the Google Groups "Polymer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/ce563e1c-e264-4df0-8515-28c7ab122b48%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jan Miksovsky]

Hajime: As I indicated above, the scenario I'm facing is one where a component wants to dynamically import some content.

* From at aesthetic perspective, it feels bad for a component to have non-local effects on the document.

* It also exposes some implementation details in the host DOM that are better obscured from the component host. I'd prefer for my component users to generally view my component as a black box that does something useful, and would rather not have them wonder why their document head suddenly has unknown <link> tags in it.

* Finally, this limitation was slightly surprising to me, and might be too others. Given that I can have a static <link> in an imported document, I'd gotten the impression that I could put a <link> anywhere.

This does not seems like a significant problem, but I still wanted to share my experience in case others were similarly confused, and offer it for your consideration.

[Hajime Morrita]

Jan, thanks for sharing your thought! It clarified my understanding.

I think this is rather a symptom of a missing feature, that is an imperative API for HTML Imports, say, System.importDocument(url).

We the spec writers have been thinking about that, but started from declarative API using <link> instead of adding such kind of imperative API for reasons. However for some use cases like dynamic loading, imperative API will fit better. I admit that it is clumsy to add another <link> to document.head just for requesting an import. 

This is a bit off-topic but let me explain why started with <link>:

- It allows us to incorporate with the HTML parser. For example, we can block <script> from running until all imports become ready.

- We see there are similar issues in Web platform. It is not only about imports but also about other linked resources. Think about stylesheets for example, or scripts. It'd better to have some uniform-looking way to load them imperatively but we don't yet figure it out. At the same time we need some loading machinery for web components. As a kind of workaround, we add the API with small surface and limited expressiveness so that we cover major use cases without adding unexpected power that is hard to capture in imperative ways. I concern that shadow-based scoping can be such a "unexpected power".

Anyway, I created a bug to track this topic [1]. I don't expect quick progress in this direction as we Web Component team in Blink is now focusing on stabilizing it. We're aware of this though.

So... Thanks for your patience. We're aware of the problem. Please think it as a symptom of a limitation we're tentatively forcing.

[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25319

--

morrita

--
morrita