Managing Global State - with services?

[Martin Probst]

Hi,

my application has a set of effectively global variables that are used and modified from different places in the application, e.g. the page title, or the currently selected item in the navigation bar.

One way to handle this is to put that state it in the root scope, and (but that's terrible) assign it with $scope.$root.pageTitle = 'Spooky action at a distance'. I'm also a bit worried about modifying the root scope, I assume that'd cause a lot of cascading checks in all child scopes?

The other way would be to have a service that encapsulates the state, e.g.

angular.module(...).service('appState', function() {  return { pageTitle: 'Initial' }; }); 

But how would I go about using that? Just putting it into the scope object?

function MyCtrl($scope, appState) {

  $scope.appState = appState;

}

Martin

[Peter Bacon Darwin]

I have played with both strategies. Services are nice but as you point out they add a layer of complexity.If you are going to assign it to the scope I suspect you will be triggering digests when it changes anyway, although I don't know if the guys at Google (GaGs) have optimized this at all.
So there is not much benefit to be had there.
By the way, if you have an object stored at the root, you can change its fields on any scope without having to resort to scope.$root.
The benefits of services come from modularity and being able to hide implementaction details from the controllers.
Pete

...from my mobile.

--
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.
For more options, visit this group at http://groups.google.com/group/angular?hl=en.

[Martin Probst]

I have played with both strategies. Services are nice but as you point out they add a layer of complexity.If you are going to assign it to the scope I suspect you will be triggering digests when it changes anyway, although I don't know if the guys at Google (GaGs) have optimized this at all.

A third way of handling these things would be events on the $root scope, e.g. $rootScope.$emit('titleChanged', 'Rollmops', ...), which are listened to by whomever it might concern. That sounds both efficient and kind of reasonable for this type of operation (current title, currently selected item for some definition thereof ...).

So there is not much benefit to be had there.
By the way, if you have an object stored at the root, you can change its fields on any scope without having to resort to scope.$root.

Are you sure? The way I read code and documentation is that assigning into a scope will create a new property on that scope, but that's distinct from the property on the root (or any parent) scope.

Martin

[Peter Bacon Darwin]

If you assign to a property on a property of scope then it is the original property on the parent scope that is updated.

Pete

--

[Martin Probst]

If you assign to a property on a property of scope then it is the original property on the parent scope that is updated.

Ah sorry, I didn't understand that you were referring to assigning into a property _within_ the other property. That makes sense :-)

Martin

[guill...@gmail.com]

Did there some sort of best practice showed up since the last answer?

I try to follow the Angular design principles to keep my code clean, I came up with the pattern "service expose a state object, controller attach that state object to scope" but I'm not sure it's the best way.

[Will Kriski]

I use services (I had to because my ng-views have their own scope), then you inject the service into each controller. In my HTML I access the data (set/get) via functions in the controller. So there is no data in the controller (the entries array in the fiddle below).  

Here's a fiddle - http://jsfiddle.net/willkriski/LBwHC/26/