AngularJS using $rootScope as a data store

Chris Collins picture Chris Collins · May 24, 2013 · Viewed 50.3k times · Source

I have an idea for my AngularJS app and I'm curious if the AngularJS community would consider it okay to do it this way. In short, I am connecting to a data API and displaying my results on the page.

I have created an AngularJS service that creates a data store on $rootScope.DataStore. I also have a service method that updates the DataStore with the data returned from an API endpoint. If I request the "products" API endpoint from inside my controller with DataStore.update('products'), this would update $rootScope.DataStore.products with my product data.

Now, in the view/partial, all I need to do is say ng-repeat="product in DataStore.products" to show my data, and it doesn't matter what controller scope I am in. So, in essence my DataStore is my single source of truth.

What I feel like I gain from this method is easy to follow semantics and minimal controller coding. So, anytime the DataStore is updated, anything that's bound to DataStore also gets updated.

Would this put too much load on the $rootScope digest cycle, or is this just an odd way to do it? Or is it a totally awesome way? :) Any comments are welcome.

Answer

Dan picture Dan · May 24, 2013

This question is addressed in the AngularJS FAQ quoted here:

Occasionally there are pieces of data that you want to make global to the whole app. For these, you can inject $rootScope and set values on it like any other scope. Since the scopes inherit from the root scope, these values will be available to the expressions attached to directives like ng-show just like values on your local $scope.

It seems that the team does encourage using $rootScope this way, with this caveat:

Of course, global state sucks and you should use $rootScope sparingly, like you would (hopefully) use with global variables in any language. In particular, don't use it for code, only data. If you're tempted to put a function on $rootScope, it's almost always better to put it in a service that can be injected where it's needed, and more easily tested.

Conversely, don't create a service whose only purpose in life is to store and return bits of data.

This does not put too much load on the $digest cycle (which implements basic dirty checking to test for data mutation) and this is not an odd way to do things.

EDIT: For more details on performance, see this answer from Misko (AngularJS dev) here on SO: How does data binding work in AngularJS? Specifically note the section on performance.