Preparing the Example Project

As with the other chapters in this part of the book, I am going to continue working with the project created in Chapter 11 and most recently modified in Chapter 19. To prepare for this chapter, I added a file called log.service.ts to the src/app folder and used it to define the service shown in Listing 20-1.

This service writes out log messages, with differing levels of severity, to the browser’s JavaScript console. I will register and use this service later in the chapter.

Open a new browser window and navigate to http://localhost:4200 to see the application, as shown in Figure 20-1.

Using Service Providers

The changes in Listing 20-2 prevent the application from running. Angular processes the HTML document and starts creating the hierarchy of components, each with their templates that require directives and data bindings, and it encounters the classes that depend on the DiscountService class. But it can’t create an instance of DiscountService because its constructor requires a LogService object and it doesn’t know how to handle this class.

Angular delegates responsibility for creating the objects needed for dependency injection to providers, each of which managed a single type of dependency. When it needs to create an instance of the DiscountService class, it looks for a suitable provider to resolve the LogService dependency. Since there is no such provider, Angular can’t create the objects it needs to start the application and reports the error.

You might wonder why the configuration step in Listing 20-3 is required. After all, Angular could just assume that it should create a new LogService object the first time it needs one.

Using Local Providers

When Angular creates a new instance of a class, it resolves any dependencies using an injector. It is an injector that is responsible for inspecting the constructors of classes to determine what dependencies have been declared and resolving them using the available providers.

So far, all of the dependency injection examples have relied on providers configured in the application’s Angular module. But the Angular dependency injection system is more complex: there is a hierarchy of injectors that corresponds to the application’s tree of components and directives. Each component and directive can have its own injector, and each injector can be configured with its own set of providers, known as local providers.

When there is a dependency to resolve, Angular uses the injector for the nearest component or directive. The injector first tries to resolve the dependency using its own set of local providers. If no local providers have been set up or there are no providers that can be used to resolve this specific dependency, then the injector consults the parent component’s injector. The process is repeated—the parent component’s injector tries to resolve the dependency using its own set of local providers. If a suitable provider is available, then it is used to provide the service object required to resolve the dependency. If there is no suitable provider, then the request is passed up to the next level in the hierarchy, to the grandparent of the original injector. At the top of the hierarchy is the root Angular module, whose providers are the last resort before reporting an error.

Defining providers in the Angular module means that all dependencies for a token within the application will be resolved using the same object. As I explain in the following sections, registering providers further down the injector hierarchy can change this behavior and alter the way that services are created and used.

Creating Local Providers in a Component

Components can define local providers, which allow separate servers to be created and used by part of the application. Components support two decorator properties for creating local providers, as described in Table 20-8.

Table 20-8

The Component Decorator Properties for Local Providers

Name	Description
providers	This property is used to create a provider used to resolve dependencies of view and content children.
viewProviders	This property is used to create a provider used to resolve dependencies of view children.

The simplest way to address my LogService issue is to use the providers property to set up a local provider, as shown in Listing 20-22.

import { Component, Input } from "@angular/core";

import { Model } from "./repository.model";

import { Product } from "./product.model";

import { DiscountService } from "./discount.service";

import { LogService } from "./log.service";

@Component({

  selector: "paProductTable",

  templateUrl: "productTable.component.html",

  providers:[LogService]

})

export class ProductTableComponent {

  constructor(private dataModel: Model) { }

  getProduct(key: number): Product {

    return this.dataModel.getProduct(key);

  }

  getProducts(): Product[] {

    return this.dataModel.getProducts();

  }

  deleteProduct(key: number) {

    this.dataModel.deleteProduct(key);

  }

  dateObject: Date = new Date(2020, 1, 20);

  dateString: string = "2020-02-20T00:00:00.000Z";

  dateNumber: number = 1582156800000;

}

Listing 20-22

Creating a Local Provider in the productTable.component.ts File in the src/app Folder

