Page 58 - MSDN Magazine, July 2017

constructor
ngOnChanges ngOnInit ngDoCheck
ngAfterContentInit ngAfterContentChecked ngAfterViewInit ngAfterViewChecked
ngOnDestroy
Figure 3 Angular Lifecycle Hooks Provided by Angular Documentation
scenario because re-registering providers is typically not a good thing, but this scenario illustrates the point. If Component_A has a WidgetService injected into it, Angular first looks inside Compo- nent_A. Identifying that the WidgetService is there, Component_A will get a new instance of WidgetService every time it’s created. You could have two Component_A classes each with their own WidgetService in which those two services know nothing about each other. Moving on from there, Angular would find a Widget- Service for Component_B at Child.Module_A. This service is a singleton for all components under Child.Module_A, which do not provide their own WidgetService. Last, a WidgetService for Component_C is found at the Parent.Module. A service placed out at the Parent.Module (or AppModule) level is traditionally used as a singleton for the entire Single Page Application.
Singleton services wouldn’t be declared at the component level. Each time a component gets created AngularJS does an inside-out search for the injected services.
Component Class
As mentioned, component classes are very similar to the C# classes with which most developers are familiar. They have constructors where services can be injected, as well as parameters declared inside and outside of methods. One added benefit that Angular provides
is lifecycle hooks. Figure 3 shows a list of all the lifecycle hooks that are able to be tied into. Two of the most popular are ngOnInit and ngOnDestroy.
ngOnInit tends to be the place where initial service calls are made to obtain initial data. This hook is only called once and, more important, any @Input variables have been set at this time.
ngOnDestroy is a great place to unsubscribe from subscriptions that don’t self-terminate. If you don’t unsubscribe from these sub- scriptions, it could potentially cause memory leaks.
Template Syntax
HTML Template Syntax provides a way for components to not only affect the look and feel of its own content, but also for components to talk to each other. Following is some of the most commonly used syntax.
Interpolation uses curly braces ({{}}) to extract the content of the object property:
@Component({ template: `
<div class="row">
<div class="col-md-12 form-group">
<label>Product Name:</label>
<span class="form-control-static">{{product.name}}</span> </div>
</div> `
})
export class ProductComponent { product: Product = new Product("Computer ABC"); }
One-way binding lets you set values from a component object/ property as an attribute of an HTML element. Here, you desig- nate the value as being one way bound by enclosing that attribute with brackets ([]):
@Component({ template: `
<div class="row">
<div class="col-md-12 form-group">
<label>Product Name:</label>
<input type="text" class="form-control" disabled=""
[value]="product.name" /> </div>
</div>
export class ProductComponent { product: Product = new Product("Computer ABC"); }
Two-way binding is similar to one-way binding except that as the value of the HTML element changes, the value in the compo- nent changes, as well. In Figure 4, two-way binding by specifying (ngModel) is designated. In this case, ngModel is used because it’s an internal Angular directive for form elements. Because all (boundName) does is comb both one-way binding [] and event binding (), you can use this syntax on any element as long as it supports both the ability to have a value set on boundName and a boundNameChange event.
Figure 4 Example of Two-Way Binding
` })
@Component({ template: `
<div class="row">
<div class="col-md-12 form-group">
<label>Product Name:</label>
<input type="text" class="form-control" [(ngModel)]="product.name" /> <span class="form-control-static">{{product.name}}</span>
</div> </div>
` })
export class ProductComponent { product: Product = new Product(); }
52 msdn magazine
ASP.NET Core