CODEWITHSUNDEEP
angularproperty-binding
Brian
Brian

Reputation: 730

Angular performance using a service or properties and events

The docs mention several ways for components to interact:

https://angular.io/guide/component-interaction

Is there a performance benefit to using services instead of properties/events, or the other way around?

I'm still new to Angular and have been using services to share data between components, but I feel like that "globalizes" the data, such that any component can read or write to the service, if it allows. I'm considering switching to properties/events as a way to enforce data scope, and attempting to limit services for globally used data (like logs, or other data that really needs universal access).

Is there a memory <-> cpu trade-off to make there?

Upvotes: 1

Views: 759

Answers (2)

kha
kha

Reputation: 20023

Generally speaking and in principle, the two serve different purposes.

You use a service when you need to "do something" such as communicating with a REST API, cache data or anything else that can come under a serviceable interface, can be reused and is bound to the lifetime of the application.

An event on the other hand is meant to "respond" to things. For instance, when a click event happens, a callback needs to be fired and handled and its lifetime is not tied to the lifetime of the application but rather to the lifetime of the event and its callback.

Of course, there's no reason why you can't mix the two (having EventEmitter<>/RX observer inside a service for instance is perfectly fine if your service is "reactive"; for instance, when it's listening to a websocket connection and needs to notify 1-N subscribers) but the general design principle should be to use service/events where they make sense.

Additionally, as you mentioned, services are global (within context/module) whereas events and properties are generally localised. For this reason, it's best to use services where global interaction makes sense (shared infrastructure for instance) and use events/properties where it should be localised.

What I suggest:

Use services where you need to perform caching, you need to perform external communications (websocket/webapi) or when you need to share common functionality between multiple components/services/layers.

Use events and properties where the sole intention is to share data between 2 (or more if chained) components since they're generally cleaner for this purpose (the interface of the component will dictate exactly what it inputs and what it outputs).

What you want to avoid is to create too many "services" which only act as a gateway of communication between your components where events/properties (input and output) make more sense.

Upvotes: 1

IAfanasov
IAfanasov

Reputation: 4993

Any service could also be scoped to a module. providedIn property of @Injectable() directive manages the scope of the service.

You get it absolutely right about the memory implications of the service as data storage. If the app has really a lot of data, it could be noticeable. For most, I would say almost all, apps there is not a significant amount of data. The user would not notice a difference between global service or component properties.

As for CPU, I don't any reason that would differentiate CPU usage in both scenarios. Only the implementation of the data store would affect the CPU usage. No matter where this store is.

Upvotes: 0

Related Questions