0

Suppose I have a users service that calls an external API

In order to avoid calling this API twice (e.g. once for parent page, and then again for any child elements that need it).

would it be OK to store data within the service?

e.g. myService.userName, myService.userID, etc.

I've read that it's bad practice to store data in services; this is why I'm asking

Note: I do not need the data persist. It should refresh upon page load.

Alvaro Silvino
  • 9,441
  • 12
  • 52
  • 80
Ricky
  • 2,850
  • 5
  • 28
  • 41
  • 3
    Its not bad practice. Its generally a good habit to store data on service to access data across different controllers. – Rahil Wazir Sep 30 '15 at 17:13
  • Use a provider: https://docs.angularjs.org/guide/providers – Hieu Le Sep 30 '15 at 17:15
  • Thanks @RahilWazir: Will the data to erase upon each page load? This is essentially what I want – Ricky Sep 30 '15 at 17:17
  • 1
    Yes, the data gets erased on page load ... You're reloading the page :) - unless you cached it in localStorage. – sirrocco Sep 30 '15 at 17:21
  • 1
    javascript doesn't persist between page loads .. angular is javascript – charlietfl Sep 30 '15 at 17:21
  • OK great, thanks guys. @HieuLe I'll check out your provider link in after this and report back. However, what is the distinction between storing the data in my service versus using a provider? – Ricky Sep 30 '15 at 17:23
  • 1
    @Ricky get used to using service before you worry about providers. Take a look, understand that they are there but for user it is unlikely you need one yet – charlietfl Sep 30 '15 at 17:30
  • OK that works, thanks @charlietfl. So for my purposes here,they are essentially the same effect. I'm curious though, how we do prevent the case where a piece of code attempts to read a property prior the original API call returning? – Ricky Sep 30 '15 at 17:32
  • no simple answer for that other than using promises and learn about `resolve` in routing – charlietfl Sep 30 '15 at 17:34

3 Answers3

1

I think caching data in a service has several advantages, you must be aware however, what is actually happening.

Here are a few facts and infos regarding services:

  • they are singletons, meaning there is only one instance in your whole application
  • a service is always there (you don't need to create it explicitly)
  • a service can cache data which can be usefull, e.g. to maintain the state of a view/page and/or to reduce the amount of requests sent to the server
  • services can be used to exchange data between different components (e.g. directives, controllers, other services, etc.)
  • services can easily be injected where ever you need them
  • services can be tested without any UI-related issues..

In certain cases you might need to pay attention tough:

  • if different components share and modify the same service, they might "mess" up each others data - this can be desired, but might also have some side-effects
  • services obviously only cache as long as the application "lives", i.e. if the user reloads or revisits the page, the data/state is lost. If you want to persist the data, you can store the service's data in the local storage for example.

I think a service is good if it has a clear, understandable API and doesn't try to do too much. And if it can be reused by several compontents, which seems to be the case with your requirements.

Please note that some of this is copied from my answer in a different post regarding services vs. directive. Maybe you can find some more info there.

Community
  • 1
  • 1
PzYon
  • 2,963
  • 3
  • 16
  • 27
0

You can cache ur data in a service... but you should do it with server & client side checks so no one will edit it and will change the info there.

whenever you get in a website, as a client, you should be answered once for a question that doesn't change a lot. for example, asking for user details should happen once if it doesn't change in the next minute.

Storing the info in a service is a common option, another option is local storage and/or cookie, which will be helpful in the next time you enter and if, again, it doesn't change a lot.

0

There's nothing wrong with caching in a service (they are singletons, and are commonly used for sharing state between controllers.) One option, if you are using $resource to access your API from your service, is to simply turn on $resource's built-in caching, like this:

var myResource = $resource(baseUrl + '/something/:id', {id: '@id'}, {
        'get': { method:'GET', cache: true},
    });
jlew
  • 10,491
  • 1
  • 35
  • 58