Open dcherman opened 7 years ago
gkalpak
commented
7 years ago I generally like the idea. (Maybe ng-bindon- would be a more suitable name though :smiley:)
Without giving it much thought, one thing that I am not excited about is that this will require a little extra work (sme as we do for ngAttr) for every attribute we process.
dcherman
commented
7 years ago Yea, naming is hard. I couldn't think of an ng-bind variant that was both succinct and clear.
Are the two best I've got so far. Wasn't too concerned about the name in the proposal since we can bikeshed that while implementing the actual meat of the feature.
As far as any perf implications, I think that with a fairly simple modification to NG_ATTR_BINDING and collectDirectives in $compile, we can get this feature without any additional iteration of the attributes and with minimal overhead. I'll see about throwing together a proof of concept when I have some time over the next few days.
Similar to Angular 2's "banana in a box" syntactic sugar to support adding a one-way binding and an expression to set that one-way binding all in one shot, how would you feel about supporting something like:
<my-component ng-banana-foo="bar>which would expand internally to<my-component foo="bar" foo-changed="bar=$event">?While the proposed syntax isn't quite as nice as the Angular2 one, I thought it might be important to not use the same syntax in order to avoid confusion between the two frameworks. With the push towards components and unidirectional dataflow since 1.5, this would be a really nice enhancement to reduce some of the verbosity associated with actually following those ideas.