[templates] How featureful should the default processor be?

[domenic]

From what I can tell the proposal includes the following features:

• Stripping leading/trailing whitespace from expressions, so you can do {{ x }} instead of {{x}}.
• Path searching with dots, so you can do {{x.y}}. (But not brackets, so you cannot do {{x["y"]}}.)
• Fallback with ||. Doesn't appear to be in the formal spec. Does this use boolean semantics, so false or 0 trigger fallback? Or is it just undefined and null? Just undefined?

There's a lot of potential for scope creep here. I think the most minimal version omits all three of these so it's purely JavaScript property lookup. I'm not sure if that'd be too restrictive, or OK.

Note that Mustache doesn't allow any of these, I am pretty sure, and requires you to manipulate your data into an appropriate format beforehand. (Maybe it supports whitespace stripping?)

[rniwa]

Stripping the leading & trailing HTML whitespace is a feature of template parts themselves. Right now, I don't have a formal spec for the default processor. We're pretty much open to options. The only thing we ask is that we don't spend another six months debating & spec'ing the default processor's capability & semantics by making them too complicated.

[caridy]

I think the most minimal version omits all three of these so it's purely JavaScript property lookup.

I will definitely favor that. Looking at this from the localization point of view, you could have the default message in english, or the key for the label, or both of them combined, or even a complex default ICU or Fluent message inside those {{...}} and the processor will give you the ability to produce the right value. This is a use-case from the far end of the spectrum for simple apps, but definitely important for complex apps.

[tclzcja]

@domenic one concern about the not having {{ x["y"] }} part: what if the property name contains special characters? One case I can think about is i18n, a multi-language property/object may look like:

name["en-AU"]
lastname["zh-CN"]

and we can't use dot in that scenario - I mean, assuming name.en-AU is illegal either in the spec.

[domenic]

You can create an object with the appropriate properties, like you would in Handlebars or Mustache.

[stramel]

@domenic As I mentioned in #688 I often find myself needing index + 1 which doesn't appear it would be supported by the proposed feature subset.

[domenic]

Yes, you would need to create an object such as const obj = { number: originalObj.index + 1 } and then use {{number}}. Just like in Handlebars.

[justinfagnani]

I think that keeping expressions in the default processors just simple keys will be the best for the first version. Even simple expressions like a.b or a[b] will end up having to define semantics that might not match JavaScript, or JavaScript best practice idioms of any given time, so we'd end up with a not JavaScript, but JavaScript like, expression language in the platform.

Ultimately I think we want to find a way to somewhat safely allow real JavaScript in the expressions with a built-in processor, and until then I think user-space processors can explore the feature space here pretty well.

FWIW - since this proposal is very much like the internals of lit-html - when lit-html produces an HTML template it doesn't put any expressions inside the delimiter, they're all just {{}} and associated with values from the JS template by order. I think this might end up being a very common approach, where the expression are empty, or have a generated key used to lookup in another structure produced from the actual expressions that the developers write.

[rniwa]

I think a.b is fine because we can define that as regular [[Get]] on a. What's challenging for + 1, a["b"], etc... is the parsing of it needs to match ES2017 or whatever.

[domenic]

The parsing for property references (a.b) is nontrivial and also needs to match the JS spec. Think about Unicode escapes, which characters are allowed as the first one after the dot, etc.

[rniwa]

@domenic : We can just limit to ASCII literals.

[domenic]

That doesn't match the JS spec

[rniwa]

@domenic : Obviously not. But we don't have to support the full JS spec as long as it's a strict subset (and I know not all ASCII characters aren't allowed in property list, etc...). For that matter, we wouldn't match the spec regardless of what we spec. Even if we just supported {{~}}, we would have differences to the real JS behavior due to escaping, etc...

[rniwa]

I'm going to say that we're gonna insist pretty hard on supporting dot syntax because it's going to be very important for our declarative custom elements syntax.

[domenic]

Ok, we can discuss this point of contention further in person. We'd prefer that to not be in the default processor. (Edit: but, are looking forward to working together and especially seeing the integration you allude to, which will surely add to the discussion.)