Re: [WICG/webcomponents] [templates] A declarative JavaScript templating API (Issue #1069)

trusktr left a comment (WICG/webcomponents#1069)

> > You know what I would add to it?
> > Support for Promises and Observables/Observers as template parameters
> 
> There are a fairly large number of data types that could be natively handled by the template system. I think the important questions about this are:
> 
> 1. Where are different values handle? In the template layer or the DOM Parts layer?

Does you all see that with these sorts of questions, we're begging for more complexity?

We don't need to support promises, signals, or anything else but plain values early on. People can wrap their templates in effects if they want to use signals. They can also call their own functions or methods to rerun templates when promises resolve.

We don't need to thinking about how DOM Parts can handle various types of values.

We want to ship something usable to users ASAP before they've all left the web and done something else with their lives and we've all become old farts (myself included!).

The simplest possible solution is to do with this spec something similar as I've described for simplifying the Template Instantiation proposal in my previous comment, and leave the DOM-updating implementation details to browsers, with the most minimal API exposed to users.

The most minimal API for this tagged template proposal is:

- specify desired behavior of attribute, text content, and list interpolations
- return the DOM (or DOM list) result from the html tag function, which is cached by source location.
- the *only* new JS API for web devs is the `html` tagged template literal, with a way to key the cache:
  - f.e. `` html(key)`...` `` so that it can be keyed on custom criteria besides source location, such as per custom element instance, etc.

This would be a very small API surface area that browsers can implement the details of in whichever most optimal way they see fit, very easy to spec without all the other details, and would require no frameworks and the most minimal JS requirements for end users.

Minimal example inside an HTML file:

```html
<script>
  function myTmpl(a, b, key) {
    // undefined key is the same as not using a key
    return html(key)`<p>
      One value: ${a} <br />
      Other value: ${b}
    </p>`
  }

  const p = myTmpl(123, 456)
  
  document.body.append(p)

  // ... later update the DOM ...
  myTmpl('foo', 'bar')

  // need a new instance? Then:
  const sym = Symbol()
  const p2 = myTmpl('a', 'b', sym)
  document.body.append(p2)
  // ... later call tmpl2 when needed
  tmpl2('c', 'd', sym)
</script>
```

Done. That's it! This will be a smaller spec and we can do two things:

- ship something sooner
- have it be useful without requiring significant JS or frameworks.


---

Note, even without a key option, there's still a way to bypass source location caching. Here's the previous example without using the key option, though not as ergonomic for end web API users to write:

```html
<script>
  function makeTmpl() {
    return new Function('a', 'b', `
      return html\`<p>
        One value: ${a} <br />
        Other value: ${b}
      </p>\`
    `)
  }

  const tmpl = makeTmpl()
  const p = tmpl(123, 456)
  
  document.body.append(p)

  // ... later update the DOM ...
  tmpl('foo', 'bar')

  // need a new instance? Then:
  const tmpl2 = makeTmpl()
  const p2 = tmpl2('a', 'b')
  document.body.append(p2)
  // ... later call tmpl2 when needed
  tmpl2('c', 'd')
</script>
```

Lastly, we could make the key option be keyable with the template's own return value:

```js
const tmpl = (val, key) => html(key)`<p>value ${val}</p>`

const p = tmpl(123)

document.body.append(p)

// ...later, update the specific DOM:
tmpl(456, p)
```

TLDR: What's the absolute most minimal smallest possible spec that is most useful for end web API users.

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

Message ID: <WICG/webcomponents/issues/1069/2770268470@github.com>