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?

Answer 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.

Answer 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.

Answer 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.

Answer 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