The Brief Specifics About Angular Compiler

As the name suggests, Angular Compiler can be an advanced tool that compiles both the Angular applications and libraries. It is also famous as ngc amongst the coders. Built on the TypeScript Compiler (tsc), the Angular Compiler transcends the TypeScript compilation process to include supplemental code generation pertaining to Angular's functionalities.

The Angular Compiler acts as a link between both developer expertise and run-time achievement: Angular developers create applications using an intuitive, decorator-based API, and ngc converts this code further into effective executable commands.

Angular Compiler: Two Ways to Nail It!

Just In Time (JIT) Compiler: Just in time compilers offer compilation all through program execution at run time prior to actual execution. Put simply, code is compiled only when it is required, rather than at build time.

Ahead Of Time (AOT) Compiler: The Ahead of Time compiler transforms your code under the build time before your browser downloads and runs it when you serve/create your own angular app.

The Ideal Illustration: Before & After Of Angular Compilation

For instance, a standard Angular compilation might seem like this one -

import {Component} from '@angular/core';

@Component({
  selector: 'app-cmp',
  template: '<span>Your name is {{name}}</span>',
})
export class AppCmp {
  name = 'Alex';
}

Now, below is the image as to how the component seems post the compilation -

import { Component } from '@angular/core';                                      
import * as i0 from "@angular/core";

export class AppCmp {
    constructor() {
        this.name = 'Alex';
    }
}                                                                               
AppCmp.ɵfac = function AppCmp_Factory(t) { return new (t || AppCmp)(); };
AppCmp.ɵcmp = i0.ɵɵdefineComponent({
  type: AppCmp,
  selectors: [["app-cmp"]],
  decls: 2,
  vars: 1,
  template: function AppCmp_Template(rf, ctx) {
    if (rf & 1) {
      i0.ɵɵelementStart(0, "span");
      i0.ɵɵtext(1);
      i0.ɵɵelementEnd();
    }
    if (rf & 2) {
      i0.ɵɵadvance(1);
      i0.ɵɵtextInterpolate1("Your name is ", ctx.name, "");
    }
  },
  encapsulation: 2
});                                                   
(function () { (typeof ngDevMode === "undefined" || ngDevMode) && i0.ɵsetClassMetadata(AppCmp, [{
        type: Component,
        args: [{
                selector: 'app-cmp',
                template: '<span>Your name is {{name}}</span>',
            }]
    }], null, null); })();

The Insights Derived From Image 1 and Image 2:

• There are various static properties such as ɵfac and ɵcmpthat replaces the @Component decorator.
• This substitute introduces the component to the Angular runtime as well as implements change detection as well as template rendering.
• Resultantly, ngc can be thought of as an extended TypeScript compiler. It not only understands how to "execute" Angular decorators, but also helps them implement their impacts to the decorated classes at build time rather than run time

What Lies At The Heart of ngc?

ngc has had several key objectives that are as follows -

• Whenever the developer makes changes, recompile rapidly.
• TypeScript's type-checking norms should be applied to component templates.
• Angular decorators, together with components and templates, must be compiled.

Let's take a look at how ngc handles each of the aforementioned objectives.

Incrementality

As a result, both graphs collaborate that can provide quick iterative compilation. The import graph is employed to ascertain which analyses must be rerun, and the semantic graph is utilized to comprehend how adjustments in analysis data continue to spread throughout the program and necessitate recompilation of outcomes.

As a result, the compiler can respond to shifts in inputs quickly and do a minimal amount of work to upgrade its outputs accurately.

Being Fast Incrementally

While the rationale in TypeScript and Angular is proficient, it may still consider taking several seconds to carry out all of the parsing, analyzation, and synthesizing necessary to generate JavaScript output for the input program. Resultantly , both TypeScript and Angular endorse a gradual compilation mode, in which previously performed work is used again to more productively upgrade a compiled program when a minor modification is made in the input.

The biggest concern with incremental compilation is that, when a particular transformation in an input stream, the compiler must ascertain which deliverables have altered and which are secure to repurpose. If the compiler is unable to verify that an outcome has not transformed, it must err on the side of recompiling it.

The Angular compiler has mainly two techniques for tackling this issue: the semantic dependency graph and the import graph

Graph Import:

