build: enable strictPropertyInitialization

[Splaktar]

• fix related build errors
• complete this._destroyed in ngOnDestroy()
• replace use of deprecated DomPortalHost with DomPortalOutlet

Builds on PR #688

[Splaktar]

@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?

Edit: ✅ solved

[Splaktar]

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.

[Splaktar]

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.

[Splaktar]

@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?

[JoostK]

@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.

[Splaktar]

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

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

[Splaktar]

@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]

PR #926 reverts the workarounds, mentioned above, to get the builds working with the async pipe type narrowing bug.

[Splaktar]

@jelbourn this is the PR I mentioned in the meeting and you said that you would take a quick look at. This would get us closer to being aligned with the Angular CLI's strict mode.

[andrewseguin]

LGTM