This sounds like a great idea for a template diagnostic! Looking forward to it being ready for review/discussion!

@JeanMeche Since this visits every node in the AST, what about expressions like fn(signalA)? It seems like this diagnostic will still fire. But you might sometimes want to actually pass the signal, as opposed to just reading it?

@dylhunn This is already covered, I'll add a test though !

@crisbeto Highlighted some potential concerns before we merge this. Let's target v16.1.

1. It only checks interpolations, not things like [attr.foo]="signal"
2. It doesn’t check host bindings because extended diagnostics don’t have access to them.
3. Would be better to fin a cleaner way to detect a Signal

The regular binding (ex.: <div [myDirectiveInput]="sig"> is tricker as there are legitimate cases where someone might want to pass a reference to a signal (instead of unwrapping its value).

Just to capture this here: And in those cases, the normal type-checking is already sufficient and will complain if e.g. myDirectiveInput does not take a Signal<T>

@pkozlowski-opensource @JeanMeche Just to confirm, the regular non-interpolated binding case <div [myDirectiveInput]="sig"> Pawel describes does not produce a diagnostic, right?

Edit: saw the slack thread, thanks!

the regular non-interpolated binding case <div [myDirectiveInput]="sig"> Pawel describes does not produce a diagnostic, right?

No, it won't produce a diagnostic. The typechecker should do that.

Caretaker: windows is a flake. PR has sufficient approvals (me and Pawel).

This PR was merged into the repository by commit 8eef694.

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