Template syntax should support tear-offs for event bindings

[alorenzen]

Right now, we have to supply a method call for template bindings, using the magical $event variable.
<material-button (trigger)="onClick($event)"></material-button>

In order to be more "dart-y", and also to remove the need to remember the magic $event variable, we could instead support a tear-off
<material-button (trigger)="onClick"></material-button>

[alorenzen]

Open question: would we handle onFoo() (no event object) as well as onFoo($event) (event object)?
I.e. would we try to infer the behavior based on the presence / absence of a variable (either in the @Output like (trigger), or in the handler, like onClick), or just support one use case (such as assume there is a single variable).

[matanlurey]

I'm a fan of inferring based on a variable/lack-of. WDUT @hterkelsen?

[alorenzen]

If that's too hard to land off the bat, we could start with one and then add support for inference.

Also, should we block this on the angular_ast integration?

[matanlurey]

Probably. /cc @MichaelRFairhurst @mk13

[MichaelRFairhurst]

What about something like this?

class Counter {
  int _count = 0;
  int get tick => ++count;
}

and in the tpl

<div (click)="tick">

And what about

<div (click)="counter.tick">

in short, this requires more specification. And I'm seeing a lot of surprising edge cases that will exist in any spec.

Its kind of like if dart suddenly added support for

  int myMethod() => foo;

Yes, practically you can look at that and figure out how this could be a tearoff....but the theory gets mucky and so its probably better to change the syntax

  int myMethod() = foo;

what about

  <div (click)=".foo">

? Though then we're getting back into some of the problems that pipe expressions had, where we're deviating from dart expression syntax which causes its own problems.

I like the idea of this. I'm hoping there's a more precise way to specify it.

[jonahwilliams]

As long as we're throwing ideas out there...

Off the top of my head, there are only two uses for the current template syntax for calling methods.

1. Passing the magical $event argument.
2. Capturing local variables from a directive (NgFor, NgFor, and NgFor).

Everything else, like passing literals can be done from the controller.

What if there was a annotation like @Handle() which allowed you to somehow declare what methods from the controller you wanted to use in the template, such that the angular compiler could infer what to do with just an identifier.

<div *ngFor="let foo of foos">
   <button (click)="handleFoo">Click Me</button>
</div>

@Handle(/*...some additional information maybe needed here */)
void handleFoo(Event event, Foo foo) {
  /// Do some stuff.
}

I'm not sure what information would be required. maybe the types would get you far enough, or maybe you would need the names of the locals.

(As a side note, my ulterior motive is I want a template syntax where dart expressions aren't required.)

[zoechi]

I like the original idea, but if it requires additional Angular syntax, I think it's not worth it.

[TedSander]

@jonahwilliams there is another case. Passing a varref from a template directive:
<input #input></input><button (click)="onClick(input.value)">Submit</button>
It is nice when you don't really need the element in the controller and so don't want to add the extra overhead of a @ViewChild

[matanlurey]

This is now in #1437!

[alorenzen]

I haven't landed #1437 yet, so shouldn't we keep this open until then? The PR has a comment that will auto close this when landed.

[matanlurey]

#1437 is now synced in d72bcef? @alorenzen

[alorenzen]

Oopps, sorry. I had a CL pending from before vacay, but forgot that it's a fix for this, not the PR itself. Yes, this can be closed.