Support one time bindings in component signature

[asulaiman]

I'm submitting a ...

• bug report
• feature request
• other (Please do not submit support requests here (see above))

Current behavior:
Currently the only way to define one time bindings is in the parent template which defines the component itself.

<my-component item="::someBinding"></my-component>

At the moment if a component is designed to support a binding which should be one time everytime, we need to add the one-time binding :: notation to the binding attribute each time the component is used.

Expected / new behavior:
In the component definition, provide an :: binding type. So the above example if it was supported on the component level would see the component defined as follows:

angular.module('myApp').component('myComponent', { templateUrl: 'template.html', bindings: { someBinding: '<::' } });

Consequently usage of the component would then be:
<my-component item="someBinding"></my-component>

Minimal reproduction of the problem with instructions:
Basically if i have a component with a one way binding which would/should use one-time binding, i do not want to define the one time binding everytime on the parent template level. This would also enforce the usage of one time-binding for this particular binding on the component.

AngularJS version: 1.6.5
Browser: all

[Narretz]

I can see the utility, but I'm not sure how often this is needed, and if it warrants the complexity that comes with implementing this,

[gkalpak]

I would have used it quite often (and I don't think it will be hard to implement) 😁
My concerns are mainly:

1. This complicates the directive API (which is something we don't take lightly, as this thing is already quite complex).
2. This is not something that is currently possible with Angular (2+) afaik, and we are generally trying to avoid introducing new features (or encourage practices) that will make the transition to Angular more difficult.

Also, we are talking about saving a few : or reducing a few (generally) cheap bindings. So, I don't expect this to a noticeabe impact.

So, although I think it might have been a good idea to introduce this back when one-time bindings were implemented, I am not too keen on introducing this now.

[asulaiman]

@gkalpak
This complicates the directive API (which is something we don't take likely, as this thing is already quite complex.
I know that we already support two character binding configuration with required bindings <? and i presume that adding support for one-time binding here would just be a matter of reusing what is already implemented for one time bindings. Is it really a lot of complexity over what we already have?

This is not something that is currently possible with Angular (2+) afaik, and we are generally trying to avoid introducing new features (or encourage practices) that will make the transition to Angular more difficult.
Youre right it isnt, good point. However as far as i can tell, one time bindings are not supported at all in Angular 2+. So transitioning to Angular 2 would already require some adjustment on those components that leverage one time bindings. Isnt doing that refactor on the component definition level less cumbersome than ripping them out from all the templates that use the component?

Also, we are talking about saving a few : or reducing a few (generally) cheap bindings. So, I don't expect this to a noticeabe impact.
I think its not just about ease of use for cheap bindings but also a means of enforcing their usage when more expensive bindings shouldnt be used. This is something that comes up very often when i do code reviews with my teams.

[gkalpak]

I know that we already support two character binding configuration with required bindings <? and i presume that adding support for one-time binding here would just be a matter of reusing what is already implemented for one time bindings. Is it really a lot of complexity over what we already have?

Like I said, implementing it should be fairly straight forward. The public API though would get considerably more complicated. Before people have to understand and memorize @, =, <, &, @?, =?, <?, &?, =*. Now would also be ::@, ::@?, ::=, ::=?, ::<, ::<?, ::=*.

I can totally imagine jokes about one-time, two-way, optional, collection bindings (or ::=*? for short) 😛
I can also imagine people wondering whether to use one-time, two-way collection bindings or one-way optional bindings (although most people won't be wondering that, because they will have no idea what that even means).

You get the point (hopefully). I am not saying it something experienced AngularJS devs can't handle, but for the average user, it will be an unnecessary burden. (Like I said, the gains will be minimal in 99% of cases.)

I think its not just about ease of use for cheap bindings but also a means of enforcing their usage when more expensive bindings shouldnt be used. This is something that comes up very often when i do code reviews with my teams.

As already said, there is merit and there is cost. (Tradeoffs, tradeoffs 😃)
If you are too concerned about performance, you can still have your one-time bindings by expplicitly using :: when binding (which is inconvenient but works) and most of the time (especially when using <) the extra watchers (if you don't explicitly use ::) are cheap, so I can hardly imagine this becoming a performance bottleneck in your apps.

And if you are too concerned about enforcing the "one-time-binded-ness", you can create a utility that maually checks the bindings (e.g. during compilation or something).

Sure all this is inconvenient, but is doable. Thus, I said we are talking about making things more convenient for fewer people or keeping things more convenient for more people. (Plus there is the Angular incompatibility.)

Frankly, I would love to have this feature for myself, but I don't think it is a good addition for most users (what an altruist 😛).

_{(As always, this is just my opinion and I am happy to move along if others are happy with it.)}

[asulaiman]

With a very heavy heart i guess i would have to agree. Interesting that you mention:

most of the time (especially when using <) the extra watchers (if you don't explicitly use ::) are cheap

I guess its cheaper than a two way binding but it still means that angular maintains a watcher on the parent scope no? How does that make it cheap?

[gkalpak]

I mean they are as cheap as watchers can get (which is not the case with = bindings for example). They are just regular, non-deep watchers, which boils down to a simple === check (which is the fastest form od equality check you can get in JavaScript 😃). Also, AngularJS can optimize them (if possible), for example automatically remove the watcher for constant bindings or watch their inputs (if the expression has inputs and is considered pure etc).

[asulaiman]

If anyones interested i created a webpack loader to accomplish this. Can be found here:
https://github.com/asulaiman/angular-onetime-binding-loader