I have been reading wrox angular book. Inside the book the author describes that a method of sharing data between controllers is to

1. Have a property on the root scope
2. Update that property on the root scope
3. Broadcast the fact that the property was updated
4. All children scopes that need to know , will listen for the broadcast.

as opposed to expose an object on a Service and letting angular's two way databinding do all the heavy lifting. Why would anyone go with the 'root scope publish/subscribe' methodology, instead of exposing an object on the service?

I have been reading wrox angular book. Inside the book the author describes that a method of sharing data between controllers is to

1. Have a property on the root scope
2. Update that property on the root scope
3. Broadcast the fact that the property was updated
4. All children scopes that need to know , will listen for the broadcast.

as opposed to expose an object on a Service and letting angular's two way databinding do all the heavy lifting. Why would anyone go with the 'root scope publish/subscribe' methodology, instead of exposing an object on the service?

• javascript
• angularjs

3 Answers 3

That's interesting question.

First we should consider differences on various levels:

• Scope

  • in case of $rootScope we define variable in global scope
  • in case of shared services we can inject this service to controllers that really use this value

• Extensibility

  • $rootScope - we have limited options to add additional logic to work on this value (we can define another global function)
  • shared services - we are free to define any kind of logic

• Encapsulation

  • $rootScope - all object defined in $rootScope would be visible in all modules
  • shared services - we can decide what is visible and what is not

• Modularity

  • $rootScope - global variables is not places in module spaces
  • shared services - service is a separate module for application

• Maintaining

  • $rootScope - it's very hard to find which ponents use our $rootScope variable.
  • shared services - we can see which services we use and we can find in which ponent we use this service

• Binding

  • $rootScope - it is easy to setup two-way binding in several controllers on one variable in $rootScope
  • shared services - could be tricky to enable two-way binding

In my opinion this is only useful for make really global variables.

Say you have two controllers A and B, and a service S, storing the mon data.

When A changes data in S, B cannot directly change its scope value by understanding that data in S has changed. Someone has to say to it that data in S has changed and update its scope according to this change. This may be done two ways.

• One is rootScope broadcast: service S broadcast changes and B listens this broadcast.
• The other $scope.$watch: In controller B, scope must watch the changes in service data.

It depends which kind of data you are managing, if you are for example relying on a DB where you perform CRUD actions, you'd like a service to just interact with the DB.

That's called a stateless service, some people vouch for it and some are against and prefer to have state also on the service, exposing the object as you mentioned.

I'll leave you a couple resources with more information on the topic so you can decide which solution suits you best

http://www.johnpapa/sharing-data-in-an-angular-controller-or-an-angular-service/

http://www.webdeveasy./angularjs-data-model/