Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
2-way binding syntax, e.g., [(ngModel)], should support elvis operator #7697
A2 supports the elvis operator (?.) in property bindings but not "two-way" bindings.
This is ok:
A2 throws an error if I write
Today's workaround is
Recommend that template statements support elvis in assignments.
For example, the following
It follows that we will then support
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.
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.
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
Time for some creativity.
If I recall the discussion with @IgorMinar correctly it was more like he wasn't sure if it's the right pattern to promote.
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
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.
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.
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!
For me the workaround is just bull****, do you really think it's a good approach?
I hope you guys can understand my complaints and probably give this a little more attention.
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.