Feature request: make one-way expression bindings for components

[thorn0]

See http://teropa.info/blog/2015/10/18/refactoring-angular-apps-to-components.html#replace-two-way-binding-with-one-way-binding

There seems to be little value in the ability of components to change values in the parent scope via two-way =-bindings. @-bindings are one-way, but they can be used only for string values. It'd be logical to introduce a new kind of one-way bindings for expressions of any type or to change the behavior of =-bindings for components (defined with the component method).

[17cupsofcoffee]

👍 This would make it a lot easier to migrate components across to Angular 2, as well - the less we're relying on two-way binding, the less we'll have to refactor later on. At the minute I'm just trying to enforce 'don't mutate the inputs' as a code convention, but it'd be great to not have to rely on that.

[Narretz]

There's actually a PR for that: #12835
I personally like the idea.
👍

[robstove]

Nice start. Out of curiosity, what is the reasoning for using '#' for specifying the binding mode?

[thorn0]

I believe it's still not late for the 1.5 release to include this. It'd be really consistent with the rest of the changes related to the component approach. Please consider extracting it from the ice box before the release.

Let me quote the description of the Ice Box milestone:

Milestone for valid issues and bugs that we have no aspirations on fixing any time soon because they are not affecting primary use-cases and are not aligned with our goals.

I can't agree that it's not aligned with the current goal of migration facilitation.

[robstove]

@thorn0 +1

[Narretz]

We'll talk about this in the meeting today.

Regarding the symbol for it, there's nothing set, but > is favorable. - is also okay, but might be confused with the dash delimiter. # has no real connection to bindings.

[thorn0]

@Narretz That's great. As for the argument of 'further complicating the DDO API', the API docs can be made to appear less complicated by adding a standard highlighted paragraph 'Best Practice', which would recommend using these new bindings for inputs and & (or events?) for outputs.

[Narretz]

@robstove

Yes, last minute addition for 1.5. Although, compared to the PR here #12835 We are not going to copy the parentValue, instead we just set it on the isolate scope. This means, if you have bind an object and then change a property on that object, it'll be reflected in the origin scope. This is because completely copying the object to the isolate scope is very difficult. If you need to make a copy, you can always do that yourself.

[robstove]

Perfect! Will look forward to this enhancement. Thanks guys.