Define generic of ng-template

[waterplea]

🚀 feature request

Relevant Package

This feature request is for @angular/language-service

Description

I quite often use ng-templates in my application to later include them in the *ngTemplateOutlet and pass them the context. However when I define the template itself, it doesn't know the interface the context will have, so say this:

<ng-template #willUseLater
             let-item
             let-index="index">
    {{index}} — {{item}}
</ng-template>

Gives me an error ng: The template context does not defined a member called 'index'. (note also a typo here)

Under ng-template there's TemplateRef<T>, but there is no way to define that T.

Describe the solution you'd like

Provide a way to define the generic in place without extra overhead

Describe alternatives you've considered

At least disable this error as it has no purpose if you have any complex template usage

[pkozlowski-opensource]

Oh, this is an interesting one ! @waterplea did you consider any options for "Provide a way to define the generic in place without extra overhead"?

Somehow we would have to define context type in a template but my first knee-jerk reaction is that it would be... I don't know, like writing TS code in a template. Anyway, interested in other people thoughts...

[waterplea]

Well, since it digs in the source code files statically anyway it could try to find the uses of this template. If you have it with context, you most certainly have a template variable for it. So there's a chance to find it in components' ViewChild/ren or if it is passed as an input to some other component inside template directly — you could try to find a corresponding input's type. However that is probably not that easy and there's also a case (how I actually use it) of additional directive:

<ng-template #ref="myDirective" myDirective let-item let-index="index">
  ...
</ng-template>

and

class MyDirective<T> {
  constructor(
    @Inject(TemplateRef) templateRef: TemplateRef<{$implicit: T, index: number}>
  )
}

Which makes it even more difficult.

[Airblader]

I think having some [ngTemplateContextType] would be useful here, and in line with ngTemplateOutlet* on ng-container.

Yes it would be some level of typing in the template, but usually you'd probably just bind a specific type rather than define full interfaces there. Also @waterplea outlined issues with inferring it automatically, and at the end of the day having type information is better than not having type information.

Trying to infer types when not defined explicitly is a separate effort that could be done on top of providing the expected type information. The language service can also analyze that ngTemplateOutletContext is set according to this type in the templates.

[Airblader]

With the ngTemplateContextGuard and ngAcceptInputType_* functions as recent additions, Angular has moved towards pragmatic decisions to improve type safety support in Angular. In the spirit of that I would like to bring attention to this issue again and propose a similarly pragmatic approach.

Lack of type safety for ng-template is one of the big places in Angular at the moment where type safety really suffers.

Contrary to my half-baked proposal above I would instead suggest something like this, which closely follows the implementation of ngTemplateContextGuard which can be done from directive side:

interface Article {
    price: number;
}

interface Context<T> {
    $implicit: T;
}

@Component({
    template: `
        <ng-template [ngTemplateContextGuard]="guardFn" let-article>
            {{ article.price }} <!-- OK -->
            {{ article.prize }} <!-- Error -->
        </ng-template>
    `,
})
export class FooComponent {

    public readonly guardFn = (ctx: any): ctx is Context<Article> => true;

}

This also avoids the issue of introducing types directly into the template and would still leave automatic discovery of the proper type to be an option in the future.

Ideally using *ngTemplateOutlet should then throw an error if the context type doesn't match (otherwise the chain of type safety is broken). I'm not sure if this is problematic from an implementation perspective, and if so then this would be a useful feature regardless.

CC @alxhub @IgorMinar