feat(core): Support two-way binding for value on Input elements

[JeanMeche]

The commit adds runtime support for two-way bindings on input. No Forms imports required this is supported at runtime level. This will only handle strings as value returns a string.

The compiler didn't throw any warnings on value 2-way bindings before, so no changes on this side.

@Component({
  selector: 'app-root',
  standalone: true,
  template: ` <input [(value)]="name" />`,
})
class App {
  name = signal('Angular');
  effect = effect(() =>this.name());
}

[devversion]

I believe the semantics may be confusing. e.g. Why input and not the change event?

[JeanMeche]

The input event fires on every keystroke, change only fires on blur/enter.

[devversion]

I know, but why do we choose input and not change? In addition, how can a user tell what event they will get.

[JeanMeche]

We would probably mention that in the docs.
About input vs change, we're binding the value property on an HTMLInputElement and the value of this property changes on every input event. I would expect the signal to reflect that.

[devversion]

Yeah, people might have different expectations- so we should make sure we considering the alternatives as well.

I definitely also do see input valuable.

[dylhunn]

Input events also feel like the right choice to me, since this is how ngModel behaves, so it's "consistent."

[crisbeto]

Should we have some tests that cover the more complex input types, like date or number? Also we'd probably need some tests for the template type checking side as well.

[JeanMeche]

The value property will always return a string, we could supporting binding on valueAsNumber & valueAsDate to support those types.

[JeanMeche]

should we optimize this structure by making it a tuple ?

[dylhunn]

IMO not necessary.