Support passing generics to tagged template string

[patrick91]

I was trying to write some type definition for the styled-components project, but it looks like there is no way to specify a generic when using a tagged template. So... here is a subset of the typedef I'm writing:

declare module 'styled-components' {
    import * as React from "react";

    export function input<P>(values: TemplateStringsArray): React.StatelessComponent<P>;
}

This is how I'd like to use it:

import * as React from 'react';

/// <reference path="../../../typings/styled-components/styled-components.d.ts" />

import styled from 'styled-components';

interface Props {
  placeholder: string;
}

const Input = styled.input<Props>`
  font-size: 1.5em;
  text-align: center;
  color: palevioletred;
`;

I know that it can also be possible to override Input.propTypes manually[1], but I was wondering if this could be an useful addition to Typescript.

TypeScript Version: 2.0.3

[1] Or even write a custom component and just use the styled(Component)style`` syntax

[blakeembrey]

From twitter, turns out this issue already exists: https://twitter.com/drosenwasser/status/797222514715824128. I think this is the correct syntax to use and the same thing I tried when I wanted to use generics with a template tag.

[DanielRosenwasser]

If all you're doing is specifying the type argument for an output type (and the type system can't make any checks on that), that's not really a case for generics - that seems like a better case for a type assertion.

The one thing that I do see as a benefit in the original use case is that you don't have to write React.StatelessComponent every time, which is definitely a pain.

[blakeembrey]

@DanielRosenwasser The use-case doesn't bother me, it's only the feature I really care about 😄 I could very well want to restrict the types of parameters the tag can use to just values/keys of the type, for instance (E.g. current nightly features).

Edit: I'd love to have the generic discussion somewhere, where's the best place to do that? Personally I like specify the return type in generics (where the return is valuable) for a couple of reasons:

1. Without it, coercion is tricky (assigning a semi-compatible type that looks similar) and messy (e.g. have to wrap it specifically in parens when using chaining) and a new developer can get it wrong.
2. Adding it in the future would currently require breaking backward compatibility, so introducing it once features like the keyed types or members of lands on stable would break current users.

[rossipedia]

I just ran into this trying to put together a small template library:

It would be really nice if the first example worked (and would be the least astonishing, IMHO)

[Igorbek]

Since it's awaiting more feedback, here's my feedback. I am pretty sure the use case is not only for return type. Consider signature:

interface SimplifiedStyledFunction<P> {
  <TNewProps>(strings: TemplateStringsArray, ...interpolations: ((props: P & TNewProps) => string)[]): StyledComponent<P & TNewProps>;
}

• there's no way to infer TNewProps from the usage in interpolations
• no way to cast return type (it wouldn't match)
• workaround: specify type of props in each interpolation in form of Props & TNewProps, which will be incredibly annoying

[DanielRosenwasser]

To give some technical background on this, there are four operations that we consider flavors of function invocations in the compiler:

• call expression: foo()
• new expressions: new Foo()
• tagged templates: foo `stuff`
• decorators: @FooComponent class C { }

The latter two do not allow explicit type arguments. My feeling is that both should be allowed, but given the demand, work to support tagged templates is reasonable and should have some more priority.

[DanielRosenwasser]

If anyone does decide to send a PR, give us all a heads up here first.

[DanielRosenwasser]

So I remembered the real reason we didn't do this originally.

Right now, tagged templates are considered MemberExpressions. Those bind just a bit more tightly than a CallExpression or NewExpression.

Since tagged templates will always bind more tightly, we'll always try to parse tagged template type arguments, even when we're going to parse out a call expression.

If you take the following:

foo<Bar>()

A naive approach would do the following:

1. Let me try to parse out a MemberExpression
   1. I have a foo. Keep parsing out the rest of a MemberExpression.
   2. I see <! Let me look try parsing out type arguments for a tagged template.
   3. I have type arguments! Let me see if I have a template string.
   4. I have an open paren - let me discard all the work I've done to get those type parameters. 😢
2. I was able to get foo as a MemberExpression. Let me see if I can parse out a call.
   1. I see a <. I should parse out type arguments as part of a CallExpression.
   2. I got type arguments! Now I see an open paren! I'll try parsing out the call arguments.

This approach means that for every call expression with generics, we have to perform steps 1.ii, through 1.iv even though we're going to throw away the result.

While it's rare that you have to supply type arguments, it's less-than-ideal to do a re-parse every time.