The compiler creates a graph of crucial imports among files whilst also conducting partial assessment activities on the program for the initial period. Whenever something varies, the compiler is capable of recognizing the dependencies among files.

For instance, if the file my.component.ts contains a component whose selector is described by a continuous imported from selector.ts, the import graph indicates that my.component.ts is dependent on selector.ts. If selector.ts alters, the compiler can refer to this graph to determine that my.component.ts's results of the analysis are no longer accurate and ought to be re-run. The import graph is useful for determining whatever may transform, but it has two massive flaws:

• It is oversensitive to apparently irrelevant modifications. If selector.ts is changed but still only adds a remark, my.component.ts does not need to be recompiled.
• Imports are not used to articulate all dependencies in Angular applications. If the selector of MyCmp changes, other components that use MyCmp in their template may be impacted, sometimes if they never straightforwardly import MyCmp.

Semantic Dependency Graph:

The semantic dependency chart continues where the import graph ends. This diagram depicts the real semantics of compilation that depicts the way the components and directives interact with one another. Its task is to identify which semantic modifications necessitate the reproduction of a given level of output.

For instance, if selector.ts is altered however and MyCmp's selector remains unchanged, the semantic dep graph will recognize that there is nothing semantically affecting MyCmp has changed and MyCmp's previous output can be used again. If the selector changes, the collection of components/directives employed by other components may transform, and the semantic graph will be aware that those components must be re-compiled.

Flow of Compilation

The prime objective of ngc is to compile TypeScript code whilst also converting recognised Angular decorated classes into more effective run-time depictions. The primary flow of Angular compilation is as specified below -

• Inspect each project file for decorated classes and construct a model of which components, directives, pipes, NgModules, and others must be compiled.
• TypeScript can be used to type-check expressions when it comes to component templates.
• Compile the entire program, such as extra Angular code for each decorated class.
• Build a TypeScript compiler example that includes some Angular capabilities.
• Make links among the decorated classes

Step 1: Make a TypeScript programme

A ts.Program instance represents a program to be compiled in TypeScript's compiler. This example manages to combine the number of files to be compiled, dependency type information, and the specific set of compiler alternatives to be employed.

It is difficult to identify the collection of files and interdependencies. Frequently, the user specifies a single "entry point" file (for instance, main.ts), and TypeScript should examine the imports within this file to determine which other files should be compiled. These files have had more imports, which develop to include even so many files, and etc.

A number of these imports seem to be dependencies: citations to code that isn't compiled but is employed in many such way and must be recognised to TypeScript's type system. These dependency imports are to .d.ts files, that are typically found in node modules.

The Angular compiler has to do something unusual at this point: it brings extra input files to the ts.Program. ngc keeps adding a "shadow" file with the.ngtypecheck suffix to each and every file published by the user (for example, my.component.ts) (e.g., my.component.ngtypecheck.ts). Internally, these files could be used for template type-checking.

ngc could add both these files to the ts.Program, such as.ngfactory files, based on compiler options, for retrograde suitability with the prior View Engine architectural style.

Step 2: Individual Evaluation

ngc searches for classes with Angular decorators and tries to statistically comprehend each decorator during the compilation phase. If it confronts a @Component decorated class, for instance, it examines the decorator and tries to ascertain the component's framework, selector, view encapsulation settings, and any additional data about the component that may be required to start generating code for it.

This necessitates that the compiler be capable of partial evaluation: reading expressions from decorator metadata and trying to perceive those expressions without simply running them.

Evaluation in Part

In an Angular decorator, data is sometimes hidden behind an expression. A component selector, for instance, is specified as a literal string, it may also be a perpetual:

const MY_SELECTOR = 'my-cmp';

@Component({
  selector: MY_SELECTOR,
  template: '...',
})
export class MyCmp {}

ngc navigates code using TypeScript APIs to assess the expression MY SELECTOR, trying to trace it back to its declaration and ultimately trying to resolve it to the string'my-cmp'.

Simple constants, object and array literals, property accesses, imports/exports, arithmetic and other binary operational processes, and sometimes even starts calling to simple functions can be understood by the partial evaluator. This feature allows Angular developers to be more flexible when describing components and other Angular types to the compiler.

Analysis Results

The compiler has a great suggestion of what components, directives, pipes, injectables, and NgModules are in the input program by the finish of the analysis stage. For every one of these, the compiler creates a "metadata" object that describes everything that it discovered from the decorators of the category.

