persistence with routing

[Pudas Jriest]

Hi all,

I was reading this thread:

Having used angular for all of 3 days, I came to the same conclusion as the author -- using root scope to store my state.  Others replying suggest using a service to cache state in order to avoid using the root scope.  Though this sounds like an alternative, my concerns with a custom service to store states are:

1) Repeating data: My controller would have to copy this from the caching service to the $scope on each invocation. I may have thousands of items that I don't necessarily want to 'copy' from this 'cache service' into the scope (this is a heavy weight app).

2) More coupling: Each time more user input state is added (i.e sorting, filter etc) I need to catch that update to the model and store it in the cache service too.  I'd also have to modify the controller so that on subsequent invocations that additional cached state was again reflected in the $scope (re implement 2 way binding, but this time between controller and service!) -- is there some easier way to achieve this that I'm missing?

In essence I'm concerned that another service, though avoiding the use of root scope, would be worth the additional maintenance burden.

Warm regards,

PJ.

[Antonio Fernández Porrúa]

1. The values are not copied, just referenced.

2. You should not use your scope as your model, and you do not need to.
Put in the scope only the things needed in the view, neither more nor less.
This way there are less values to check.

3. Your service could be just a javascript empty object, where you store anything you want.

angular.module(foo).service('bar',function(){ return this; });

Then in your controler

If(bar.baz === undefined){
bar.baz = $scope.baz
}
$scope.baz = bar.baz

If baz is an array or an object this will work fine, so you can use an object to store strings and numbers

[Luke Kende]

I agree with Antonio.  You are going to shoot yourself in the foot putting everything on $rootScope even though it will seem easier to start.  Services are the way to go, period.  It took me awhile to realize what Antonio and others are saying: your model should be in your services not on the $scope in the controller.  It will make sense in the long run.  But if you must learn the hard way, try it on $rootScope first.  Though you will probably get it to work, once your application is big enough, it will be much more problematic to manage.

[Pudas Jriest]

Okay, so I had to actually write a service for the cache to see how it does make a lot of sense.  Good points.

Actually, another free advantage i got out of adding a caching service was that I can avoid scope.apply()... which I was having to use because the updates to the scope were not emanating from angular.  Now since I am building up the model on the scope from another source, that goes away too which makes things neater.

On the amount of data on the scope, you are right.  I'm just copying all data: $scope.component { xyz = cache.component.xyz}, but now I have a great place to be selective when needed.

Thanks a bundle. 

PJ

[Luke Kende]

Your email name is kinda funny.  Glad you figured it out and it is clicking for you.  Services/factories can be really versatile and powerful and keep code clean...  Happy coding!

--
You received this message because you are subscribed to a topic in the Google Groups "AngularJS" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/angular/zRTm0xd92fA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to angular+u...@googlegroups.com.
To post to this group, send email to ang...@googlegroups.com.
Visit this group at http://groups.google.com/group/angular.
For more options, visit https://groups.google.com/d/optout.

[Jonathan El-Bizri]

Something that should probably be mentioned in regard to placing your model in scope is that it makes services that consume $rootScope stuff harder to test. Since services are instantiated before runtime, you can't just inject a '$new' scope into the service to test - you have to build a mock for it. And this ends up involving mocking out a lot more than you actually want to test - $apply, $on, etc, etc, etc.

I've used scope-as-model in a couple of early projects, and I'm in the process of refactoring them now I've seen the light :)

Jonathan

--
You received this message because you are subscribed to the Google Groups "AngularJS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to angular+u...@googlegroups.com.