Angular v4: Do we store data in a Service or the Component or both?

Question

Angular v4: Do we store data in a Service or the Component or both?

After reviewing quite a few tutorials, as well as reading the documentation of Angular, I'm still not clear on this subject.

https://angular.io/tutorial/toh-pt2 Angular's tutorial clearly shows data stored in the Component.

https://angular.io/guide/architecture#services Angular's Architecture > Services section shows code with the service having an array of data (is this proper?).

If we store data in Components, we would heavily used @Input and @Output to move data between child components (assuming we want this data in the front end), however this poses a problem when we use routing, we would need our new Component which loaded from the router-outlet to make a new call to our service for a promise to make the API call to our server to hold data. Possibly in this case we would have 2 components holding the same data - however they may not match.

If we store data in a Service, we would heavily use our Services to retrieve data, and manipulate data (assuming we want this data in the front end) this way our service holds 1 set of data, and each component may call on the service data at any time to get consistent data.

--

What is the proper way of storing data? Is one of the other not advised?

Solution 1

Generally speaking, you want to store data in a service if a lot of components use the same data. That way, it makes it extremely easy to access the same data from all different parts of your app. If one component modifies the data in the service, it will be modified for all the components that use the data which is usually very helpful. However, sometimes it is unnecessary if you only need to send data from one component to another, where one is a parent of the other. In this scenario, using input/output would be advised.

If you don't need to send the specific data between various components, then storing the data in a component is perfectly acceptable! Keep in mind that it will not be accessible from other components unless you use input/output.

Solution 2

Component controllers should only manage UI interactions for that specific component.

Services, in the other hand, manage interactions between components, data mapping, event handling between components that don't have a direct relation (parent > child, siblings, etc.).

The idea behind this is that a service once is created it stays in the scope and doesn't get destroyed. Components in the other hand are removed from the DOM after they are destroyed. With this said, if you use your component to do, for example, API calls to gather data, this API call will be done every time the component is initialized in the lifecycle of the framework, whereas services, as already mentioned, will persist.

The persistence of services also allow us to use things like observables, to always maintain that direct line between front-end and back-end.

Hopefully this helps.

EDIT

Keep in mind that the Angular.io tutorial is separated into multiple sections to help give a complete introduction to the framework as the user follows the tutorial.

Solution 3

If multiple Components share data, put it in a service... when possible. I say when possible, because by making the service manage the data, you now have to worry about stale data. My goto data-storage location is in the Component, but you have to be careful doing this, as you don't want to cause the site to have to re-fetch data all the time.

Personally, most of my components manage their own data, in order to avoid stale-data issues.

If you are not worried about this, you could even use a caching service, that will, instead of storing the data in ram, store it in localstorage, or session storage, to make sure the site doesn't get slowed down by loads of data being put in the computers Ram.

I am by no authority an expert on this though, this is just my opinion.

Solution 4

You know @Output is related to an EventEmitter right, so data is shared between components by binding to events. Services are where you conventionally do something like a Http request - something like RESTFUL api. It could also be local storage, network connectivity, or as a bucket for storing state whilst the app runs. Components are associated in general to Views and use shadow DOM

View more solutions

Comments

[Baruch]

"If you don't need to send the specific data between various components, then storing the data in a component is perfectly acceptable!" Not according to the official style guide.

[Alex Nelson]

You still store data in a service anyways? I was taught that way through a Udemy course

[Baruch]

The official guide for Angular architecture states You define a component's application logic—what it does to support the view—inside a class. The class interacts with the view through an API of properties and methods. which means that the controller is there to manipulate UI in the component, it should only know of its data through a service or an Input.

[Speros]

This is great information, thank you both. The documentation, more specifically the tutorial on Angular does not clearly show this. So data can be stored in Services all day, and data retrieved from a Service and added to a Component is only valid as long as the data is specific to that Component's view.

[Baruch]

@Speros the tutorial does show this, just not in p2. Here: angular.io/tutorial/toh-pt4 .

[Baruch]

What do you use Services for if you manage your data in the component?

[Alex Nelson]

It just seems unnecessary to have to inject a service and reference its data when that component is the only component using the data, but I understand that using a service would follow MVC guidelines much better

[Baruch]

Why would you have a component that can only deal with one set of data? That seems counter-intuitive, components are meant to be reused.

[Speros]

@Baruch I don't see an array of heroes in the service file, am I missing something here? I believe this is why I was initially confused. I've never seen a Service file hold data from Angular official documentation, aside from the 1 link I posted above.

[Alex Nelson]

I mean not that the component can't be reused but that the data isn't being used in other components

[Baruch]

@Speros If you notice the link, the array of heroes is in a mock file that gets imported into the service. The service then has a function getHeroes that returns the array. Then the component injects the service and uses that function to set its data. Its also good to know that the data sent to the component should already be manipulated in a way that the component can understand.

[Baruch]

@AlexNelson From experience, I find it hard to believe that a real life application has data that isn't used in other components. Also, the architectural guides for any framework are there not only to help us understand the framework, but to ease the transition of other developers using/learning the same code base. And I strongly suggest you, I, and everyone to follow them.

[Adam Pine]

Services are exclusively for GET/POST/PUT actions on the data, where the component, calls the service, to GET the data, and then stores it in the component. I hesitate to make it to where everything is stored in a service, because then how does the component not then duplicate that data, so the view can use it? also, omg I can comment on my own posts!! God, not being able to comment is a real pain. after writing this, I think I am, in fact, using services to "hold" my data, I just don't cache my data in the service... and the components use the service to get the needed data.

[Adam Pine]

I also have a desire to infact cache the data in a service, eventually... I just have to get around to find the time to actually do this at some point.

[Baruch]

angular.io/guide/… that's why you use a service.

[Adam Pine]

I like all the "why?"s in that article. Make the article read a bit more demanding.

[Sergey Sklyar]

@AlexNelson can you please provide the name of this course you learned? I'm in a situation where I need to store data in service and just need a good example or course to inspire from. Thanks