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

[developit]

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

[weswigham]

So far as we know, html`<${Header} sticky=${'yes'} />` compiles to render(html(__makeTemplateObject(["<", " sticky=", " />"], ["<", " sticky=", " />"]), Header, 'yes'));, not render(h(Header, { sticky: 'yes' }));, and we do check it like the tagged template call we believe it to be equivalent to. You seem to be using some babel plugin to handle some special template compilation - that's all well and good, but there's very little chance we'll be able to typecheck it.

[IgorMinar]

There is at least one key missing piece to in this proposal: we also need to make sure that the ts language service is compatible or can leverage this extension point. The language service should be able to work on these custom syntaxes just like it works on files with tsx templates today.

[IgorMinar]

@weswigham how does the compiler know that sticky is supposed to be a property on the Header component? I don't understand how that info is conveyed to the type-checker. Can you please clarify?

[IgorMinar]

We could generalize this topic/request to: enable composing design-time code input on top of TypeScript, with the goal of enabling composition of different solutions on top of TypeScript and by doing that increasing the innovation in this space.

The tsx support in typescript would then become just one of many pre-processors for typescript, which would possibly also clean up some of the tsx "leakage" all over the typescript code base and AST.
…

[AnyhowStep]

This is pretty much why I go out of my way to avoid UI libraries that require me to use strings to render stuff.

Because code in strings can't be type checked.

Some libraries try to mitigate it by introducing an additional compile step but it's just clunky, and hack-y.

---

If support for this is implemented as some kind of compiler plugin, you could write a plugin to parse languages other than TS/TSX/HTML/CSS in strings... Like MySQL.

Just being random, here.

[justinfagnani]

@AnyhowStep I don't think that's a helpful comment in a thread of people trying to discuss how to implement such a thing. If you're not interested you don't have to participate.

[justinfagnani]

cc @octref and @rictic

In our experience looking into this, one of the first missing pieces is a type construction API. We can parse a template, like:

html`<my-element .prop=${foo.bar}`></my-element>

And know how we should build the type of the LHS of the implied assignment, ie:

typeof HTMLElementTagNameMap['my-element'].prop

but we don't have an actual API to build the type. If we did, there is an API for checking assignability.

Once we have those pieces we can do this in a compiler plugin. From there we would really love to have a way to specify plugins in tsconfig so we don't have to write a wrapper around tsc.

[AnyhowStep]

I brought up considering the possibility of parsing other languages like MySQL, if this was a plugin support type thing.

It would be a shame if this was implemented and it was constrained to just TS/HTML/CSS-esque languages only.

I would personally be interested in this mostly for query languages (MySQL, GraphQL). Not rendering, in particular. Maybe GLSL.

If that's not showing interest, then I guess I'm not interested.

[developit]

Apologies for not making it clear in my initial proposal, that is a result of my lack of knowledge pertaining to TypeScript internals. I would vastly prefer the option of allowing arbitrary extensions to the type system, as @justinfagnani outlined. The source code I included was simply a pertinent example of one case where such functionality would be extremely useful.

Regarding @weswigham's comment - that is TypeScript's output when transpiling to ES5, which isn't really important here. HTM is not a babel plugin, it's a runtime library that implements the html function I alluded to. The template string is opaque until runtime, when its XML-like contents are parsed and result in a series of invocations of a hyperscript-like function.

I was not proposing that TypeScript infer types from the ES5 output, but rather that a point of extension be added so developers can build ways for type information to flow through these otherwise opaque constructs. I think there is applicability here across many uses of Tagged Templates - we have a language construct for associating a template with a processor function, but no means of passing type information through that relationship.

[IgorMinar]

Could we change the subject of this issue to reflect that what we are asking for is a generic extension point? Thanks!

[octref]

If you want the errors in IDE, it's possible to do it now with TS Language Service Plugin. Although it's cumbersome.

If we did, there is an API for checking assignability.

The runtime Language Server Type Checker actually lacks API for doing type-checking programmatically: #9879. So your best bet is to start a new Language Service and construct a SourceFile manually. This doubles the CPU/mem consumption of TS Language Server.

enable composing design-time code input on top of TypeScript

@weswigham, per Anders's reason for closing #9943, is this a valid idea? Being able to construct virtual SourceFiles in development time and run language features (completion, diagnostics, jump-to-definition, etc) on them would make it much easier to build upon the TS Language Server.