[Kiro]

"Before writing angular-data I used to create fleets of services for my various resources, each performing data management and communicating with a persistence layer."

Can someone give me an example of this? I just use $http and populte the $scope models in callbacks so I don't really recognize the problem.

[kitbrennan]

A simple example would be storing data on your 'logged in user' on a large application that has multiple controllers/services.

A scope only extends as far as a particular controller/service. If you wanted every controller/service to have access to that user's data (eg. that user's ID), you would create a service that would store that data, and then inject that service into each place you need to access the data.

[crucialfelix]

With basic $http or resource:

You have to reload all the data each time you go to this view (if you navigate back to previous page it has to reload).

You have to reload data that is used on multiple pages. eg. products, categories, tags and especially user

The most common solution is to start stuffing things in $rootScope, after that you stuff it in localStorage using angular-cache (which is great).

My own system keeps the user's menu in cache, so it loads near instantly when they come back to the site (still logged in). It invalidates the cache if the user or app version has changed.

[sqren]

For you specific purpose, I don't see why not using the built-in caching mechanism of Angular https://docs.angularjs.org/api/ng/service/$http#caching

The cool thing about angular-data, is that stuff it available, even when the browser is offline and you do a refresh.

[crucialfelix]

the built in $http cache isn't at all suitable for what i described.

I do currently use angular-cache (from the author of angular-data) and build on top of that.

I specifically need to invalidate the storage if the user is different, the server generated session id is different or if the app version has changed since the last page load.

this is a service called UserStorage which can safely be used knowing that it gets dumped if somebody tries to mess with the user or they just logged out/in.

the site I built this for is not a single page app, people load pages often. persistence is essential.

the whole site appears to be server side personalized with menus, saved notes added to property listings etc. but its all frontend enhancement and the server can cache all the pages.

[pseudobry]

For those writing largish non-trivial apps its essential to separate concerns for maintainability and testability. Controllers and UI logic get separated from domain logic and your Model layer. $scope is no Model layer.

[bsaul]

Yet angular-data doesn't seem to deal with model layer per say, but rather synchronization issues between what's somehow in the scope and the web services. To me that seems to be handled quite well with services and maybe factories for wrapping json into custom model classes.

It seems more meant ot be used as a caching layer that would wrap you webservice access services.

[Kiro]

I understand. It would be nice to see an example though.

[robbs]

Using $http and callbacks is great to get started but it doesn't scale up to large apps very well.

[chrisherring]

Can you explain why? A large app will not likely make a far greater number of http calls at the same time. If you must have up to date data then I don't see an alternative in something like angular.