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

EisenbergEffect left a comment (WICG/webcomponents#1069)

What @NullVoxPopuli shows above in his interpreted example, is essentially the way that FAST's templating engine worked (built on signals and tagged template literals). It was the best pattern I could find to enable the kind of signals support we needed. However, it had the unfortunate ergonomic side-effect of needing to use lambdas for all reactive expressions. I can't recall which of these threads I mentioned it on, but this is why I wondered whether we need a different syntax in template literals to denote "capture expression" vs. "capture value". If you have direct access to the signal, you can capture value, but in more complex MVVM scenarios, you do not have direct access to the signal, so you need to capture the expression, which you will execute later in a particular context.

Quick example...

```js
class Person {
  @signal firstName = "Rob";
  @signal lastName = "Eisenberg";

  get fullName() { return `${this.firstName} ${this.lastName}`; }
}

//This won't be able to update the way we want.
const model = new Person();
const template = html`Hello, may name is ${model.fullName}`;

// We need to do something like this, but ugh, ugly ergnomoics.
const template = html`Hello, may name is ${model => model.fullName}`;
```

A JSX transform could improve ergonomics and produce this output, but we'd still need some standard target for the tagged template handler to understand a particular parameter as an expression or lazy evaluation.

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

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