watch VS listener

[Eduardo-Julio]

Hi,

I was looking for something like this to decrease the number of watchers in a part of the app with a lot of scopes values in the view, and to just update the values in the html when necessary.

The thing is, after making some tests, I can see that the number of watchers decreases, but they are just replaced by listeners.

So for example:

        <div
            bind-notifier="{ keyName:scopeValue }">
            <span
                ng-bind=":keyName:scopeValue">
            </span>
        </div>

The ng-bind watcher is replaced by a listener that is triggered when the bind-notifier value changes and emits a event, I get it.

But applying this to 30 ng-bind elements for example, just create 30 listeners instead of 30 watchers, right?

Maybe Im missing something here so it would be great to know the advantage, thanks.

[aeisenberg]

It sounds like you don't want bind notifier. I think you're looking for one-time binding, using the :: syntax.

[Eduardo-Julio]

It sounds like you don't want bind notifier. I think you're looking for one-time binding, using the :: syntax.

Thanks for the quick answer.

Nope, as it says on the readme of this package

This package is meant for those looking for a middleground between two way binding, and one time bindings. someTimeBinding?

I need to update binds just when I want, not when they change value (to save on watchers).

Can you please help me understand the benefits of changing the watchers for listeners? Im probably not understanding something about this or how it works. Thanks!

[aeisenberg]

Right...ok. The way that you update bindings on demand is by emitting an event over the proper scope. The bindings to be notified must be listening on that scope. This is the way the package is implemented, using standard angularjs listeners. Using this package, it is not possible to directly trigger a rebind without a listener. I'm not even sure how that would be done in angularjs.

[Eduardo-Julio]

Thanks for the explication.

So what Im understanding with this (and I have searched a lot about it without finding much), its that listeners have better performance than watchers?

If I implement the :keyValue: structure on 100 bindings, those are going to be 100 listeners waiting for the event to update. Ok. So thats better than 100 watchers, is that correct?

[aeisenberg]

It depends on the situation. If you want to compare a single digest cycle all of the listeners firing and all of the watchers being trigger, the watchers would be more performant. This is not the use case for this package.

The use case is that these bindings will be notified rarely and only under controlled and well-known circumstances. Unless they handle an event (and creation and deletion), listeners do not use any cpu. 300 inactive listeners do not affect performance. (They do affect memory usage, but not significantly more than watchers.)

[Eduardo-Julio]

I really appreciate the explication, I will use it then when its the right situation because it seems that listeners are better than watchers in some situations, thanks.

[aeisenberg]

Thanks for your interest in the project.