What about syntax for template tag composition, instead of only solving dedent?

[ljharb]

It seems like if there was syntax to make template tags composable, then you could easily use dedent, gql, etc without them needing to be changed - and then you’d be solving the general problem instead of one specific one.

[mmkal]

I'm not sure I follow - could you give an example? In general, template tags aren't composable since the codomain isn't the same as the domain, but maybe it'd work for a subset of formatting-only template tags. Would this be something different from an overloaded version of dedent like in the example from the readme (copied below)?

const query = dedent(sql)`
  select *
  from students
  where name = ${name}
`

[ljharb]

Something like compose(dedent, gql, thirdThing), where each one would get the output of the previous one, and the same frozen template object, since any template tag is callable as a function as long as you give it the right arguments.

[mmkal]

Would new syntax be necessary? I'd have thought it'd be possible to write a compose function like that already.

It still depends on the dedent library, so doesn't solve the problems highlighted in the proposal: runtime performance impact, decrease in portability, necessary coupling of dedent with other tags/tools, as well as the inconvenience of needing to do all that to get the desired behaviour in the vast majority of use-cases. Plus the possible incompatibility with other proposals like https://github.com/tc39/proposal-array-is-template-object

I might still be missing something here though. I'd be interested to see an example of another problem this would solve which the proposal doesn't cover. Or, what the syntax would look like and what it would do.

[jridgewell]

I agree with @mmkal here. The issue with relying on runtime behaviors is that we lose the ability to verify that this template expression came from syntax. Lit recently had to work around this for security reasons (though it's incomplete without isTemplateObject). Imagine if sql had to do different behavior if passed a non-template object, because of the potential that a user injected strings into the array.

As for whether this proposal should solve this, I don't think so. We can debate whether dedent belongs in the language, but even if we were to add a compose, we'd still be debating whether dedent belongs in the language, because it's the thing we're trying to solve.