$watch vs $on

[Venkat]

Some features can be implemented using $watch or $on event listener.

Is there any difference in performance or advantage of $watch vs $on?

[Pawel Kozlowski]

Those are completely different things...

$watch - watch for changes to expressions evaluating against a scope
$on - react on events sent through the scopes hierarchy

So comparing them doesn't make much sense really....

Cheers,
Pawel

On Mon, Dec 10, 2012 at 5:49 PM, Venkat <ram...@gmail.com> wrote:
> Some features can be implemented using $watch or $on event listener.
> Is there any difference in performance or advantage of $watch vs $on?
>

> --
> You received this message because you are subscribed to the Google Groups
> "AngularJS" group.
> To post to this group, send email to ang...@googlegroups.com.
> To unsubscribe from this group, send email to
> angular+u...@googlegroups.com.
> Visit this group at http://groups.google.com/group/angular?hl=en-US.
>
>



--
Question? Send a fiddle
(http://jsfiddle.net/pkozlowski_opensource/Q2NpJ/) or a plunk
(http://plnkr.co/)
Need help with jsFiddle? Check this:
http://pkozlowskios.wordpress.com/2012/08/12/using-jsfiddle-with-angularjs/

Looking for UI widget library for AngularJS? Here you go:
http://angular-ui.github.com/

[Venkat]

Thanks Pawel for the reply.

[Mike McElroy]

Venkat, it may help to know exactly what you're wanting to use them interchangeably as.  Interdirective/controller communication?

IMHO (and IME, O's are never H), you shouldn't be thinking about using them interchangeably.  Have a plan of action when approaching your project.  I have the impression that event listeners are valuable for when you have a lot of action happening in response to an event, or data can change in different ways and you want to react to it differently.  The $watch logic surrounding something like that can be very nasty, and will lead to problems eventually, where just listening for a specific event can make things a lot easier.

If your change happens in a predictable way (like a grid updating with sorted/filtered data), $watches are probably your more performant option.  But I have no numbers to back that up.

-MikeMac

[Venkat]

Hi MikeMac,

Thanks for the reply.

In the following fiddle,

http://jsfiddle.net/ramandv/qPEm7/

I have two versions of ControllerA . One version monitors service using $watch and Other version with $on.

Fiddle overview: 

When you click the "random currency" link in ControllerB, ControllerB updates the myService. 

myService is being monitored by ControllerA to get changed Currency.

What do you suggest $watch or $on in this scenario?

-Venkat

[Mike McElroy]

I'm gonna go with certainly not $on.  

Have to get into a meeting, but check out http://jsfiddle.net/8tLfP/

On Tue, Dec 11, 2012 at 9:19 AM, Venkat <ram...@gmail.com> wrote:

http://jsfiddle.net/ramandv/qPEm7/

[Mike McElroy]

What the heck?  I'm not used to jsFiddle.  Sorry, that's http://jsfiddle.net/8tLfP/1/

[Venkat]

Thanks MikeMac.

Based on your answer and some  articles, my understanding on the usage of $watch and $on are

- if it is communication between ControllerA and ControllerB, then $on can be used . Because ControllerA cant get the ControllerB reference.

- But in most of the other cases, $watch should be suffice.

And also $broadcast can be received by all the other Controllers or directives, which may not be desired. So if we can use $watch, it is better to use that.

Btw, your changes (http://jsfiddle.net/8tLfP/1/) in the code removes the encapsulation of the myService. Because now, the controllerA can change the myService members.

-Venkat

[Mike McElroy]

Venkat, 

I didn't realize full encapsulation was in your specification.

http://jsfiddle.net/8tLfP/2/ is more along the lines of what you were thinking, using $watch.  BTW, syntactically, your use of service vs. factory doesn't seem right.  As I understand it, and I could very easily be wrong, service constructors operate on a blank instance (services use this a lot), whereas factories return an object constructed within the function.  I changed it to a factory in /2/.

http://jsfiddle.net/8tLfP/3/ is your requirement using .service and $watch.

-MikeMac

[Venkat]

Hi MikeMac,

Thanks a lot for pointing out the service vs factory mistake.

After you reply, I was trying to understand  the difference service vs factory. found the following thread

https://groups.google.com/d/topic/angular/56sdORWEoqg/discussion

The above thread is very good in highlighting the differences among service, factory and provider.

Thanks,

Venkat

[Mike McElroy]

np, Venkat.  I came from a C#.NET background, so it was really difficult to wrap my head around the service/factory/provider differentiation until I let go of my old-language frame of mind.

If you're coming from a .NET or Java-type language, you may have a hard time dissociating the word "service" and "factory" from the meanings they have in those worlds.  Completely separating those ideas (loosely couple them?) helped me to understand them better.  Also just trying lots of different possibilities and seeing what came out on the other end.

Something like this: http://jsfiddle.net/pE9TJ/2/

:-)

-MikeMac

[Peter Bacon Darwin]

It is useful to think of all services as nothing more than singletons that can be injected into other components as required.  Nothing more nothing less.

Also having a background in .NET, I found it also helpful to think of AngularJS controllers as ASP.NET "code-behind" files.  In other words, you have your template for a page (or user control) in .aspx (or .ascx) files an the "controller" in the page behind, .aspx.cs (or .ascx.cs).  This is fundamentally a different programming model from the Rails controller which is not code behind for a template but actually deals with the current request usually resulting in rendering a template.  The Rails kind of controller is probably most similar to the route definitions in AngularJS.