Providing templates via light dom

[govis]

One thing that might be useful for Polymer is an easy way to declare element templates in light dom. In general Templatizer requires substantial amount of additional code and is often an overkill when we just want to tweak the element a bit depending on where or how it's being used.

As you can see some PaperElements are currently trying to define different templates for when they are used with Polymer 1 or 2 and are not relying on Templatizer and instead creating their own boilerplate code to swap templates at run-time and embedding it into the elements.

A more common use case would be declaring element template similar how we declare contents to be distributed into its slot(s):

<my-element>
<template id="part-1">
...
</template>
<template id="part-2">
...
</template>
</my-element>

This is more of a question to explore some possibilities in this regard. Thanks

[kevinpschaaf]

We've significantly improved the template system to allow runtime-binding and stamping of templates. this._stampTemplate(template) will return a dom fragment with nodes bound to the element it is called on. Check out the tests here and API docs here (the latest API docs haven't been rendered to the website yet, but you can read them in the code for now).

Can you try the new API's out and see if they meet your needs?

[govis]

Thank you for your response - the new improvements look good and I think that you are on the right track with making basic templating functionality intrinsic to an element.

My use case is slightly different. I have an element with a dom-repeat. I'd like to be able to supply a different template for the dom-repeat when I use the element. Ideally I'd like to have a template property with some default content that I'd bind to the dom-repeat's template and then provide alternative templates as required. Having a couple of lines of code to read the new template contents and push it into the dom-repeat or any other template inside the element would work too.

In this specific case I don't need to stamp it , but simply pass it to the dom-depeat, but I totally see how ease of stamping is likely to come in handy as well. Unfortunately I am having difficulty getting the new template from within the element, this.querySelector('#templateId') gives me null - I think that template of the element itself might be getting in the way somehow. Thanks.

Here's an example of what I'm trying to do:

http://jsbin.com/xozaxetayu/edit?html,output

[aaronanderson]

This Stack Overflow answer https://stackoverflow.com/a/44235946/3750066 implements a solution similar to what you are looking for.

[govis]

Thanks a lot @aaronanderson - that's pretty much what I was looking for, glad you were able to figure it out. Takes a bit more then a couple of lines of code but at least it's doable.

This seems like a common use case, so hopefully they will streamline template handling in future versions. Looks like they've also just been fixing template content cashing in #4597 - something you might have dealt with as well.

[aaronanderson]

this._stampTemplate(template) seems to be an internal API. Can the same effect be somehow reproduced using the documented Polymer.Templatize.templatize(template) API function? The latter uses the former but it references a __dataHost property set to the template itself and I have not found a documented way to override it.

[govis]

Reopening so @kevinpschaaf or someone on the polymer team can answer @aaronanderson question. Please close as you see fit.

[kevinpschaaf]

In Polymer 2.0, we're following a convention across the board that non-underscored methods (denoted with @public) are API for element end-user use, and single-underscored methods (denoted with @protected) are "protected", i.e. for subclasser use. We intend to maintain both API sets (public & protected) per semver rules. It's only private (aka double-underscored members that should be avoided).

So yes, _stampTemplate and _contentForTemplate can be safely used in element code.

Note there's an issue open on the API doc viewer to update the API filtering checkboxes to reflect this (currently what says "Show Private" is actually hiding/showing protected members): PolymerElements/iron-doc-viewer#117