-
Notifications
You must be signed in to change notification settings - Fork 27.4k
Feature: Support unidirectional dataflow syntactic sugar #15455
Comments
I generally like the idea. (Maybe |
Yea, naming is hard. I couldn't think of an
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 |
In order to reduce some of the verbosity associated with conforming to the ideas behind unidirectional data-flow, we can introduce a special attribute syntax that will be automatically expanded in order to simulate two-way data binding. For example, `<my-component ng-autobind-foo="bar">` will be expanded into `<my-component foo="bar" foo-changed="bar = $event">` Fixes angular#15455
In order to reduce some of the verbosity associated with conforming to the ideas behind unidirectional data-flow, we can introduce a special attribute syntax that will be automatically expanded in order to simulate two-way data binding. For example, `<my-component ng-autobind-foo="bar">` will be expanded into `<my-component foo="bar" foo-changed="bar = $event">` Fixes angular#15455
In order to reduce some of the verbosity associated with conforming to the ideas behind unidirectional data-flow, we can introduce a special attribute syntax that will be automatically expanded in order to simulate two-way data binding. For example, `<my-component ng-autobind-foo="bar">` will be expanded into `<my-component foo="bar" foo-changed="bar = $event">` Fixes angular#15455
In order to reduce some of the verbosity associated with conforming to the ideas behind unidirectional data-flow, we can introduce a special attribute syntax that will be automatically expanded in order to simulate two-way data binding. For example, `<my-component ng-bindon-foo="bar">` will be expanded into `<my-component foo="bar" foo-change="bar=$event">` Fixes angular#15455
In order to reduce some of the verbosity associated with conforming to the ideas behind unidirectional data-flow, we can introduce a special attribute syntax that will be automatically expanded in order to simulate two-way data binding. For example, `<my-component ng-bindon-foo="bar">` will be expanded into `<my-component foo="bar" foo-change="bar=$event">` Fixes angular#15455
In order to reduce some of the verbosity associated with conforming to the ideas behind unidirectional data-flow, we can introduce a special attribute syntax that will be automatically expanded in order to simulate two-way data binding. For example, `<my-component ng-bindon-foo="bar">` will be expanded into `<my-component foo="bar" foo-change="bar=$event">` Fixes angular#15455
In order to reduce some of the verbosity associated with conforming to the ideas behind unidirectional data-flow, we can introduce a special attribute syntax that will be automatically expanded in order to simulate two-way data binding. For example, `<my-component ng-bindon-foo="bar">` will be expanded into `<my-component foo="bar" foo-change="bar=$event">` Fixes angular#15455
In order to reduce some of the verbosity associated with conforming to the ideas behind unidirectional data-flow, we can introduce a special attribute syntax that will be automatically expanded in order to simulate two-way data binding. For example, `<my-component ng-bindon-foo="bar">` will be expanded into `<my-component foo="bar" foo-change="bar=$event">` Fixes angular#15455
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.
The text was updated successfully, but these errors were encountered: