Type checking for structural directive without parameter

Which @angular/* package(s) are the source of the bug?

Don’t known / other

Is this a regression?

No

Description

Hello, not sure if this is an actual issue or just me misunderstanding behaviour of structural directives in Angular.

Let’s say we have a simple structural directive (see repro). From my point of view, two declarations below should be equal, however, the first one throws type error, while the second one compiles without any errors. Why is that?

<!-- Why this one throws type error -->
<h1 *appUnless>Test</h1>

<!-- And this one not? -->
<ng-template [appUnless]>
  <h1>Test</h1>
</ng-template>

From my point of view, typechecker expects the structural directive without any parameters to be equal to following:

<ng-template [appUnless]="''">
  <h1>Test</h1>
</ng-template>

when in reality, it is equal to code above (I tried to change the type of the directive parameter to boolean | string, and checked if the input setter will be called - it wasn’t).

Please provide a link to a minimal reproduction of the bug

https://stackblitz.com/edit/angular-ivy-vbzbnj?file=src%2Fapp%2Funless.directive.ts,src%2Fapp%2Fapp.component.html,tsconfig.json,src%2Fapp%2Fapp.module.ts,src%2Fapp%2Fapp.component.ts

Please provide the exception or error you saw

No response

Please provide the environment you discovered this bug in (run ng version)

No response

Anything else?

No response

[alxhub]

Ahh, I see. <div test> - setter called. <ng-template test> - setter called. <div *test> - setter not called.

Very curious. This warrants further investigation - I would expect the last two to behave more or less identically.

[alxhub]

You’re close - the expanded <h1 *appUnless> is actually wrapped in <ng-template appUnless>. That is, an attribute, not a property ([appUnless]).

I suspect what’s happening here is that in the absence of any other bindings, the template type-checker treats this as an “empty” attribute binding (<ng-template appUnless="">, but the template compiler doesn’t actually generate code to write this value at runtime.

This is interesting! It’s not immediately obvious to me whether it’s the template type-checker or the template compiler at fault here. I suspect the better argument is that the runtime shouldn’t be setting “default” attribute values, so the template type-checker is in the wrong.

Here is a simpler reproduction without the structural directive.