Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
wardbell opened this issue Mar 21, 2016 · 15 comments
Open

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

wardbell opened this issue Mar 21, 2016 · 15 comments

Comments

@wardbell
Copy link
Contributor

@wardbell wardbell commented Mar 21, 2016

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

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

This comment has been minimized.

Copy link
Member

@Foxandxss Foxandxss commented Mar 21, 2016

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 :)

@PascalPrecht

This comment has been minimized.

Copy link
Contributor

@PascalPrecht PascalPrecht commented Mar 22, 2016

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

This comment has been minimized.

Copy link

@nathic nathic commented May 13, 2016

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

@aarmora

This comment has been minimized.

Copy link

@aarmora aarmora commented May 17, 2016

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

@ryanlin1986

This comment has been minimized.

Copy link

@ryanlin1986 ryanlin1986 commented May 18, 2016

This is a essential feature for data-binding

@wardbell

This comment has been minimized.

Copy link
Contributor Author

@wardbell wardbell commented May 21, 2016

@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).

@PascalPrecht

This comment has been minimized.

Copy link
Contributor

@PascalPrecht PascalPrecht commented May 21, 2016

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

This comment has been minimized.

Copy link
Contributor Author

@wardbell wardbell commented May 22, 2016

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

This comment has been minimized.

Copy link

@cburgdorf cburgdorf commented May 22, 2016

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

This comment has been minimized.

Copy link
Member

@Foxandxss Foxandxss commented Jun 3, 2016

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

Thanks.

@kenkopelson

This comment has been minimized.

Copy link

@kenkopelson kenkopelson commented Jun 6, 2016

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

This comment has been minimized.

Copy link

@nathic nathic commented Jun 14, 2016

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.

@Jammy42

This comment has been minimized.

Copy link

@Jammy42 Jammy42 commented Jun 22, 2016

Would be nice if someone from the Angular2 Team would post a comment here ... or are they already working on a different framework ?

@vicb

This comment has been minimized.

Copy link
Contributor

@vicb vicb commented Jun 22, 2016

@kenkopelson @nathic @Jammy42 please stay constructive and follow our code of conduct.

This is not on our priority list for now as there is a workaround.

Do you know of any langage that supports the safe navigation operator in assignment ? Knowing how other deal with this could help. Thanks.

@angular angular locked and limited conversation to collaborators Jun 22, 2016
@naomiblack

This comment has been minimized.

Copy link
Contributor

@naomiblack naomiblack commented Jun 22, 2016

Folks, the discussion on this issue is veering into insults.

I deleted some comments on this issue that did not add to the technical discussion and I'm locking the conversation for now.

Per angular's code of conduct, bullying and personal attacks on members of the community (calling people out for being young/inexperienced/not "real" team members when you disagree) and demanding action are not tolerated here.

I'd like to assure you that we have an open issue precisely because we understand that it is valued by many developers.

We have not addressed it yet because the solution is non-trivial without introducing breaking changes, and there is a workaround that prevents people from being stuck.

We hear you. It's on our list for future work.

I'm hopeful that we can find a way to add this feature in future, and would welcome contributions that point to other examples of languages that support the safe navigation operator in assignment.

@kara kara removed the comp: forms label Sep 6, 2016
@mhevery mhevery added comp: forms and removed comp: core/forms labels Sep 7, 2016
@kara kara added comp: core and removed comp: forms labels Dec 7, 2017
@ngbot ngbot bot added this to the Backlog milestone Jan 23, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.