By this juncture, components' templates and stylesheets have been loaded from disc (if required), and the compiler could have generated errors (known as "diagnostics" in TypeScript) if semantic mistakes have been identified in any aspect of the input thus far.

Step 3: Conduct a Global Analysis

The compiler must first understand how the various decorated types in the program relate to one another before it can type-check or generate code. The primary goal of this step is to comprehend the program's NgModule structure.

NgModules

The compiler must understand what directives, components, and pipes are employed in each component's framework in order to type-check as well as produce code. This is difficult but Angular components do not import their dependencies straightforwardly.

Angular components perhaps use HTML to define templates, and prospective dependencies are paired against elements in those templates utilizing CSS-style selectors. This allows for a potent abstraction layer: Angular components no longer ought to know how their dependencies are framed.

The Angular @NgModule abstraction resolves these iterators. NgModules can be assumed as composable layout range units. A standard NgModule could perhaps look like this:

@NgModule({
  declarations: [ImageViewerComponent, ImageResizeDirective],
  imports: [CommonModule],
  exports: [ImageViewerComponent],
})
export class ImageViewerModule {}

NgModules can be thought of as proclaiming 2 separate perspectives: A "compilation scope," or the set of prospective dependencies obtainable to any components proclaimed in the NgModule on it's own. An "export scope" is a collection of prospective dependencies that are made accessible in the compilation purview of any NgModules that import the provided NgModule.

Because ImageViewerComponent is an element defined in this NgModule, its prospective dependencies are determined by theNgModule's compilation scope. This compilation scope is the unification of all proclamations and the scope of export of any imported NgModules. Declaring a component in numerous NgModules is therefore a mistake in Angular. A component and its NgModule must both be gathered during the same time.

In this particular instance, CommonModule is imported, so the compilation scope of ImageViewerModule (and therefore ImageViewerComponent) involves all of CommonModule's directives and pipes — NgIf, NgForOf, AsyncPipe, and a few a others. These proclaimed directives — ImageViewerComponent and ImageResizeDirective — are also included in the compilation purview.

.d.ts metadata

The Angular compiler must completely recognize the compilation scope of NgModules proclaimed in the compilation during the worldwide analysis stage. These NgModules, even so, may import other NgModules outside of compilation, such as libraries as well as other constraints. TypeScript understands types from such dependencies via declaration files with the .d.ts extension. These .d.ts proclamations are used by the Angular compiler to transfer along data about Angular aspects within those dependencies.

The ImageViewerModule above, for instance, imports CommonModule from the @angular/common package. An incomplete assessment of the imports list will help solve the categories titled “ in imports to proclamations within the dependencies' .d.ts files.

Recognizing only the mark of imported NgModules is insufficient. To construct its graph, the compiler uses a special metadata type to share data regarding NgModule declarations, imports, and exports via the.d.ts files. This (streamlined) metadata, for instance, appears in the produced declaration file for Angular's CommonModule:

export declare class CommonModule {
  static mod: ng.NgModuleDeclaration<CommonModule, [typeof NgClass, typeof NgComponentOutlet, typeof NgForOf, typeof NgIf, typeof NgTemplateOutlet, typeof NgStyle, typeof NgSwitch, typeof NgSwitchCase, typeof NgSwitchDefault, typeof AsyncPipe, ...]>;
  // … 
}

This type declaration is not meant for TypeScript type-checking; rather, it integrates relevant data (citations and other meta-data) about Angular's comprehension of the class in an inquiry into the type system.

ngc can ascertain the export context of CommonModule based on these special types. It can generate valuable metadata about the mandates themselves by using TypeScript's APIs to settle the citations within this metadata to those class definitions:

export declare class NgIf<T> {
  // …
  static dir: ng.DirectiveDeclaration<NgIf<any>, "[ngIf]", never, { "ngIf": "ngIf"; "ngIfThen": "ngIfThen"; "ngIfElse": "ngIfElse"; }, {}, never>;
}

This provides ngc with enough data about the system's structure to begin compilation.

Step 4: Type-Checking Template

ngc can detect and notify type errors in Angular templates. For instance, if a template strives to attach the value name.first but the name object doesn't have a first property, ngc may report this as a type error. ngc confronts a major dilemma in proficiently conducting this verification.

