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.

[gkalpak]

Where do we bikeshed about the symbol ? I think < is better 😃
(No, seriously, I do... 😛 )

[robstove]

Dash '-' seemed appropriate to me. I see '=' as two directions and '-' as one direction (not the boy band). 😄

[Narretz]

@gkalpak Why <? To me >, because parent > child

[thorn0]

bindings: { propertyName: "<attrName" }

Which means: the value is copied from the attribute attrName to the property propertyName.

Indeed, < looks better.

[robstove]

How does this look:

binding: { propertyName: "*attrName" }

[thorn0]

@robstove * is already in use. It can be combined with = for watching collections. The new one-way binding should support collections too so we might end up with propertyName: "**attrName" if we choose *. 🚲

[robstove]

@thorn0 Ah good point. Forgot about collections.

[aoancea]

I personally like the idea.

@Narretz Well thank you!

[aoancea]

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

@robstove This is pretty much what came into my mind when I was prototyping the idea
For me though, from the ideas in this post, it would make more sense to use '>' as you are sending something to the child as @Narretz described