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

dariomannu left a comment (WICG/webcomponents#1069)

@trusktr 

> With these questions we're potentially asking for more complexity and maybe it's too much to spec.
> We don't need to support promises, signals, or anything else but plain values for an initial spec.

I would challenge the point of a reactive templates proposal if you don't even support reactive primitives.
If all you care about is plain values, untagged template literals rock:
```js
target.innerHTML = `<div class="${strClass}">${ arrayOfStrings.map(whatever).join('<br>') }</div>`;
```

> * People can wrap their templates in effects if they want to use signals.
> * They can call their own functions or methods to rerun templates when promises resolve.

I'm not looking to use signals. That's the whole point of binding reactive primitives like Promises and Observables.
If you do that, you'll no longer have to rerun, rerender components or even worse, wrap them in effects or other unnecessary boilerplate.

You shouldn't have to write any more than the below to render a Promise:
```js
const data = fetch('/api').then(json).then(whatever);

target.innerHTML = html`
  <div>${data}</div>
`;
```


> We don't need to decide how DOM Parts can handle various types of values, and we don't even need DOM Parts.
> 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 "move fast and break things" guys have already done their damage to the world leaving others to clean up the mess.
If you're only looking for a paid retirement, there are other ways to get one without the same dishonourable mentions 🙃, so why don't we just take the time to think? Once it's done, there's no way back...


> ### Most minimal spec
> 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.

Can't see that. If you have some good proposals, maybe on a more open platform like this?


>   // ... 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:

This is a bit far from being like the universal solution to all problems reactive primitives solve.
Understanding how those work may help to appreciate the value they can bring here.


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

And this is why I'm saying add support for Promises and Observables, so the world wouldn't have to do this.

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

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