Angular is a development platform for creating applications using modern web standards. Angular includes a wealth of essential features such as mobile gestures, animations, filtering, routing, data binding, security, internationalization, and beautiful UI components. It's extremely modular, lightweight, and easy to learn.

angular

**Note**: This course is still valid for Angular ^17 but the set up has changed.

Services and registering service providers are an inherent part of an Angular application. It is where you should define your application logic, they keep the state of the application and allow to share that among different components. 

That said, components can ask for instances of services by specifying them as parameters of their constructor functions which will then provided at runtime by Angular’s dependency injection mechanism. While services themselves are mostly just plain ES2015 classes, there are some interesting things to discover, especially when it comes to dependency injection. 

We can define services at various levels within our application, which allows us to control the scope and visibility of a given service. We can furthermore alias old service definitions to new, existing services which is handy for refactoring scenarios and we also have the possibility to define so-called factory functions for fully taking control of how a given service is being constructed. 

In this course we will take a closer look and walk step by step through all of these scenarios.

Hi, here's a short intro to my course about Angular Services and how they use the Dependency Injector in Angular.

The goal of this Angular Service Injection with the Dependency Injector course is to learn about the various ways Angular services can be created and provided with the dependency injector. While dependency injection has a broader range of applications, in this course we will mostly focus on the Angular services part and how they make use of DI.

That includes learning what a service is about, how it can be registered with the DI mechanism. We will learn about service aliases, value providers and factory functions. Also, understanding the lifetime of a service instance and how to control it, can be fundamental for creating some more advanced Angular apps. That's also when we learn about the hierarchical nature of Angular's DI.
Towards the end we'll take a look at what Angular provider shadowing is all about, and how it can cause some headache when not applied properly.

Enjoy the course!

Introducing Angular Service Injection with the Dependency Injector

An Angular service is a simple ES2015 class with a decorator on top. In this lesson we take a look at the anatomy of a service, what the `@Injectable` decorator is about and why and when it is actually required.

Define an Angular Service

Given that services are simple classes we could just import them in our component via normal ES2015 import statements and then instantiate them accordingly. 

However, a service might depend upon other services as well and we definitely don’t want to manually wire up the entire chain of such dependencies. That’s why we have the dependency injector in Angular which will do it for us. 

In this lesson we learn how to wire up our service properly by defining a provider that creates our service. We will also see how services defined on `NgModule` are globally visible because they are hooked up onto Angular’s root injector.

Register a Service to Angular’s Dependency Injection Mechanism

An Angular service registered on the NgModule is globally visible on the entire application. Moreover it is a singleton instance, so every component that requires it via its constructor, will get the same instance. However this is not always the desired behavior. 

Rather you may like to get a fresh instance of a given service every time a component requests it. This is especially powerful for caching scenarios for instance. In this lesson we will learn how to achieve such behavior with Angular’s hierarchical dependency injector.

Create Multiple Angular Service Instances

Aliased providers in Angular allow us to overwrite a provider with another existing provider, so basically create an alias. This is particularly useful if you either don’t have access to the provider you’re aliasing, or when you’re performing a larger refactoring and you don’t want to replace all occurrences right upfront. In this lesson we are going to look also at the key difference between aliasing a provider and simply overwriting it.

Define an Aliased Class Provider in Angular

Often it might be simply easier to create the implementation out of a simple JavaScript object rather than a full blown class. That’s where value providers come in play!





Simplify an Angular Service using a JavaScript Object as a Value Provider

Sometimes you need to have full control of how a service is instantiated at runtime. Consider for instance a logging service that gets the information of whether it is enabled or not via its constructor. Angular’s DI won’t be able to determine that value as it is something that needs to be provided explicitly. Factory providers in Angular allow to define a function which will then be called by the dependency injector to construct the given service instance.

Instantiate a Service using an Angular Factory Provider

Although you want full control over the creation of a service inside a factory function, you might still want to get further dependencies to be resolved via Angular’s dependency injector. In this lesson we learn how to pass in dependencies to a factory function.

Pass Dependencies to a Factory Provider in Angular

Angular's hierarchical dependency allows us to overwrite a global service with a different class implementation for just a given sub-tree of the entire component tree of your application. 

In this lesson we will take a look how this works, by registering the service on the component's child injector.

Overwrite a Service in a Component Subtree in Angular

As your application grows, you may have different kind of implementations of the same service structure. Take for instance a logging service with different concrete implementation flavors. Something that might immediately jump into your mind is to use an interface to abstract the concrete implementation of these specific service instances and use the interface for fetching the instance in your components. Unfortunately, TypeScript interfaces won’t work with Angular’s dependency injector. 

In this lesson we will learn why and how we can circumvent TypeScript interfaces.

Use an Abstract Class as DI Token for your Services in Angular

Very differently to AngularJS (v1.x), Angular now has a hierarchical dependency injector. That allows to specify service definitions as well as the [service lifetime](https://egghead.io/lessons/angular-overwrite-a-service-in-a-component-subtree-in-angular) at various levels in our application. Whenever a service is requested, Angular will walk up the component tree and search for a matching definition. While in most cases that's perfectly fine, often you may want to take control over the dependency lookup. In this lesson we will learn how, by applying `@Host()`, `@SkipSelf()` and `@Optional()`.

Control the dependency lookup with @Host, @SkipSelf and @Optional

Shared Angular modules may export components as well as services which are meant to be reused across the entire application. Whenever you want to use an exported component, in another module, you need to import the module defining that component accordingly. Services on the other hand are globally registered, there is one instance per dependency injector. However, there is something you should be aware of: **Lazy loaded modules have their own dependency injector.** As a result, importing shared modules in a lazy loaded module, may result in multiple instances of a service being available in the app.
In this lesson we will learn about the `ModuleWithProviders` interface that helps avoid such situations.

Avoid Multiple Service Instances in Lazy Loaded Modules in Angular

Angular's DI is quite powerful. There are however some peculiarities when it comes to the registration of Angular services with the dependency injector, in combination with lazy loaded Angular modules. The way you register the Angular service (e.g. using the `providers` array on a NgModule or the `providedIn` decorator) might have a direct impact on the instances of the service you have in memory at runtime. Let's explore that in more detail.

You can also read more details [in my blog post](https://juristr.com/blog/2021/04/angular-di-and-lazy-modules/)

Use "providedIn" service registration to avoid multiple instances with lazy loaded modules

As we've seen in my [course on Angular Service Injection with the DI](https://egghead.io/courses/angular-service-injection-with-the-dependency-injector-di) there are different ways to register a service with Angular's Dependency Injector. The major approaches (as of Angular v8+) is to either register the service on the `NgModule` `providers` array, or to directly use the `@Injectable({ providedIn: 'root' })` decorator.

In this lesson we're going to specifically look into the impact of those two methods to the final bundle size

More details can also be read [in one of my recent blog posts](https://juristr.com/blog/2021/04/angular-di-and-lazy-modules/)

Angular Service Injection with the Dependency Injector (DI)

Juri Strumpflohner

Course Content