@crisbeto can you please take a look at this Circle CI error? It seems to be related to the Portal Changes in 9.0.0.

Should I file a bug here or is there some misconfiguration in this PR?

I just found that this branch/PR were passing on CircleCI, but failing to build locally. It appears that ng test doesn't expose Ivy's Template Type Checking errors. However, Template Type Checking does break the build. So I've added a build task to CI to catch this issue.

Note that these Template Type Checking errors are new in Angular 9.0.0-rc.6. In the previous build based on 9.0.0-rc.4, they did not appear.

Additionally, it also runs build:content to ensure that the docs-content can be synced as we've had a couple issues this year where that was broken and we weren't aware of it immediately.

OK, the issues that I'm hitting were introduced in Angular 9.0.0-rc.5 as part of PR angular/angular#33997 (specifically angular/angular@66e8ed4) which was fixing angular/angular#31556. Prior to that change, template variables created as part of an *ngIf="something | async; let thing" were always of type any (i.e. thing: any). However, they are now typed and will throw errors due to strict Template Type Checking.

I'm investigating how to solve them, but I don't feel like my current solution is solid, so I'm continuing to investigate.

@crisbeto or @JoostK do you have any guidance here?

Template

<ng-container *ngIf="componentViewer.componentDocItem | async; let docItem">
  <span class="cdk-visually-hidden" tabindex="-1" #initialFocusTarget>
    Examples for {{docItem.id}}
  </span>
  <example-viewer *ngFor="let example of docItem.examples"
                  [example]="example"></example-viewer>
</ng-container>

There are errors for

src/app/pages/component-viewer/component-examples.html:3:20 - error TS2531: Object is possibly 'null'.

3     Examples for {{docItem.id}}
                     ~~~~~~~~~~

  src/app/pages/component-viewer/component-viewer.ts:132:16
    132   templateUrl: './component-examples.html',
                       ~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Error occurs in the template of component ComponentExamples.
src/app/pages/component-viewer/component-examples.html:5:34 - error TS2531: Object is possibly 'null'.

5   <example-viewer *ngFor="let example of docItem.examples" [example]="example"></example-viewer>
                                   ~~~~~~~~~~~~~~~~

  src/app/pages/component-viewer/component-viewer.ts:132:16
    132   templateUrl: './component-examples.html',
                       ~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Error occurs in the template of component ComponentExamples.

Solutions?

It's complaining about docItem.id and docItem.examples where docItem might be null in these cases. But it seems to be ignoring the fact that this template won't be rendered if docItem is null.

The tests in PR angular/angular#33997 don't cover the use case where the Async Pipe is used.

How do you recommend developers solve this very common use case?

@Splaktar ah, this is interesting. Using as the way we tested it reflects the NgIfContext.ngIf property, for which the template type checker has applied the appropriate context guard expression due to the presence of NgIf.ngContextGuard_ngIf.

When used with a let assignment to $implicit, however, the context guard for ngIf does not narrow reads of $implicit.

I'll have a look to see if there's something that can be done here.

@JoostK I tried the following and got the same errors:

<ng-container *ngIf="componentViewer.componentDocItem | async as docItem">

@JoostK here is the workaround that I had to apply to get our repo building again after the breaking change in Angular 9.0.0-rc.5.

Do you have an open GitHub issue to track this or should I open one? I wasn't able to find one after looking through the Angular issues.

@Splaktar there isn't any issue at the moment, so please open one.

In the meantime I am working on a PR to resolve this issue, but I'm not fond of the approach quite yet.

The main reason as to why template variables are not properly narrowed is because the "template guard" for the ngIf input is only regarding the input binding expression itself. When using template variables, however, the value is taken from NgIfContext which is not narrowed as it's currently not possible to insert template guards for context variables. The PR I'm working on changes the "template context guard" of NgIf to let the context type be inferred to NgIfContext<NonNullable<T>> so that its properties $implicit and ngIf would no longer include the nullable types.

Opened angular/angular#34572 to track the issue with ngIf + async pipe type narrowing.