Control-Flow migration does not support NgFor's ngForTemplate input #53068
Description
Which @angular/* package(s) are the source of the bug?
core
Is this a regression?
No
Description
After running ng generate @angular/core:control-flow one of my components ended up being broken. The reason for this is that the migration is not accounting for NgFor's ngForTemplate input.
before the migration:
<ng-container *ngFor="let item of iterable; template: itemTemplate"></ng-container>
<ng-template #itemTemplate let-item>...</ng-template>
after the automated migration:
@for (item of iterable; track item) {}
<ng-template #itemTemplate let-item>...</ng-template>
As there doesn't seem to be an equivalent available with the new @for-block for this use case,
one would have to use the following workaround to get it running:
@for (item of iterable; track item) {
<ng-container *ngTemplateOutlet="itemTemplate; context: {$implicit: item}"></ng-container>
}
<ng-template #itemTemplate let-item>...</ng-template>
Although this is easy to do manually, I think the automated migration should either properly handle this case or at least notify the user to take manual action! Otherwise, this issue might be hard to detect in bigger applications.
Please provide a link to a minimal reproduction of the bug
No response
Please provide the exception or error you saw
None.. Migration succeeded but my component was broken. It was not rendering the specific list anymore since its template contained an empty built-in @for-block.
Please provide the environment you discovered this bug in (run ng version)
Angular CLI: 17.0.2
Node: 18.18.2
Package Manager: npm 9.8.1
OS: darwin arm64
Angular: 17.0.3
... animations, common, compiler, compiler-cli, core, forms
... localize, platform-browser, platform-browser-dynamic, router
... service-worker
Package Version
---------------------------------------------------------
@angular-devkit/architect 0.1700.2
@angular-devkit/build-angular 17.0.2
@angular-devkit/core 17.0.2
@angular-devkit/schematics 17.0.2
@angular/cdk 17.0.1
@angular/cli 17.0.2
@angular/fire 17.0.0-next.0
@angular/material 17.0.1
@schematics/angular 17.0.2
ng-packagr 17.0.2
rxjs 7.8.1
typescript 5.2.2
zone.js 0.14.2
Anything else?
While I know this is some rare use-case, I was wondering whether the above replacement is acceptable in terms of performance!? It will basically stamp out multiple template outlets which in turn render the specific template rather than rendering that template directly. If this indeed has performance drawbacks, should there maybe be an alternative solution for this use case with the new @for-block syntax?