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 a

Answer 1

The reason that services should not have state is that it leads to race conditions when you have multiple threads accessing the service.

A common problem with state in a service is:

1. thread 1 writes to the state
2. thread 2 writes to the state
3. thread 1 reads from the state
4. thread 2 reads from the state

Thread 1 now has the wrong value.

That being said, javascript is currently single threaded so you're not going to have thread access problems like this. However, I would be worried if I had a service where multiple asynchronous $http calls were all writing to the same service variable. If only so I could sleep better I night, I'd try to write all my service methods so they were pass-throughs for the actual data.

Instead, of maintaing the state in the service, you could consider putting the state in the backend as much as possible. Things like "authenticated" or even widths and heights could be maintained and queried for. This can open up some possibilities for allowing users to navigate away from the app, come back and find all their preferences still setup and logged in. You could store a session id in the cookie and save all this stuff on the backend.

If you did go the route of having a separate object to store state, you might be able to $emit to it from the service when something in the state has changed: how to emit events from a factory. This would have the nice side-effect of having multiple services being able to modify a unified application state because state is not being stored in any one service (or worse spread out among multiple services).