Re: [w3c/webcomponents] Discussion: Templates that Don't Destroy Element References (#777)

What I'm proposing is more fundamental (and more efficient) than Template Instantiation, but not mutually exclusive to Template Instantiation. Here's how the two would complement each other. First I'll discuss what I'm proposing and later I'll tie that into Template Instantiation proposal.

Template Literals already know the context from which to determine the values of the ${interpolations/expressions} they contain. They also already inherently know which portions of the string are "parts".

Template Literals, without the help of any type of HTML template element, already contain everything that needs to be known to generate DOM. Therefore, I think it would be ideal for Browsers to add 2 prototype method to all strings. One called **toDOM()** and the other called **toTemplate()**. Here's how this would work.

### **toDOM()**

If you want to create live Dom (that's ready for the appendChild method) you use the toDOM() method:
```
let div = document.createElement("div");
div.textContent = "Click Here to See an Alert";
div.addEventListener('click', (event)=>{alert(`You've click a div that contained this text: ${this.div.textContent}.`)});

let str = `String containing ${expression}`;
document.body.appendChild(str.toDOM);  //Page says: Click Here to See an Alert
setTimeout(()=>
{
 div.textContent = "Nevermind";}, 5000); // Page says "Nevermind" after 5 seconds.
}

```
Above is what I'd primarily use, because if I already have direct object reference to the dynamic element-objects that changes (which what I'm proposing would give you), there is no need for template updating. Therefore, there's no need for an intermediary template element and the added parts-replacement processing it brings with it.

### **toTemplate()**
Here's where your proposal comes into the picture.
The toTemplate() does the same thing that the toDOM() method does, except it it returns a html `<template>` element where all interpolations have been replaced with unnamed-TemplateParts. Later when you call the htmlTemplate.createInstance(['You','Pass','an','array','of','replacements']);

If you want each tempate part to have a name, you can pass names in during the toTemplate() method:
templateLiteral.toTemplate('array','of','named','parts');

Then, later when you call htmlTemplate.createInstance(), you pass in an object literal instead of an array if you originally gave the parts a name during toTemplate().

And also, the examples you gave, where the template element was created in HTML, this will be fine too.

These two methods are fundamentally different ways of updating the dynamic aspects of a web component. The first method only gets called when something changes. The Template Instantiation method has to evaluation each part to determine if something changed. If you handle your updates at this more fundamental level, you web-component is event-driven. You don't have to compare anything to see what changed, the event inherently tells you what changed and you go update that alone.



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/777#issuecomment-445189134