Allow Type Checking to be Extended (into Tagged Templates, for example)

Search Terms

Tagged Templates, template literals, JSX, htm, lit, lit-html, hyperhtml, nanohtml, choo

Suggestion

Many developers are exploring Tagged Templates as an alternative to JSX/TSX, as the result offers some important advantages. In particular, Tagged Templates parse faster than compiled JSX in all modern JS engines [1], and expose potential optimizations for consuming rendering libraries to be able to bypass comparison logic for identified static portions of a UI representation.

Regardless of the merit of these advantages, one of the key drawbacks cited by developers when adopting Tagged Templates in place of TSX is the lack of typing within static templates and associated expression parts. This affects all libraries using Tagged Templates.

[1]: analysis and benchmark data forthcoming, email me for access if necessary.

Using htm as an example:

interface Props {
    sticky: boolean;
}
function Header({ sticky }: Props) {
  return html`<header class=${'header' + (sticky ? ' sticky' : '')} />`;
}
render(html`<${Header} sticky=${'yes'} />`);
// Incorrect type, but no error ^^^^^

(view example in playground)

Since the template's static parts are an unknown format, this is logical. However, consider the compiled output of the above:

interface Props {
    sticky: boolean;
}
function Header({ sticky }: Props) {
  return h('header', {class: 'header' + (sticky ? ' sticky' : '')});
}
render(h(Header, { sticky: 'yes' }));
//                 ^^^^^^
//                 Type 'string' is not assignable to type 'boolean'.

(view example in playground)

I would like to suggest that we need a solution for type-checking Tagged Templates. The shortest-path solution would be to special-case checking for Tagged Templates with a tag function that has a local identifier with the name html, though clearly that's not optimal as implementation of html can vary.

Use Cases

The use-case for this is to allow developers to express view hierarchies in standard JavaScript syntax rather than JSX/TSX, while preserving the typing support currently offered by TSX being integrated into TypeScript's parser.

If a design were to be proposed to extend type checking to arbitrary opaque Tagged Templates (perhaps through plugins), this would allow a whole host of untyped code to be checked by the TypeScript Compiler. I'm fairly certain the various CSS-in-JS solutions would be also interested in this level of static analysis in order to errors currently handled at runtime into compilation.

Examples

interface Props {
    sticky: boolean;
}
function Header({ sticky }: Props) {
  return html`<header class=${'header' + (sticky ? ' sticky' : '')} />`;
}
render(html`<${Header} sticky=${'yes'} />`);
//                            ^^^^^^^^
//                            Type 'string' is not assignable to type 'boolean'.

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• This feature would agree with the rest of TypeScript's Design Goals. (specifically goals 1, 2 & 6)

/cc @IgorMinar @JustinFagnani @RobWormald @Surma

Start by reading the TypeScript parser and type-checker areas that handle tagged templates and TSX, then compare how the example is represented and checked. The issue proposes extending checking to opaque tagged-template formats, potentially through plugins; done would require an agreed design and type errors for invalid embedded expressions without changing JavaScript output.