Binding / Expression Namespaces (better BindOnce alternative)

[ProLoser]

So lots of people are asking for 'BindOnce' but I actually don't believe this is the best approach to handle performance. Not only does it require specific directives, it also doesn't properly tackle the 'bind-occasionally' scenario, or when it does, it requires a completely different directive. Instead I propose:

Expression Namespaces

Examples:

• ng-bind="{ personNamespace: person.name }"
• {{personNamespace:: person.age}}
• ng-if="personNamespace:: person.alive"
• ng-repeat="personNamespace:: child in person.children "
• $scope.$watch('personNamespace:: person.height', ... )
• {{i18n:: i18n['welcome.message']}}
• ng-if="login:: hasPermission('DeleteUsers')"

These would all be handled by:

ng-namespace="{ personNamespace: person }" or $scope.$namespace({ personNamespace: 'person' })

Only the ng-namespace expression is evaluated on every $digest. When the expression changes in value, all namespaced bindings get re-evaluated.

The person value would be watched normally, and every time it changes, the personNamespace bindings throughout the rest of the application would be refreshed.

This is pretty much JUST 'bind-occasionally' since if the 'occasional' occurance is only once, then you are getting the same benefit of a bind-once.

Benefits:

• You can intermix multiple namespaces together, unlike bindonce which sections off groups of bindings
• Completely backwards compatible with the old syntax
• Simplistic syntax that can be used anywhere expressions are used
• All bindings are bind-occasionally
• Problems such as internationalization, permission restrictions, etc can all be tackled with traditional bindings without needing to create workaround directives
• Additional edge-cases for undeclared namespaces (if the namespace isn't declared in ng-namespace)
  • If namespace is undeclared, behave like bind-once?
    {{once:: person.name}}
  • If namespace is undeclared, fall back to normal watching behavior?
    {{always:: person.selected}}

Issues:

• Using ng-namespace (a directive) may be confusing alongside namespaces in watchers (controllers). I am not 100% sure the watcher version is necessary however.

Implementation

I was discussing how the best way to write an efficient translation solution and we realized that instead of using watchers, it's better to use $broadcast() to signify that a namespace digest has been triggered. I'm not necessarily saying this is how it should be implemented in the core, but this was one idea we came up with.

This separates the expression being WATCHED from the expression being ECHO'd

It's like saying "Although I want to spit out person.age I want you to just monitor person for changes". However what is being 'monitored' is defined in your ng-namespace. Each binding or expression is no longer being watched. Instead they are waiting for some sort of $broadcast('namespace-person') instead, and only 1 watcher is ever actually used.

TL;DR:

Using expression 'namespaces' we no longer deal with turning off / on bindings. Instead, only 1 expression is 'watched' and all the other bindings are tied to this one expression. There is no toggling on and off of bindings.

<div ng-namespace="person:: person.id">
  <h1>{{person:: person.name}} ({{person:: person.age}})</h1>
  <h2>{{person:: person.title}}</h2>
  <p>Gender: {{person:: person.gender}}, Company: {{person:: person.company}}</p>
</div>

[rhettl]

I like your solution in part -- specifically, I like the part that it works in expressions, which work in AND out of directives due to $scope.$eval() and similar functions. Also, depending on how this solution and ngBindOnce are implemented in the core, this solution may be easier to implement in some custom directives then ngBindOnce.

My use case for ngBindOnce is a search menu with many nested layers. Due to the number of nested repeats it adds easily an estimated 8000+ watchers -- this number is just the search menu and doesn't include the rest of the app.
With your solution I would definitely reduce my overall load but, as I understand it, each of those watchers would still exist somewhere in memory. They may not do anything 99% of the time but they will still exist. I am unsure if this would resolve my problem or if it would only reduce the symptoms significantly.

The major advantages that ngBindOnce has to this solution include: (order irrespective)

1. The simplicity of fire-once-and-done
2. The syntax matches pre-existing directives so there is very little to learn
3. No need to add the additional layer of complexities that namespaces inherently brings to the table
4. No additional watchers. Not silent watchers but no watchers

Though, you mention backwards compatibility in syntax as on of your benefits list so I am willing to stipulate that number 2 may be nullified. personally though, I find the directive name easier to use and learn then the extra namespace syntax. But is just my opinion.

All in all, great alternative. As long as the core team adds something to solve this problem, or at least greatly decrease the problem, I will be somewhat more happy.

[ProLoser]

@rhettl actually no, your 8000+ watchers would be lumped into 1 watcher and that 1 watcher would trigger (potentially) 8000+ re-evaluations

As for the ngBindOnce advantages:

1. fire-once-and-done in the long run is never going to stick. There is always going to be a refactor where you come back and realized that 'once' was not enough, you wanted 'twice' or 'thrice'. How about this addendum: if the namespace is not found, then the expression is evaluated once. If a namespace is added later, then the namespaced bindings latch on and begin using it as a listener. Alternatively, the case of wether or not the ng-namespace exists or not can add more variety of control.
2. What? What pre-existing directives? Third-party libs should not really be brought into consideration of refactor-value. AngularJS should not try to exactly emulate third party libs for the sake of back-compat
3. This is debatable. Bind-once already has an aspect of 'namespacing', it's just limited to 1 namespace. This would/could be the same as using a namespace that was never defined
4. I am not proposing using inactive/silent watchers. I'm talking about your namespace being your only watcher, while the rest of the bindings are simply evaluators.

I don't really think adding more directives makes life simpler. It makes it more complicated to refactor, and you lose aspects of fallbacks and back-compat that you would otherwise gain from being able to implement namespaces anywhere an expression could be used.

[rhettl]

@ProLoser,

My understanding of this is that <span>{{person.name}}</span> will generate a watcher normally. In order for <span>{{personNamespace: person.name}}</span> to change, there will still need to be some sort of watcher/process generated. This watcher/process will either have to:

1. watch the personNamespace namespace
2. register itself with a stack of changes to be made when the personNamespace namespace changes, or
3. have a type of watcher which exists but is evaluated in the digest after personNamespace changes instead of on every digest.
   This is what I mean by silent/inactive watcher. It is a watcher that exists in memory and technically takes up space, but isn't activated on every digest like a normal watcher. I know that this will still decrease process time significantly, but I wonder if it might still bog down browsers (I really don't know -- if it won't bog down even at 8000+ of these silent watchers then my point is nullified :D).

As for the "ngBindOnce advantages" response list:

1. I agree with your point that it will never be enough, someone will always need a bind twice and many people have requested over and over a bind-on-off switch. This does seem to solve that problem as well.
2. By pre-existing I mean the existing directives like ngBind. Since ngBind is a common directive already, it is very easy to understand the functional difference from the core's ngBind to a directive named ngBindOnce
3. Agreed, it is debatable.
4. See point above regarding "silent/inactive watchers"

I can see where adding more directives might make re-factoring more difficult. I know that more directives can add more complications, but I also feel that the declarative nature of AngularJS is in the understandable directive. The more distinct a directive name, the more intuitive it is to use and the easier it is to learn for new people.

Though I am not sure I see how "[...] you lose aspects of fallbacks and back-compat [...]"

Enjoying the discussion,
-- Rhett :D

[ProLoser]

No matter what you're going to be storing SOME sort of reference in memory. Keep in mind, if you have 8000+ bind-once directives you are executing the linking function 8000+ times. You may also want to simply look at DOM virtualization for your specific usecase.

Regardless, when we're not talking about DOM manipulation, JS can keep up pretty well if it's unavoidable memory storage (it can iterate and modify 400,000 objects in an array in milliseconds, as I've found). Arguing the merits of storing a reference to {{x}} placeholders vs bind-once="x" placeholders vs anything else is kind of moot. In any and all scenarios, SOMETHING is going to be registered in a cached stack. This however is not that big of a deal if done at a bare-minimum use-case.

You're also slightly confusing how the watcher works in my proposal. You do NOT have 8000+ functions observing 1 value for changes. You have 8000+ callbacks waiting to be triggered. The namespace watcher, when fired, iterates through these 8000+ callbacks and fires them all. In other words, unless the namespace is triggered, these 'processes/watchers' will never be touched, execute, perform checks, etc. They would simply be inactive functions in memory in a collection.

[ProLoser]

As for the merits of back-compat/fallback/api, I personally feel you're better off going into your existing expressions/bindings and adding a prefix than changing which directive you are using altogether. This means that third-party libs, etc, will break if they expect you to be using a specific binding. However, by simply adding additional syntax triggers to expressions, as you stated, you can now use this namespacing anywhere in the codebase. AND third party libs would be more capable of handling namespaces since they can just be stripped out (either by the lib or by angular) vs having to completely switch between which directive you're firing.

More directives != simplicity. It means more complexity, more API to learn, and a higher barrier of entry. Part of the beauty of angular as a whole is that you are capable of doing things like $scope.val = whateverTheHellYouWant vs something like new Knockout.Observable('Array') and all that garbage. Keep the API simple and just make it more versatile, rather than creating one directive/method/endpoint/api for every possible variation of a behavior (even if they get broken down internally).

[rhettl]

Okay, thank you for the explanation on multiple accounts,

The namespace watcher, when fired, iterates through these 8000+ callbacks and fires them all.

This meets my #2 above, "[...] register itself with a stack of changes to be made when the personNamespace namespace changes." You sound like you have some experience in the iterative power of JS and I am inclined to trust that. I would still be interested to see the benchmarks after the code has been more or less completed :)

To the back-compat paragraph, your argument is reasonable. I have been making a lot of directives lately for work's user interfaces and if one is expecting a particular directive like ngRepeat or ngBind it would be off-putting to suddenly have ngRepeatOnce and ngBindOnce, though I am unable to come with a use case where someone would want to do this w/o allowing the normal use of the original version. I can see how using the expressions would be beneficial, as it would hopefully easily pass through $parse and $eval as current ones do. While writing this I am considering the ramifications of putting one of these namespaced expressions through $parse and how it would work with var value = $parse($expr)($scope) and $parse($expr).assign($scope, newValue)

I agree with much of your last paragraph on "directives != simplicity" but I did not mean to imply the opposite. Anyway, I think this portion is something of opinion on both our accounts as far as which will be more simple. Personally, while I don't see yours as more simple, if it is simple enough and benchmarks better, then I think most of the other issues will resolve them selves eventually.

[lega911]

The namespace watcher, when fired, iterates through these 8000+ callbacks and fires them all.

Look at text-directives in Angular Light, when you write "{{=model}}" instead of "{{model}}", it works like bindonce. Also you can use "personNamespace": "{{#personNamespace model}}".
AngularJS could have something like this.