2-way binding syntax, e.g., [(ngModel)], should support elvis operator

[wardbell]

• I'm submitting a ...
  [ ] bug report
  [x] feature request
  [ ] support request
• Do you want to request a feature or report a bug?

Feature

• What is the current behavior?

A2 supports the elvis operator (?.) in property bindings but not "two-way" bindings.

This is ok: [ngModel]="hero?.name".

A2 throws an error if I write [(ngModel)]="hero?.name" because this de-sugars (in part) to (ngModelChange)="hero?.name=$event" and the elvis operator (?.) is not supported in assignments.

Today's workaround is [ngModel]="hero && hero.name". We can do better.

• If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via
  https://plnkr.co or similar (you can use this template as a starting point: http://plnkr.co/edit/tpl:AvJOMERrnz94ekVua0u5).
• What is the expected behavior?

Recommend that template statements support elvis in assignments.

For example, the following <input> element event binding — (input)="hero?.name = $event.target.value" — should assign the value to hero.name if hero != null; if hero == null it should do nothing.

It follows that we will then support [(ngModel)]="hero?.name" which was the original motivation for this request.

• What is the motivation / use case for changing the behavior?

Elvis is useful in binding syntax ... both in property binding template expressions and event binding template statements involving assignment.

The 2-way binding syntax today prevents usage of elvis, even if we only wanted it for the property binding half of that syntax.

• Please tell us about your environment:
• Angular version: 2.0.0-beta.11 everywhere

[Foxandxss]

Oh please, we need this feature. I am a bit annoyed with having to do "foo && foo.bar".

I think it makes sense for Angular 2 template syntax to support some Typescript features. It just need to be documented properly :)

[0x-r4bbit]

I remember @cburgdorf and me running into this as well. We discussed this with @IgorMinar.

Igor, if I remember correctly you wanted to discuss this with the team, did you get to that already?

[nathic]

still no update on this.
i would love to see the elvis operator working with 2 way bindings

[aarmora]

I also vote for this. Right now I'm having to initialize every empty model by hand beforehand.

[ryanlin1986]

This is a essential feature for data-binding

[wardbell]

@mhevery You classified as "workaround is obvious". It may be obvious but it's extremely painful to implement across a large app. Would love to see this get more priority (as would the rest of this gang).

[0x-r4bbit]

I'd love to hear what came out of the discussions @IgorMinar had about this topics. If I remember correctly, he told us back in the days that this feature is not easily implemented as of now (without performance penalties).

Also, what would be the recommended workaround? We currently preset expressions with some value so we don't need the safe navigation operator. But that's clearly a hack.

[wardbell]

Right @PascalPrecht. I don't know what this workaround is ... except to make the developer work hard and write code that's fragile and hard to read.

I'm not buying the bad for performance counter-argument for two reasons

1. No one has identified the problem or its performance tax
2. We should have the ability to pay that tax if it makes sense... as it will 99.9% of the time. At least let us opt in.

Time for some creativity.

[cburgdorf]

If I recall the discussion with @IgorMinar correctly it was more like he wasn't sure if it's the right pattern to promote.

Promoting ?. means promoting routing to components that haven't fully loaded yet. It's often better to defer rendering of the component until it's data is ready.

Personally, I think even if you follow the practice of not rendering components until their data is fully loaded for most of your components you'll still face enough situations where it would be beneficial to allow ?. with the [()] syntax.

[Foxandxss]

@Jammy42 please follow our Code of Conduct if you plan on contributing to this issue.

Thanks.

[kenkopelson]

I really have to take exception to this statement made by cburgdorf above:

"Promoting ?. means promoting routing to components that haven't fully loaded yet. It's often better to defer rendering of the component until it's data is ready."

Routing really has little to do with this. When you load up a page it is quite common to load multiple sets of data from a database like MongoDB. All the components are there, but when the data arrives, some of the fields may or may not be set. This is normal and expected. The binding should handle this easily and transparently.

Also, why do we use Promises and Observables? Is it not for this very reason? WE WANT TO RENDER COMPONENTS NOW and then the data shows up when it shows up. We are talking javascript here, so when data comes across from someplace like MongoDB, there is NO TYPE to the data. Fields could easily be missing, since MongoDB does not require empty fields to be in the database. When fields are missing, I don't expect the binding to break, for heaven's sake. I expect the binding to say "oh, this field is missing, so I'll just set it anyhow and voila - magically created in the target object!

Please don't presuppose how people will use this and then decide for us what's good or bad. A framework should be consistent and predictable, making things easier, not harder. PLEASE FIX THIS NOW, as I consider this a deal-breaker for using Angular 2 at all. Angular 1 worked very well in this regard. Please do not take steps backwards. It's vital we get this fixed.

[nathic]

I agree with @kenkopelson and @Jammy42 and I think this shouldn't be marked as feature request. It's much rather a serious bug. In a more and more reactive and async programming world, you can not justify a misfunctional databinding. As @kenkopelson stated: some fields may or may not be set!
This issue doesn't really bother the angular team and I don't quite understand why. It makes angular 2 really unattractive for to live with the thought of having to preinitialise everything just to make sure not to end up with a completely red console log and a blank site is frustrating and not satisfying.

For me the workaround is just bull****, do you really think it's a good approach?
For me the label "type: feature" isn't correct for THIS IS A BUG!

I hope you guys can understand my complaints and probably give this a little more attention.