Should an Angular service have state?

Question

Recently some co-workers and I were having a discussion as to whether or not AngularJS services should have state or not. We came up with some arguments for and against it and I wanted to get additional thoughts and feedback on the subject. In my searching I found this but there doesn't seem to be any clear best-practice mentioned. In the none client-side world a service should never hold state, but I am starting to think that it might be acceptable client-side because its a different problem.

Reasons for services holding state:

1. The service isn't going to be accessed by multiple threads. Each browser will have its own instance of the service.
2. Allows the service to hold the state only it cares about instead of storing it in the rootScope. encapsulates

Reasons for services to not hold state:

1. Services are no longer idempotent. Calling functions may change state and therefore may have different results when calling it based upon the state of the service.
2. I would think that overall this would be easier to test.

One way that might address #2 in the "for services holding state" section would be to have an appState object set on the rootScope that contains the current state of the application. Then all the state would be gathered in one location and then you just pull what you need out of it in your service. I found this and wondered

Answer 1

It would probably depend on what you mean by "state", but in many cases I think the answer would be yes: services should hold state.

For example, if you have a service that is responsible for communication with an API, that service could hold the authentication state.

By the way, I'm not sure how much idempotence matters for AngularJS services - they're singletons and so inherently have some state. You could (and in some cases must) create idempotent methods on the service, but that's a separate issue.

Answer 2

In AngularJS, services are passed in via factory function. And basically they are objects that can contain some state (e.g. for caching or storing data needed for performing their actions).

One good solution that can take both cons of having/not having state is when service (that could be actually function) that return object that contain state.

Take a look at the $http service: you can get instance of this service calling

var x = $http({url:'...'}); 

And then call by

var result = x.get() //actually `$http.get` is shortcut of this operation 

Same with ngResource: using service you get object with some state that can perform desired actions.

So basically I think that is the best option: from one point you avoid 'side effects' by moving state that could be modified by actions into separate object, not stored in service itself, but can have specific state in that object to be able to store custom info (like auth information etc).