When Angular needs to create a new pipe object, it detects the dependency on LogService and starts working its way up the application hierarchy, examining each component it finds to determine whether they have a provider that can be used to resolve the dependency. The ProductTableComponent does have a LogService provider, which is used to create the service used to resolve the pipe’s dependency. This means there are now two LogService objects in the application, each of which can be configured separately, as shown in Figure 20-2.

The LogService object created by the component’s provider uses the default value for its minimumLevel property and will display LogLevel.INFO messages. The LogService object created by the module, which will be used to resolve all other dependencies in the application, including the one declared by the DiscountService class, is configured so that it will display only LogLevel.ERROR messages. When you save the changes, you will see the logging messages from the pipe (which receives the service from the component) but not from DiscountService (which receives the service from the module).

Understanding the Provider Alternatives

As described in Table 20-8, there are two properties that can be used to create local providers. To demonstrate how these properties differ, I added a file called valueDisplay.directive.ts to the src/app folder and used it to define the directive shown in Listing 20-23.

import { Directive, InjectionToken, Inject, HostBinding} from "@angular/core";

export const VALUE_SERVICE = new InjectionToken("value_service");

@Directive({

    selector: "[paDisplayValue]"

})

export class PaDisplayValueDirective {

    constructor( @Inject(VALUE_SERVICE) serviceValue: string) {

        this.elementContent = serviceValue;

    }

    @HostBinding("textContent")

    elementContent: string;

}

Listing 20-23

The Contents of the valueDisplay.directive.ts File in the src/app Folder

The VALUE_SERVICE opaque token will be used to define a value-based service, on which the directive in this listing declares a dependency so that it can be displayed in the host element’s content. Listing 20-24 shows the service being defined and the directive being registered in the Angular module. I have also simplified the LogService provider in the module for brevity.

import { NgModule } from "@angular/core";

import { BrowserModule } from "@angular/platform-browser";

import { ProductComponent } from "./component";

import { FormsModule, ReactiveFormsModule  } from "@angular/forms";

import { PaAttrDirective } from "./attr.directive";

import { PaModel } from "./twoway.directive";

import { PaStructureDirective } from "./structure.directive";

import { PaIteratorDirective } from "./iterator.directive";

import { PaCellColor } from "./cellColor.directive";

import { PaCellColorSwitcher } from "./cellColorSwitcher.directive";

import { ProductTableComponent } from "./productTable.component";

import { ProductFormComponent } from "./productForm.component";

import { PaAddTaxPipe } from "./addTax.pipe";

import { PaCategoryFilterPipe } from "./categoryFilter.pipe";

import { PaDiscountDisplayComponent } from "./discountDisplay.component";

import { PaDiscountEditorComponent } from "./discountEditor.component";

import { DiscountService } from "./discount.service";

import { PaDiscountPipe } from "./discount.pipe";

import { PaDiscountAmountDirective } from "./discountAmount.directive";

import { SimpleDataSource } from "./datasource.model";

import { Model } from "./repository.model";

import { LogService, LOG_SERVICE, SpecialLogService,

    LogLevel, LOG_LEVEL} from "./log.service";

import { VALUE_SERVICE, PaDisplayValueDirective} from "./valueDisplay.directive";

@NgModule({

    imports: [BrowserModule, FormsModule, ReactiveFormsModule],

    declarations: [ProductComponent, PaAttrDirective, PaModel,

        PaStructureDirective, PaIteratorDirective,

        PaCellColor, PaCellColorSwitcher, ProductTableComponent,

        ProductFormComponent, PaAddTaxPipe, PaCategoryFilterPipe,

        PaDiscountDisplayComponent, PaDiscountEditorComponent,

        PaDiscountPipe, PaDiscountAmountDirective, PaDisplayValueDirective],

    providers: [DiscountService, SimpleDataSource, Model, LogService,

                { provide: VALUE_SERVICE, useValue: "Apples" }],

    bootstrap: [ProductComponent]

})

export class AppModule { }

Listing 20-24

Registering the Directive and Service in the app.module.ts File in the src/app Folder

The provider sets up a value of Apples for the VALUE_SERVICE service. The next step is to apply the new directive so there is an instance that is a view child of a component and another that is a content child. Listing 20-25 sets up the content child instance.