TypeScript does not comprehend Angular template syntax and therefore cannot type-check it straightforwardly. The Angular compiler translates Angular templates into TypeScript code (known as a "Type Check Block," or TCB) that conveys similar operational processes at the type level, and then continues to feed this code to TypeScript for semantic verification. Any produced diagnostics are then plotted to the initial template and disclosed to the user.

Take into account a component with a framework that employs ngFor:

<span *ngFor="let user of users">{{user.name}}</span>

The compiler tries to ensure that theuser.name property connectivity is legal for this template. To do so, it needs to first comprehend how the category of the loop variable user is inferred from the input vector of users via the NgFor.

The Type Check Block generated by the compiler for this component's template ends up looking like this:

import * as i0 from './test';
import * as i1 from '@angular/common';
import * as i2 from '@angular/core';

const _ctor1: <T = any, U extends i2.NgIterable<T> = any>(init: Pick<i1.NgForOf<T, U>, "ngForOf" | "ngForTrackBy" | "ngForTemplate">) => i1.NgForOf<T, U> = null!;

/*tcb1*/
function _tcb1(ctx: i0.TestCmp) { if (true) {
    var _t1 /*T:DIR*/ /*165,197*/ = _ctor1({ "ngForOf": (((ctx).users /*190,195*/) /*190,195*/) /*187,195*/, "ngForTrackBy": null as any, "ngForTemplate": null as any }) /*D:ignore*/;
    _t1.ngForOf /*187,189*/ = (((ctx).users /*190,195*/) /*190,195*/) /*187,195*/;
    var _t2: any = null!;
    if (i1.NgForOf.ngTemplateContextGuard(_t1, _t2) /*165,216*/) {
        var _t3 /*182,186*/ = _t2.$implicit /*178,187*/;
        "" + (((_t3 /*199,203*/).name /*204,208*/) /*199,208*/);
    }
} }

• The complexity appears to be considerable in this, however this TCB is profoundly conducting a particular sequence of tasks.
• First, it deduces the NgForOf directive's actual type (which is general in nature) out of its input bindings. This is known as _t1.
• It authenticates that the component's user property is attributable to the NgForOf input using the assignment remark _t1.
• ngForOf(ctx.users) = ctx.users
• Having followed that, it proclaims a type named_t2 for the integrated view context of the ngFor row template, with a preliminary type of any.
• Utilizing such a type guard call, it narrows the type of _t2 based on the way NgForOf works by calling NgForOf 's ngTemplateContextGuard helper function.
• This scope is used to extract the implied loop variable (user in the template) and start giving it the name_t3
• Eventually, the _t3.name connectivity is specified.

If the access _t3.name is not permitted by TypeScript's norms, TypeScript will generate a diagnostic error. Before displaying the fault to the programmer, Angular's template type-checker could indeed examine the destination of the discrepancy in the TCB and utilize the embedded comments to plot the mistake onto the original template.

Angular templates have kinds from the user's program because they comprise citations to component class properties. As a result, template type-checking code could only be inspected individually, but must be reviewed in the context of the user's entire program (in the preceding example, the component type is sourced from the user's test.ts file).

ngc achieves this by incorporating the produced TCBs into the user's program via a TypeScript incremental build phase (generating a new ts.Program). Type-checking code is incorporated to separate .ngtypecheck.ts files that the compiler tends to add to the ts.Program on formation instead of going straight to user files to prevent whipping the incremental build cache.

Step 5: Expel

When this stage commences, ngc has both comprehended the program and affirmed that no potentially lethal discrepancies exist. The compiler of TypeScript is then instructed to produce JavaScript code for the program. Angular decorators are removed even during the generation stage, as well as several rigid fields are introduced to the classes conversely, with the produced Angular code prepared to be authored out in JavaScript.

If the program being gathered is a library, .d.ts files are generated as well. The file includes Angular metadata embedded in them that identifies how a potential compilation may use these kinds as dependencies.

Synopsis

To produce an appropriate and highly functional compilation of Angularlayouts and classes, Angular's compiler aims to leverage the versatility of TypeScript's compiler APIs. Assembling Angular apps enables us to provide a favorable developer experience in the IDE, provide build-time responses on code issues, and reshape that code into the most effective JavaScript to operate in the web page during the build phase.