10 ms·

Templating in HTML

200 points by clairity 4y ago

icedchai 4y ago
In the jquery days, I would often do this sort of thing with hidden divs.
- cantSpellSober 4y ago
  You weren't doing the same thing, though it may have had the same effect. Template elements aren't part of the "main" DOM.
  - icedchai 4y ago
    It had the same effect, yes, which it what I meant. The hidden div was effectively used as a template, by cloning the element and doing some awful manual data binding from JS.
- clairity 4y ago
  i remember doing stuff like that too, but now it's official! ha. it's exciting to see web standards (finally) taking direction from web developers rather than corporate interests, despite chrome being so prominent. as a random aside, i'm especially hoping forms get more love, like the common behaviors (datetime entry, combobox, validation/feedback, etc.) that every developer has to wrangle with over and over. and it's great to see things like the <modal> element becoming almost fully usable without js (it still needs to be triggered via js, but can be closed with a method='dialog' form button).
  - runarberg 4y ago
    Datetime is mostly there. I think firefox and safari have yet to implement <input type=month> and <input type=week>. As for combobox, <datalist id=mylist> and <input list=mylist> is supported everywhere. However I would like to see the CSSWG focus on better standards for styling these, it is possible now using a lot of vendor-specific hacks, but is really annoying. I’m gonna go ahead though and declare frontend validation (as good as) finished. the constraint validation API is amazing to work with (if you are not afraid of intercepting the submit event using JavaScript).
    - clairity 4y ago
      yah, for datetime, i was mostly thinking about styling the widget via css (and perhaps a bit of configuration via json), with the flexibility that all those datetime components had from the jquery days. month and week are indeed just text fields in firefox (just tested it). and for validation, i'd like it to be js-less, as it's such an integral part of the form use case. there are recent features that help, like :user-invalid and :focus-within, but it's still far from ideal for default behavior. something as simple as styling labels based on validation state of the input is only possible with the advent of :has(), which is still incomplete/experimental in firefox, but even that's still clunky (there's a combinatorial explosion of possible states to cover, having to consider :disabled, :hover, :required, :focus, etc.).
  - recursive 4y ago
    now? finally? I've been using <template> for almost a decade.
TedDoesntTalk 4y ago
Been doing today for years with a custom tags. name it anything you want. <foo/> works
- synn 4y ago
  And if you want it to be a valid HTML custom-element, just throw a dash in the name (like <v-foo>). https://html.spec.whatwg.org/#valid-custom-element-name https://html.spec.whatwg.org/#valid-custom-element-name
labrador 4y ago
> Let’s start with the fact that <template> do not enabling you to do anything that’s not possible otherwise. In that way, it’s more of a convenience tool really. If you have significant HTML structures that need to be injected at runtime, it might be very cumbersome to do so manually with document.createElement and element.setAttribute. I didn't expect the paragraph to end that way. I would write it: Let’s start with the fact that <template> do not enabling you to do anything that’s not possible otherwise. In that way, it’s more of a convenience tool really. If you have significant HTML structures that need to be injected at runtime, you can use "display:none" to hide the HTML structure, then copy node to make and show a copy, for example a dialog box Anyway, that's how I've been doing it. If <template> has some advantages, I'll start using it
- kitsunesoba 4y ago
  Front end web is not my forte, but as I understand display:none; can have unintended (usually negative) interactions with screen readers, which I don't believe is a possibility with HTML templates.
  - grimgrin 4y ago
    There’s a way to hide from screen readers too if the OP was so inclined: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-hidden https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...
    - cantSpellSober 4y ago
      display: none hides the content from screen readers, as it is not rendered. aria-hidden is for elements that were rendered but are hidden (it's redundant on elements with a display value of `none`)
      - grimgrin 4y ago
        oh yes yes. what was i thinking! ty for correction
Gualdrapo 4y ago
I'm redoing from scratch my portfolio using plain JavaScript and <template>s for most stuff, pulling everything from a JSON as a pseudo database. I think for this kind of uses <template> is great, but you can really wish it has some extra features like the ability to define repeating block sections so you didn't need to declare nested <template>s for what would be a single block code.
asadlionpk 4y ago
I wrote apps this way before React came along. I hated inserting/updating values by hand with no binding.
verisimilidude 4y ago
The <template> tag really shines when used alongside <slot> and the Shadow DOM. But I really wish there were an HTML-native way to load <template> from separate files, the same way we do with CSS and JS. Not a show-stopper, but it’d be very nice to have.
- goatlover 4y ago
  > But I really wish there were an HTML-native way to load <template> from separate files Seems like the JS folks blocked this from happening. It's weird to me to think we've arrived at the point where JS considerations have come to dominate for something that was built to be a document sharing platform.
  - spankalee 4y ago
    No one blocked it. If you're referring to HTML Imports, the problem with them is that they didn't integrate with JS modules. There's a new HTML modules proposal [1], and with JS import assertions and CSS and JSON modules landing [2], HTML modules are probably not far behind. [1]: https://github.com/WICG/webcomponents/blob/gh-pages/proposals/html-modules-proposal.md https://github.com/WICG/webcomponents/blob/gh-pages/proposal... [2]: https://web.dev/css-module-scripts/ https://web.dev/css-module-scripts/
    - dmitriid 4y ago
      goatlover: Seems like the JS folks blocked this from happening. spankaalee: not true, they were removed because.... they were't compatible with JS --- goatlover: JS considerations have come to dominate for something that was built to be a document sharing platform. spankalee: here are two proposals which are... Javascript-only, don't work without javascript, and add more Javascript to the platform --- ¯\_(ツ)_/¯
  - dmitriid 4y ago
    > where JS considerations have come to dominate Not JS. Chrome, and their decade-old crusade to make web components happen, no matter the cost or common sense
twism 4y ago
Man ... I would have been thrown off a cliff if I did this in the 2000s
geuis 4y ago
Can't this be done more easily / programmatically via createDocumentFragment? https://developer.mozilla.org/en-US/docs/Web/API/Document/createDocumentFragment https://developer.mozilla.org/en-US/docs/Web/API/Document/cr...
- colejohnson66 4y ago
  That's what the `<template>` element does. From the HTML standard[0]: > The template element can have template contents, but such template contents are not children of the template element itself. Instead, they are stored in a DocumentFragment associated with a different Document — without a browsing context — so as to avoid the template contents interfering with the main Document. [0]: https://html.spec.whatwg.org/multipage/syntax.html#template-syntax https://html.spec.whatwg.org/multipage/syntax.html#template-...
spankalee 4y ago
<template> is great, but some people are surprised that it doesn't include any form of parameterization or expressions. The entire process of cloning a template and updating it with data is left up to the developer - it's pretty low level. That's why my team made the lit-html library, which uses JS tagged template literals to make <template> elements for you, clone them and interpolate data where the JS expressions are, and then update the result really, really fast with new data: import {render, html} from 'https://unpkg.com/lit?module'; let count = 0; function increment() { count++; renderCount(); } function renderCount() { render(html` <p>The count is ${count}</p> <button @click=${increment}>Increment</button> `, document.body); } renderCount(); You can try that out here: https://lit.dev/playground/#gist=1eff9baed1251fc60dd7da8b7f9f8b4f https://lit.dev/playground/#gist=1eff9baed1251fc60dd7da8b7f9... We're also working with Apple on a proposal called Template Instantiation which brings interpolations and updates into HTML itself (though the pandemic and things really stalled that work for the moment).
- bugmen0t 4y ago
  Do you have a link to the template instantiation proposal?
  - twsted 4y ago
    In the past I've seen this one: https://github.com/WICG/webcomponents/blob/gh-pages/proposals/Template-Instantiation.md https://github.com/WICG/webcomponents/blob/gh-pages/proposal... Perhaps there are more recent versions. I liked the spirit of the proposal, but never studied it.
- voxal 4y ago
  lit-html is great. I use it for a lot of projects whenever I need some simple tempted HTML. That being said, it seems like the v1 documentation for lit-html [1] has been removed in favor of a single page in the v2 documentation [2]. Is using lit-html standalone not recommended anymore? I really liked using it standalone. [1] https://lit.dev/docs/v1/lit-html/introduction/ https://lit.dev/docs/v1/lit-html/introduction/ [2] https://lit.dev/docs/libraries/standalone-templates/ https://lit.dev/docs/libraries/standalone-templates/
lawwantsin17 4y ago
lawwantsin17 4y ago
chrismorgan 4y ago
> 'content' in document.createElement('template') Any reason you’d write this instead of window.HTMLTemplateElement, which is shorter to type and more efficient to evaluate?
asplake 4y ago
How does <template> differ from <script type="text/x-my-templating-lang">?
- bugmen0t 4y ago
  template does HTML parsing. The `content` attribute returns a DocumentFragment.
brundolf 4y ago
Sorry, but the <template> tag doesn't actually do "templating in HTML" ...but it should. It's shocking to me that we've had the modern paradigm of client-side-rendering frameworks for over a decade now, without so much as an RFC for any kind of native support. For the sake of render performance, bundle size, removing a need for transpilation, compatibility across frameworks. There are a million reasons this should be happening in the browser at this point. I'm sure it's a complicated standard to come up with (for one: HTML-based vs JS-based rendering), but why does it feel like nobody's even trying?
- encryptluks2 4y ago
  Because JS is where the privacy holes are at and keep getting added.
- tannhaeuser 4y ago
  There's no lack of syntactical templating mechanisms when HTML is hosted within a SGML markup processing context (ie how HTML started life), and no need to add templating at the HTML markup vocabulary level either: For server-side rendering, SGML (and also some other template "engines") provide HTML-aware, type-checked, parametric macro expansion. Actually, SGML templating works transparently on the client side and the server side. Within the browser OTOH, there's already JavaScript, making every dynamic feature added to HTML inessential for better or worse, like it has for over 25 years now. That's just how it was decided a long time ago, and adding half-assed features to HTML like the template element (which requires JavaScript, in turn, thus doesn't add any essential capability) all the time is exactly the thing we shouldn't be doing when the damn "web stack" is already bloated as fuck.
lenkite 4y ago
I wish HTML and not just JS had supported for consuming templates. That is I wish we could do variants of: 1. Define Template using <template id="card-template">...</template> 2. Consume Template using <use-template id="card1" refid="card-template">..</use-template> With substitution variables/text, this feature could be amazing.
- blowski 4y ago
  > With substitution variables/text, this feature could be amazing. At which point, are you just re-creating JavaScript?
  - dspillett 4y ago
    Not quite, I think he is taking about a more declarative approach compared to that offered by vanilla JS.
  - vbezhenar 4y ago
    But works with disabled JS.
- akira2501 4y ago
  Here's what I got: const $template = function(template) { // make copy of template content const root = template.content.cloneNode(true); // create proxy object for accessing named nodes and root const obj = { get $root() { // after template root is called, remove this getter function delete obj.$root; // return root only once return(root); } }; // find all named template nodes and add to proxy object for (const node of root.querySelectorAll('[data-tmpl-name]')) obj[node.dataset.tmplName] = node; // otherwise create template node content wrapped in proxy which // makes attempts to overwrite properties an error. return(new Proxy(obj, { set: () => { throw (new Error(`Attempt to overwrite a template node!`)); } })); } You can use it with something like: <template id="some_id"> <div> <h3 data-tmpl-name="header"></h3> <h5 data-tmpl-name="title"></h5> </div> <p data-tmpl-name="info"></p> </template> And then just: function of_some_sort() { const t = $template(document.getElementById('some_id')); t.header.innerHTML = 'The Header'; t.title.innerHTML = 'The title'; t.info.innerHTML = 'More stuff.'; document.body.append(t.$root); } This is was the first version I made. It's not hard to get from here to a version that can fill the template with a data object for you. In my most recent version, you could do: function of_another_sort() { document.body.append($template(document.getElementById('some_id'), { header: 'The Header', title: ['first title', 'second title'], info: (elem) => { elem.setAttribute('functions', 'work'); elem.innerHTML = 'and receive the internal element itself.'; } })); } Arrays duplicate the internal element and make copies of it, objects recurse into the element building a 'key.path.name' while looking for data-tmpl-name to replace. Functions get a copy of the element for more than just innerText/innerHTML replacement. A null or false value eliminates the internal element, and a true value passes it through unchanged. If you've ever used the old ruby library Amrita, it's basically that, but for HTML Template elements. You can easily do all this in about 100 lines of JS.
p2detar 4y ago
I appreciate this type of posts very much. Short, neat and to the point. I learned something today. Till now, I've always used: <script id="app-item-template" type="text/x-custom-template"> I'll definitely have <template> in mind from now on. Thank you!
pretzelhands 4y ago
<template> tags are so incredibly useful for keeping your JS clean when you're not able to have something more reactive around for some reason. I've recently used that on an interview project I did (https://github.com/pretzelhands/ubiquitous-sniffle https://github.com/pretzelhands/ubiquitous-sniffle) and it surprisingly takes you quite far with very little effort. The only major annoyance is really manually keeping track of the elements in the DOM and .innerText and .innerHTML-ing everything that needs a dynamic value. But it's manageable if you keep it confined.
- wildrhythms 4y ago
  This approach always seems so easy at first glance, but I find it gets rather unwieldy as soon as I need to update some deeply nested value- like updating a innerText in cell in a table in a card in a layout of a thousand cards without re-rendering the entire collection. I started using lit-html and it solves this problem (and only costs me 3KB or so to ship).
- akrymski 4y ago
  I've used this approach in my minimal MVC lib for over a decade, simply using hidden elements instead of templates http://krymski.com/espresso.js/ http://krymski.com/espresso.js/
- ohmahjong 4y ago
  Is the demo site still supposed to be up? I see > TypeError: path must be absolute or specify root to res.sendFile when I try to visit it.
cookiebyt3s 4y ago
i didn't know templates were inert. cool!
quickthrower2 4y ago
Modulo performance, why not store the html string in JS if you are going to use JS anyway, and with string interpolation it is more templatey anyway.
- xigoi 4y ago
  With templates, you can do things like template.querySelector("label").
  - quickthrower2 4y ago
    True! that would be less elegant with the string, as you would need to make it effectively into a <template> or hidden div to do such a thing.
kellengreen 4y ago
Please can we ship HTML Modules soon? https://chromestatus.com/feature/4854408103854080 https://chromestatus.com/feature/4854408103854080
Traubenfuchs 4y ago
What's the difference between using <template> and just putting your template content in a div with visibility:hidden?

Templating in HTML

200 points by clairity 4y ago

icedchai 4y ago

In the jquery days, I would often do this sort of thing with hidden divs.

cantSpellSober 4y ago
You weren't doing the same thing, though it may have had the same effect. Template elements aren't part of the "main" DOM.
- icedchai 4y ago
  It had the same effect, yes, which it what I meant. The hidden div was effectively used as a template, by cloning the element and doing some awful manual data binding from JS.
clairity 4y ago
i remember doing stuff like that too, but now it's official! ha. it's exciting to see web standards (finally) taking direction from web developers rather than corporate interests, despite chrome being so prominent. as a random aside, i'm especially hoping forms get more love, like the common behaviors (datetime entry, combobox, validation/feedback, etc.) that every developer has to wrangle with over and over. and it's great to see things like the <modal> element becoming almost fully usable without js (it still needs to be triggered via js, but can be closed with a method='dialog' form button).
- runarberg 4y ago
  Datetime is mostly there. I think firefox and safari have yet to implement <input type=month> and <input type=week>. As for combobox, <datalist id=mylist> and <input list=mylist> is supported everywhere. However I would like to see the CSSWG focus on better standards for styling these, it is possible now using a lot of vendor-specific hacks, but is really annoying. I’m gonna go ahead though and declare frontend validation (as good as) finished. the constraint validation API is amazing to work with (if you are not afraid of intercepting the submit event using JavaScript).
  - clairity 4y ago
    yah, for datetime, i was mostly thinking about styling the widget via css (and perhaps a bit of configuration via json), with the flexibility that all those datetime components had from the jquery days. month and week are indeed just text fields in firefox (just tested it). and for validation, i'd like it to be js-less, as it's such an integral part of the form use case. there are recent features that help, like :user-invalid and :focus-within, but it's still far from ideal for default behavior. something as simple as styling labels based on validation state of the input is only possible with the advent of :has(), which is still incomplete/experimental in firefox, but even that's still clunky (there's a combinatorial explosion of possible states to cover, having to consider :disabled, :hover, :required, :focus, etc.).
- recursive 4y ago
  now? finally? I've been using <template> for almost a decade.

TedDoesntTalk 4y ago

Been doing today for years with a custom tags. name it anything you want. <foo/> works

synn 4y ago
And if you want it to be a valid HTML custom-element, just throw a dash in the name (like <v-foo>). https://html.spec.whatwg.org/#valid-custom-element-name https://html.spec.whatwg.org/#valid-custom-element-name

labrador 4y ago

> Let’s start with the fact that <template> do not enabling you to do anything that’s not possible otherwise. In that way, it’s more of a convenience tool really. If you have significant HTML structures that need to be injected at runtime, it might be very cumbersome to do so manually with document.createElement and element.setAttribute. I didn't expect the paragraph to end that way. I would write it: Let’s start with the fact that <template> do not enabling you to do anything that’s not possible otherwise. In that way, it’s more of a convenience tool really. If you have significant HTML structures that need to be injected at runtime, you can use "display:none" to hide the HTML structure, then copy node to make and show a copy, for example a dialog box Anyway, that's how I've been doing it. If <template> has some advantages, I'll start using it

kitsunesoba 4y ago
Front end web is not my forte, but as I understand display:none; can have unintended (usually negative) interactions with screen readers, which I don't believe is a possibility with HTML templates.
- grimgrin 4y ago
  There’s a way to hide from screen readers too if the OP was so inclined: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-hidden https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...
  - cantSpellSober 4y ago
    display: none hides the content from screen readers, as it is not rendered. aria-hidden is for elements that were rendered but are hidden (it's redundant on elements with a display value of `none`)
    - grimgrin 4y ago
      oh yes yes. what was i thinking! ty for correction

Gualdrapo 4y ago

I'm redoing from scratch my portfolio using plain JavaScript and <template>s for most stuff, pulling everything from a JSON as a pseudo database. I think for this kind of uses <template> is great, but you can really wish it has some extra features like the ability to define repeating block sections so you didn't need to declare nested <template>s for what would be a single block code.

asadlionpk 4y ago

I wrote apps this way before React came along. I hated inserting/updating values by hand with no binding.

verisimilidude 4y ago

The <template> tag really shines when used alongside <slot> and the Shadow DOM. But I really wish there were an HTML-native way to load <template> from separate files, the same way we do with CSS and JS. Not a show-stopper, but it’d be very nice to have.

goatlover 4y ago
> But I really wish there were an HTML-native way to load <template> from separate files Seems like the JS folks blocked this from happening. It's weird to me to think we've arrived at the point where JS considerations have come to dominate for something that was built to be a document sharing platform.
- spankalee 4y ago
  No one blocked it. If you're referring to HTML Imports, the problem with them is that they didn't integrate with JS modules. There's a new HTML modules proposal [1], and with JS import assertions and CSS and JSON modules landing [2], HTML modules are probably not far behind. [1]: https://github.com/WICG/webcomponents/blob/gh-pages/proposals/html-modules-proposal.md https://github.com/WICG/webcomponents/blob/gh-pages/proposal... [2]: https://web.dev/css-module-scripts/ https://web.dev/css-module-scripts/
  - dmitriid 4y ago
    goatlover: Seems like the JS folks blocked this from happening. spankaalee: not true, they were removed because.... they were't compatible with JS --- goatlover: JS considerations have come to dominate for something that was built to be a document sharing platform. spankalee: here are two proposals which are... Javascript-only, don't work without javascript, and add more Javascript to the platform --- ¯\_(ツ)_/¯
- dmitriid 4y ago
  > where JS considerations have come to dominate Not JS. Chrome, and their decade-old crusade to make web components happen, no matter the cost or common sense

twism 4y ago

Man ... I would have been thrown off a cliff if I did this in the 2000s

geuis 4y ago

Can't this be done more easily / programmatically via createDocumentFragment? https://developer.mozilla.org/en-US/docs/Web/API/Document/createDocumentFragment https://developer.mozilla.org/en-US/docs/Web/API/Document/cr...

colejohnson66 4y ago
That's what the `<template>` element does. From the HTML standard[0]: > The template element can have template contents, but such template contents are not children of the template element itself. Instead, they are stored in a DocumentFragment associated with a different Document — without a browsing context — so as to avoid the template contents interfering with the main Document. [0]: https://html.spec.whatwg.org/multipage/syntax.html#template-syntax https://html.spec.whatwg.org/multipage/syntax.html#template-...

spankalee 4y ago

<template> is great, but some people are surprised that it doesn't include any form of parameterization or expressions. The entire process of cloning a template and updating it with data is left up to the developer - it's pretty low level. That's why my team made the lit-html library, which uses JS tagged template literals to make <template> elements for you, clone them and interpolate data where the JS expressions are, and then update the result really, really fast with new data: import {render, html} from 'https://unpkg.com/lit?module'; let count = 0; function increment() { count++; renderCount(); } function renderCount() { render(html` <p>The count is ${count}</p> <button @click=${increment}>Increment</button> `, document.body); } renderCount(); You can try that out here: https://lit.dev/playground/#gist=1eff9baed1251fc60dd7da8b7f9f8b4f https://lit.dev/playground/#gist=1eff9baed1251fc60dd7da8b7f9... We're also working with Apple on a proposal called Template Instantiation which brings interpolations and updates into HTML itself (though the pandemic and things really stalled that work for the moment).

bugmen0t 4y ago
Do you have a link to the template instantiation proposal?
- twsted 4y ago
  In the past I've seen this one: https://github.com/WICG/webcomponents/blob/gh-pages/proposals/Template-Instantiation.md https://github.com/WICG/webcomponents/blob/gh-pages/proposal... Perhaps there are more recent versions. I liked the spirit of the proposal, but never studied it.
voxal 4y ago
lit-html is great. I use it for a lot of projects whenever I need some simple tempted HTML. That being said, it seems like the v1 documentation for lit-html [1] has been removed in favor of a single page in the v2 documentation [2]. Is using lit-html standalone not recommended anymore? I really liked using it standalone. [1] https://lit.dev/docs/v1/lit-html/introduction/ https://lit.dev/docs/v1/lit-html/introduction/ [2] https://lit.dev/docs/libraries/standalone-templates/ https://lit.dev/docs/libraries/standalone-templates/

lawwantsin17 4y ago

chrismorgan 4y ago

> 'content' in document.createElement('template') Any reason you’d write this instead of window.HTMLTemplateElement, which is shorter to type and more efficient to evaluate?

asplake 4y ago

How does <template> differ from <script type="text/x-my-templating-lang">?

bugmen0t 4y ago
template does HTML parsing. The `content` attribute returns a DocumentFragment.

brundolf 4y ago

Sorry, but the <template> tag doesn't actually do "templating in HTML" ...but it should. It's shocking to me that we've had the modern paradigm of client-side-rendering frameworks for over a decade now, without so much as an RFC for any kind of native support. For the sake of render performance, bundle size, removing a need for transpilation, compatibility across frameworks. There are a million reasons this should be happening in the browser at this point. I'm sure it's a complicated standard to come up with (for one: HTML-based vs JS-based rendering), but why does it feel like nobody's even trying?

encryptluks2 4y ago
Because JS is where the privacy holes are at and keep getting added.
tannhaeuser 4y ago
There's no lack of syntactical templating mechanisms when HTML is hosted within a SGML markup processing context (ie how HTML started life), and no need to add templating at the HTML markup vocabulary level either: For server-side rendering, SGML (and also some other template "engines") provide HTML-aware, type-checked, parametric macro expansion. Actually, SGML templating works transparently on the client side and the server side. Within the browser OTOH, there's already JavaScript, making every dynamic feature added to HTML inessential for better or worse, like it has for over 25 years now. That's just how it was decided a long time ago, and adding half-assed features to HTML like the template element (which requires JavaScript, in turn, thus doesn't add any essential capability) all the time is exactly the thing we shouldn't be doing when the damn "web stack" is already bloated as fuck.

lenkite 4y ago

I wish HTML and not just JS had supported for consuming templates. That is I wish we could do variants of: 1. Define Template using <template id="card-template">...</template> 2. Consume Template using <use-template id="card1" refid="card-template">..</use-template> With substitution variables/text, this feature could be amazing.

blowski 4y ago
> With substitution variables/text, this feature could be amazing. At which point, are you just re-creating JavaScript?
- dspillett 4y ago
  Not quite, I think he is taking about a more declarative approach compared to that offered by vanilla JS.
- vbezhenar 4y ago
  But works with disabled JS.
akira2501 4y ago
Here's what I got: const $template = function(template) { // make copy of template content const root = template.content.cloneNode(true); // create proxy object for accessing named nodes and root const obj = { get $root() { // after template root is called, remove this getter function delete obj.$root; // return root only once return(root); } }; // find all named template nodes and add to proxy object for (const node of root.querySelectorAll('[data-tmpl-name]')) obj[node.dataset.tmplName] = node; // otherwise create template node content wrapped in proxy which // makes attempts to overwrite properties an error. return(new Proxy(obj, { set: () => { throw (new Error(`Attempt to overwrite a template node!`)); } })); } You can use it with something like: <template id="some_id"> <div> <h3 data-tmpl-name="header"></h3> <h5 data-tmpl-name="title"></h5> </div> <p data-tmpl-name="info"></p> </template> And then just: function of_some_sort() { const t = $template(document.getElementById('some_id')); t.header.innerHTML = 'The Header'; t.title.innerHTML = 'The title'; t.info.innerHTML = 'More stuff.'; document.body.append(t.$root); } This is was the first version I made. It's not hard to get from here to a version that can fill the template with a data object for you. In my most recent version, you could do: function of_another_sort() { document.body.append($template(document.getElementById('some_id'), { header: 'The Header', title: ['first title', 'second title'], info: (elem) => { elem.setAttribute('functions', 'work'); elem.innerHTML = 'and receive the internal element itself.'; } })); } Arrays duplicate the internal element and make copies of it, objects recurse into the element building a 'key.path.name' while looking for data-tmpl-name to replace. Functions get a copy of the element for more than just innerText/innerHTML replacement. A null or false value eliminates the internal element, and a true value passes it through unchanged. If you've ever used the old ruby library Amrita, it's basically that, but for HTML Template elements. You can easily do all this in about 100 lines of JS.

p2detar 4y ago

I appreciate this type of posts very much. Short, neat and to the point. I learned something today. Till now, I've always used: <script id="app-item-template" type="text/x-custom-template"> I'll definitely have <template> in mind from now on. Thank you!

pretzelhands 4y ago

<template> tags are so incredibly useful for keeping your JS clean when you're not able to have something more reactive around for some reason. I've recently used that on an interview project I did (https://github.com/pretzelhands/ubiquitous-sniffle https://github.com/pretzelhands/ubiquitous-sniffle) and it surprisingly takes you quite far with very little effort. The only major annoyance is really manually keeping track of the elements in the DOM and .innerText and .innerHTML-ing everything that needs a dynamic value. But it's manageable if you keep it confined.

wildrhythms 4y ago
This approach always seems so easy at first glance, but I find it gets rather unwieldy as soon as I need to update some deeply nested value- like updating a innerText in cell in a table in a card in a layout of a thousand cards without re-rendering the entire collection. I started using lit-html and it solves this problem (and only costs me 3KB or so to ship).
akrymski 4y ago
I've used this approach in my minimal MVC lib for over a decade, simply using hidden elements instead of templates http://krymski.com/espresso.js/ http://krymski.com/espresso.js/
ohmahjong 4y ago
Is the demo site still supposed to be up? I see > TypeError: path must be absolute or specify root to res.sendFile when I try to visit it.

cookiebyt3s 4y ago

i didn't know templates were inert. cool!

quickthrower2 4y ago

Modulo performance, why not store the html string in JS if you are going to use JS anyway, and with string interpolation it is more templatey anyway.

xigoi 4y ago
With templates, you can do things like template.querySelector("label").
- quickthrower2 4y ago
  True! that would be less elegant with the string, as you would need to make it effectively into a <template> or hidden div to do such a thing.

kellengreen 4y ago

Please can we ship HTML Modules soon? https://chromestatus.com/feature/4854408103854080 https://chromestatus.com/feature/4854408103854080

Traubenfuchs 4y ago

What's the difference between using <template> and just putting your template content in a div with visibility:hidden?