<div class="row m-2">

  <div class="col-4 p-2">

    <paProductForm>

      <span paDisplayValue></span>

    </paProductForm>

  </div>

  <div class="col-8 p-2">

    <paProductTable></paProductTable>

  </div>

</div>

Listing 20-25

Applying a Content Child Directive in the template.html File in the src/app Folder

Listing 20-26 projects the host element’s content and adds a view child instance of the new directive.

<form novalidate [formGroup]="form" (ngSubmit)="submitForm(form)">

    <div class="form-group" *ngFor="let control of form.productControls">

        <label>{{control.label}}</label>

        <input class="form-control"

            [(ngModel)]="newProduct[control.modelProperty]"

            name="{{control.modelProperty}}"

            formControlName="{{control.modelProperty}}" />

        <ul class="text-danger list-unstyled"

                *ngIf="(formSubmitted || control.dirty) && !control.valid">

            <li *ngFor="let error of control.getValidationMessages()">

                {{error}}

            </li>

        </ul>

    </div>

    <button class="btn btn-primary" type="submit"

        [disabled]="formSubmitted && !form.valid"

        [class.btn-secondary]="formSubmitted && !form.valid">

            Create

    </button>

</form>

<div class="bg-info text-white m-2 p-2">

    View Child Value: <span paDisplayValue></span>

</div>

<div class="bg-info text-white m-2 p-2">

    Content Child Value: <ng-content></ng-content>

</div>

Listing 20-26

Adding Directives in the productForm.component.html File in the src/app Folder

When you save the changes, you will see the new elements, as shown in Figure 20-3, both of which show the same value because the only provider for VALUE_SERVICE is defined in the module.

Creating a Local Provider for All Children

The @Component decorator’s providers property is used to define providers that will be used to resolve service dependencies for all children, regardless of whether they are defined in the template (view children) or projected from the host element (content children). Listing 20-27 defines a VALUE_SERVICE provider in the parent component for two new directive instances.

import { Component, Output, EventEmitter, ViewEncapsulation } from "@angular/core";

import { Product } from "./product.model";

import { ProductFormGroup } from "./form.model";

import { Model } from "./repository.model";

import { VALUE_SERVICE } from "./valueDisplay.directive";

@Component({

    selector: "paProductForm",

    templateUrl: "productForm.component.html",

    providers: [{ provide: VALUE_SERVICE, useValue: "Oranges" }]

})

export class ProductFormComponent {

    form: ProductFormGroup = new ProductFormGroup();

    newProduct: Product = new Product();

    formSubmitted: boolean = false;

    constructor(private model: Model) { }

    submitForm(form: any) {

        this.formSubmitted = true;

        if (form.valid) {

            this.model.saveProduct(this.newProduct);

            this.newProduct = new Product();

            this.form.reset();

            this.formSubmitted = false;

        }

    }

}

Listing 20-27

Defining a Provider in the productForm.component.ts File in the src/app Folder

The new provider changes the service value. When Angular comes to create the instances of the new directive, it begins its search for providers by working its way up the application hierarchy and finds the VALUE_SERVICE provider defined in Listing 20-27. The service value is used by both instances of the directive, as shown in Figure 20-4.

Creating a Provider for View Children

The viewProviders property defines providers that are used to resolve dependencies for view children but not content children. Listing 20-28 uses the viewProviders property to define a provider for VALUE_SERVICE.

import { Component, Output, EventEmitter, ViewEncapsulation } from "@angular/core";

import { Product } from "./product.model";

import { ProductFormGroup } from "./form.model";

import { Model } from "./repository.model";

import { VALUE_SERVICE } from "./valueDisplay.directive";

@Component({

    selector: "paProductForm",

    templateUrl: "productForm.component.html",

    viewProviders: [{ provide: VALUE_SERVICE, useValue: "Oranges" }]

})

export class ProductFormComponent {

    // ...methods and properties omitted for brevity...

}

Listing 20-28

Defining a View Child Provider in the productForm.component.ts File in the src/app Folder

