From what I understand, we use services in the case of inter and intra components communication where we hide multiple or complex data structures. Is it true we only use services in the case of persistent data structure? So what are cases we should not use services?
I Would beg to differ with the statement you made.
From what I understand, we use services in the case of inter and intra components communication where we hide multiple or complex data structures.
Instead of answering when we should not use angular service? I would answer what, why and when to use services?
1.To Implement any Business Logic that is independent of any Component
.
Example
Assume you want to calculate the age from DOB, Now you provide the year
and The logic can give you age you would not need an HTML view to do that
,it is component Independent
2. Access to Shared Data.
When passing data between components that lack a direct connection, such as siblings, grandchildren, etc, you should use a shared service.
You could either use RXJS BehaviorSubject or Subject for cross component communication.
The advantage of using BehaviorSubject or a Subject for cross-component interaction over plain getters and setters is you don't need to manually trigger a method to fetch latest data. Whenever the data is changed all the components where service is injected are automatically notified.
What is the difference between Subject and BehaviorSubject???
3. External Interactions
1.Accessing REST Web Services Using Http
-----------------------------------------------------------------------------------------------------------------------------------
Why use Services in Angular
Angular distinguishes components from services in order to increase modularity and reusability.
and It's Good Practice to Delegate complex component logic to services
From Angular Style Guide
Do limit logic in a component to only that required for the view. All other logic should be delegated to services.Do move reusable logic to services and keep components simple and focused on their intended purpose.
Why? Logic may be reused by multiple components when placed within a service and exposed via a function.
Why? Logic in a service can more easily be isolated in a unit test, while the calling logic in the component can be easily mocked.
Why? Removes dependencies and hides implementation details from the component.
Why? Keeps the component slim, trim, and focused.
Usage of Services In Angular also ensures that you are not violating DRY and SRP principles of software development.
Providing Services
FROM Angular Docs
Should you provide a service with an
@Injectabledecorator, in an@NgModule, or within an@Component? The choices lead to differences in the final bundle size, service scope, and service lifetime.When you register providers in the
@Injectabledecorator of the service itself, optimization tools such as those used by the CLI's production builds can perform tree shaking, which removes services that aren't used by your app. Tree shaking results in smaller bundle sizes.Angular module providers
(@NgModule.providers)are registered with the application's root injector. Angular can inject the corresponding services in any class it creates. Once created, a service instance lives for the life of the app and Angular injects this one service instance in every class that needs it.A component's providers
(@Component.providers)are registered with each component instance's own injector.Angular can only inject the corresponding services in that component instance or one of its descendant component instances. Angular cannot inject the same service instance anywhere else.
Note that a component-provided service may have a limited lifetime. Each new instance of the component gets its own instance of the service and, when the component instance is destroyed, so is that service instance
To get a Clear Picture Go through Angular's Hierarchical Dependency Injection system
Well, it's recommended to Always register application-wide services with the root AppModule which makes a service singleton(it will live as long as our application lives) but it entirely depends upon the use case.
If the sole purpose of the service is to share data between sibling components and to provide a couple of helper’s methods.Register it with component providers and make it a non-singleton service.
The benefit is that when Angular destroys the component, Angular will also destroy the service and release the memory that is occupied by it.@Credit