Keep data in service, or in Pages?


#1

I know this question was already discussed here a lot. i read some opinions, which favoured storing data in Pages, and use services just as data delivery, and store no data in services themselves. Why is it better then have data stored in service, so i can easily get to them from any page, that the service is injected in?

If i save data in pages, isnt it a needless complication? For example i have three pages, that need data from one service. On each page u have to fetch data and synchronize them on each of the pages. So now its 3 copys of same data. In same case, if i have data in service, all three pages can easily access them, and only the service have to handle updates and so on. So where is the advantage of the storing data in pages? Can pls someone explain it maybe with some example? :slight_smile: Thx a lot :slight_smile:


#2

After over a year of using Ionic, and browsing this forum, I still think this is a good question! At least, the WHY of it. Many responders to this type of question answer with what is basically: “because you’re supposed to”.

Some have mentioned security issues, but nothing specific.

Separating responsibilities is another one. This makes sense to me from an organizational standpoint.

I also am still curious about the ins and outs of this.


#3

Those people are insane. Especially if you lazy load. It costs almost nothing at startup to register a provider. Register 50 providers, who cares. Then, as needed, load data into your provider (service). Keep the data there as long as you need it. You can lazily load and destroy pages, and whenever a page needs the data, it will be waiting in the provider.


#4

Basically what @AaronSterling said.

He already said some of the why, and to further it for me it’s definitely a case of separation of concerns. The page template should be for display data (and thus should have minimal logic in it), the controller should retrieve the data and pass off processing to providers, and the providers should do the heavy lifting of saving/loading/updating data from Databases, Servers, your house, the pizza place, etc.

You then gain all the benefits of not having to figure out who “owns” the data, as you know the providers do. Do you have to make sure to pass along the latest data from page to page? No, because the provider owns it so ask the provider.

Plus there’s the classic case of, oh I’ve decided to switch from using X to using Y for storing my data, now I have to update all my pages that handle this data.


#5

Ok, nice i thought majority was prefering storing data in pages and use services just as some kind of bridge between page and db. And what about accessing data in providers? Is it ok to for example access data directly from provider, so in page template i use ngfor with variable from service?


#6
*ngFor let item of items

get items(): <Array<Item>> {
    return this.nameOfService.itemList();
}

The only difference when I code is that I use the async pipe in the ngFor and an Observable in the get. That way if the service updates while the page is open, the page automatically refreshes.


#7

iam using directly

*ngFor let item of nameOfService.items

what about this?

And can u give example with Observable?


#8

I consider that bad style. The goal is to have your HTML the same no matter how you get the data. What if you change databases because one is cheaper than another, or whatever? The way you are writing it, your HTML might have to change also. Make your HTML dumb – its only job is to paint a pretty picture using data that somebody else gives it.

*ngFor let item of items | async

get items(): Observable<Array<Item>> {
   return this.nameOfService.itemList();
}

#9

seems better. And how will the service look like in this example? :slight_smile:


#10

#11

ill try to study it, but so far iam little lost. Are there any other examples in ionic? Anyways thx for answers


#12

Interesting approach. Does this not go against the grain when it comes to the practice of initializing your items
in your component as an empty something?


#13

I’m not sure I understand the question, so this might not be an answer. But I seed the Observables in providers with an initial value, either using BehaviorSubject<Type>(initialValue), or by using the Observable startWith operator. In the page, the class declares items = new Array<Item>(). So there’s always a defined value for the template to read. First it’s an array of length 0. Then, as soon as the page connects to the provider, it’s the initial value provided by the provider. Finally, it’s the value obtained by the provider from its slow operation, like an ack to its HTTP request.


#14

Ok, so you do initialize items in your constructor, and that snippet was simply not included in


#15

No, if you use a getter, you talk directly to the provider, and the startWith value from the provider is what you start with. What I wrote just now was how to handle it if items is a variable. Using a getter instead means you can skip the step of defining it in the constructor.


#16

Got it. Thanks for clarifying. I follow a similar process as far as observables in my provider, but tend to then subscribe to them in my components. Haven’t used BehaviorSubject yet. I’m using your approach using a getter at the moment and I really do like it. Seems to make for cleaner code.


#17

I agree. I saw the trick in a repo of I believe it was Rob Wormald, and I’ve been using it ever since.


#18

iam a little confused with this, arent there any simple examples in ionic- some example apps, tutorials or even simple examples? That would help me understand it more probably.
In your observable example, can u post how the service looks like? So i have complete picture :slight_smile:


#19

And maybe one more question, whats point in returning Observable, when this Observable only emits that list once and is completed? I understand it when u use Subject in Service, and make Oservable out of it, so it will keep updating, thats obvious. But in case iam only returning Observable, that emits and completes, whats the point?


#20

Observables improved on Promises, and Promises improved on callbacks. So you’d use it anywhere you’d use a JS callback. Anytime you are asking a question and the answer is not instantaneous.