Angular uses the provider when resolving dependencies for view children but not for content children. This means dependencies for content children are referred up the application’s hierarchy as though the component had not defined a provider. In the example, this means that the view child will receive the service created by the component’s provider, and the content child will receive the service created by the module’s provider, as shown in Figure 20-5.

Caution

Defining providers for the same service using both the providers and viewProviders properties is not supported. If you do this, the view and content children both will receive the service created by the viewProviders provider.

Controlling Dependency Resolution

Angular provides three decorators that can be used to provide instructions about how a dependency is resolved. These decorators are described in Table 20-9 and demonstrated in the following sections.

Table 20-9

The Dependency Resolution Decorators

Name	Description
@Host	This decorator restricts the search for a provider to the nearest component.
@Optional	This decorator stops Angular from reporting an error if the dependency cannot be resolved.
@SkipSelf	This decorator excludes the providers defined by the component/directive whose dependency is being resolved.

Restricting the Provider Search

The @Host decorator restricts the search for a suitable provider so that it stops once the closest component has been reached. The decorator is typically combined with @Optional, which prevents Angular from throwing an exception if a service dependency cannot be resolved. Listing 20-29 shows the addition of both decorators to the directive in the example.

import { Directive, InjectionToken, Inject,

         HostBinding, Host, Optional} from "@angular/core";

export const VALUE_SERVICE = new InjectionToken("value_service");

@Directive({

    selector: "[paDisplayValue]"

})

export class PaDisplayValueDirective {

    constructor( @Inject(VALUE_SERVICE) @Host() @Optional() serviceValue: string) {

        this.elementContent = serviceValue || "No Value";

    }

    @HostBinding("textContent")

    elementContent: string;

}

Listing 20-29

Adding Dependency Decorators in the valueDisplay.directive.ts File in the src/app Folder

When using the @Optional decorator, you must ensure that the class is able to function if the service cannot be resolved, in which case the constructor argument for the service is undefined. The nearest component defines a service for its view children but not content children, which means that one instance of the directive will receive a service object and the other will not, as illustrated in Figure 20-6.

Skipping Self-Defined Providers

By default, the providers defined by a component are used to resolve its dependencies. The @SkipSelf decorator can be applied to constructor arguments to tell Angular to ignore the local providers and start the search at the next level in the application hierarchy, which means that the local providers will be used only to resolve dependencies for children. In Listing 20-30, I have added a dependency on the VALUE_SERVICE provider that is decorated with @SkipSelf.

import { Component, Output, EventEmitter, ViewEncapsulation,

         Inject, SkipSelf } from "@angular/core";

import { Product } from "./product.model";

import { ProductFormGroup } from "./form.model";

import { Model } from "./repository.model";

import { VALUE_SERVICE } from "./valueDisplay.directive";

@Component({

    selector: "paProductForm",

    templateUrl: "productForm.component.html",

    viewProviders: [{ provide: VALUE_SERVICE, useValue: "Oranges" }]

})

export class ProductFormComponent {

    form: ProductFormGroup = new ProductFormGroup();

    newProduct: Product = new Product();

    formSubmitted: boolean = false;

    constructor(private model: Model,

            @Inject(VALUE_SERVICE) @SkipSelf() private serviceValue: string) {

        console.log("Service Value: " + serviceValue);

    }

    submitForm(form: any) {

        this.formSubmitted = true;

        if (form.valid) {

            this.model.saveProduct(this.newProduct);

            this.newProduct = new Product();

            this.form.reset();

            this.formSubmitted = false;

        }

    }

}

Listing 20-30

Skipping Local Providers in the productForm.component.ts File in the src/app Folder

When you save the changes and the browser reloads the page, you will see the following message in the browser’s JavaScript console, showing that the service value defined locally (Oranges) has been skipped and allowing the dependency to be resolved by the Angular module:

Service Value: Apples

Summary

In this chapter, I explained the role that providers play in dependency injection and explained how they can be used to change how services are used to resolve dependencies. I described the different types of provider that can be used to create service objects and demonstrated how directives and components can define their own providers to resolve their own dependencies and those of their children. In the next chapter, I describe modules, which are the final building block for Angular applications.