Control-Flow migration does not support NgFor's ngForTemplate input

[pweyrich]

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?

[jessicajaniuk]

Thanks for reporting this! You're correct in that it's a rare use case. I have a PR up that should address this use case and ensure it migrates properly. We'll discuss the performance implications with the team.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}