Transition from AngularJS to Angular: goals, plans and rules for transferring elements (1/3)

If in the module in which we start to upgrade something, there is no an angular module, then we create it and attach it to the main application module:

 import {NgModule} from "@angular/core"; @NgModule({ // }); export class SmthModule {} @NgModule({ imports: [ ... SmthModule, ], }); export class AppModule {} 

If the angularization module is still alive, then the new module is called with the postfix .new . We cut out postfix along with the old angular module.

In a good case, we add a decorator, remove the default from export, manage imports (because the default has been removed), import into the anguly module, downgrade to the anguard module:

 import {Injectable} from "@angular/core"; @Injectable() export class SmthService { ... } // angular module @NgModule({ providers: [ ... SmthService, ], }); // angularjs module import {downgradeInjectable} from "@angular/upgrade/static"; ... .factory("vim.smth", downgradeInjectable(SmthService)) 

The service remains available under the old name in Angurarzhs and does not require additional configuration.

A good option implies: all injecting services have already moved to Angulyar, no specific items like templateCache or compiler .

In the remaining 95% of cases, we suffer, first upgrading what is injected, getting rid of all sorts of weird angularies, etc.

We drop the decorator with the metadata to the controller, put the decorators into inputs / outputs and transfer them to the beginning of the class:

 import {Component, Input, Output, EventEmitter} from "@angular/core"; @Component({ //   `-`     ,   camelCase selector: "vim-smth", //       require("./smth.html") templateUrl: "smth.html", }) export class SmthComponent { @Input() smth1: string; @Output() smthAction = new EventEmitter<void>(); ... } // angular module @NgModule({ declarations: [ ... SmthComponent, ], //         ,         exports: [ ... SmthComponent, ], }); // angularjs module import {downgradeInjectable} from "@angular/upgrade/static"; ... .directive("vimSmth", downgradeComponent({ component: SmthComponent }) as ng.IDirectiveFactory) 

All injected services, all require components (how to cling them - below to Any ) and all components / directives / filters used inside the template should be on an angular basis.

All component variables used in the template must be declared as public , otherwise it will fall on the AoT assembly.

If the component receives all the data for output from the component above (via input), then feel free to write to it in the meta-data changeDetection: ChangeDetectionStrategy.OnPush . This tells the angular that it will only sync the data template (let change detection for this component) if any of the components of the component change. Ideally, most of the components should be in this mode (but we are unlikely, because very large components that receive data for output via services).

Same as the component, only there is no template and the @Directive decorator. It is thrown into the module there, it is necessary to export it for use in the components of other modules as well.

The selector in camelCase is also used in component templates.

Now it is @Pipe and must implement the PipeTransform interface. The module is thrown in the same place as the components / directives, and also must be exported if used in other modules.

The selector in camelCase is also used in component templates.

Angular's directives and filters cannot be used in patterns of angular components and vice versa. Between the frameworks, only services and components are forwarded.

First, we get rid of export default, because AoT compiler cannot.

Secondly, because of the current structure of the modules (very large) and the use of interfaces (we put in a heap in the same file where the classes are) we caught a funny bug with importing such interfaces and using them with decorators: if the interface is imported from a file containing exports not only interfaces, but also, for example, classes / constants, and such an interface is used for typing next to the decorator (for example, @Input() smth: ISmth ), the compiler will export 'ISmth' was not found import error export 'ISmth' was not found . This can be fixed either by moving all interfaces to a separate file (which is bad due to large modules, such a file will be in a dozen screens), or by replacing interfaces with classes. Replacement for classes is not a ride, because can not inherit from multiple parents.

Selected solution: create an interface directory in each module in which files with the name of the entity will be located, containing the corresponding interfaces (for example, room, step, content, workbook, homework). Accordingly, all interfaces that are not used locally are put there and imported from such file directories.

A more detailed description of the problem:
https://github.com/angular/angular/angular-cli/issues/2034#issuecomment-302666897
https://github.com/webpack/webpack/issues/2977#issuecomment-245898520

If transglud ( ng-content ) is used in the upgraded component, then when using the component from the angular templates:

• multi-slot transkluds do not work, only the ability to forward everything in one piece through one ng-content ;
• in the transcloud of such a component, it is impossible to pass ui-view, it will not work (broken off when attempting to upgrade the viewport component);
• if the component is used in a similar way, either we postpone its upgrade to an upgrade of all the places where it is used, or make a copy of it for parallel work in already upgraded components.

When using an angular component in an angular component, the inputs are written as for a regular component angular (using [] and () ), but in kebab-case

 <vim-angular-component [some-input]="" (some-output)=""> </vim-angular-component> 

When rewriting such a template on an angular, we kebab-case on camelCase.

Do not ride, because on it the AoT compiler will swear. Therefore, import the same files into the ts file and forward it through the component.

It was:

 <span> ${require('!html-loader!image-webpack-loader?{}!./images/icon.svg')} </span> 

has become:

 const imageIcon = require<string>("!html-loader!image-webpack-loader?{}!./images/icon.svg"); public imageIcon = imageIcon; <span [innerHTML]="imageIcon | vimBaseSafeHtml"> </span> 

Or for use via img

It was:

 <img ng-src="${require('./images/icon.svg')}" /> 

has become:

 const imageIcon = require<string>("./images/icon.svg"); public imageIcon = imageIcon; <img [src]="imageIcon | vimBaseSafeUrl" /> 

$compile is no more, and there is no compilation from the string (in fact, there is a small hack, but here it’s about how to live in 95% of cases without $compile ).

Dynamically inserted components are forwarded as follows:

 @Component({...}) class DynamicComponent {} @NgModule({ declarations: [ ... DynamicComponent, ], entryComponents: [ DynamicComponent, ], }) class SomeModule {} //  @Component({ ... template: ` <vim-base-dynamic-component [component]="dynamicComponent"></vim-base-dynamic-component> ` }) class SomeComponent { public dynamicComponent = DynamicComponent; } 

The class of the inserted component can be prokidyvatsya through the service, input or else how else.

vim-base-dynamic-component is an already-written component for dynamically inserting other components with input / output support (in the future, if needed).

If you need to display different templates according to the condition, and the dynamic templateUrl used for this, replace it with a structural directive and divide the component into three. An example for separating mobile / non mobile:

request / data processing
display for mobile
display for desktops

The first component has a minimal template and is engaged in working with data, processing user actions, and the like (such a template, because of its brevity, it makes sense to put the component component in the template via `` instead of a separate html file and templateUrl ). For example:

 @Component({ selector: "...", template: ` <some-component-mobile *vimBaseIfMobile="true" [data]="data" (changeSmth)="onChangeSmth($event)"> </some-component-mobile> <some-component-desktop *vimBaseIfMobile="false" [data]="data" (changeSmth)="onChangeSmth($event)"> </some-component-desktop> `, }) 

vimBaseIfMobile is a structural directive (in this case, a direct analogue of ngIf ), displaying the corresponding component by the internal condition and the parameter passed.

Components for mobile and desktop get data via input, send some events through output and deal only with the output of the necessary. All complex logic, processing, changing data - in the main component that displays them. In such components (desktop / mobile), you can safely write changeDetection: ChangeDetectionStrategy.OnPush .

Open app/entries/angularjs-services-upgrade.ts and follow the example of an existing copy-paste (all within this file):

 // EXAMPLE: copy-paste, fix naming/params, add to module providers at the bottom, use // ----- import LoaderService from "../service/loader"; // NOTE: this function MUST be provided and exported for AoT compilation export function loaderServiceFactory(i: any) { return i.get(LoaderService.ID); } const loaderServiceProvider = { provide: LoaderService, useFactory: loaderServiceFactory, deps: [ "$injector" ] }; // ----- @NgModule({ providers: [ loaderServiceProvider, ] }) export class AngularJSServicesUpgrade {} 

Those. we copy the existing block, import the necessary service, rule the names of the constants / functions under it, rule the service used in them and its name (most often, instead of SmthService.ID you will need to insert just the name of the service under which the service is available (injected) in Angular); new smthServiceProvider constant to the list of providers at the end of the file.

This service is used as native Angulyarovsky: just inject in the constructor by class.

We put in the file with the original component (at the beginning) the following stub, which will allow the component to be thrown into the angular environment:

 import {Directive, ElementRef, Injector, Input, Output, EventEmitter} from "@angular/core"; import {UpgradeComponent} from "@angular/upgrade/static"; @Directive({ /* tslint:disable:directive-selector */ selector: "vim-smth" }) /* tslint:disable:directive-class-suffix */ export class SmthComponent extends UpgradeComponent { @Input() smth: boolean; @Output() someAction: EventEmitter<string>; constructor(elementRef: ElementRef, injector: Injector) { super("vimSmth", elementRef, injector); } } @NgModule({ declarations: [ ... SmthComponent, ] }) export class SmthModule { 

Please note that in this case the Directive decorator is used instead of the Component , this is a feature of how the angular will process it.

We do not forget to register all Input / Output (binding from an original component) and to register a component in declarations corresponding module.

Further, when upgrading this component, such a cap will become a real component of the angular.

If a component (or rather, the old component directive) injects $attrs into the controller / link function, then such a component cannot be thrown into an angular from angularis, and it needs to be upgraded or put next to an upgraded copy for the angular.

Disabling tslint errors is necessary so that it does not swear at the discrepancy between the selector name and class to the decorator directive. These lines (comments) should be removed after the upgrade component.

• using the service with promises $q is replaced with native Promise . They do not have finally , but this is fixed by the core.js/es7.promise.finally and now it is. It also has no deferred, added ts-deferred, not to write a bike every time;
• instead of $timeout and $interval use native window.setTimeout and window.setInterval ;
• instead of ng-show="visible" let us go to the attribute [hidden]="!visible" ;
• track by now should always be a method, indicated as (do not forget about the Post's postfix method):

 *ngFor="let item of items; trackBy: itemTrack" public itemTrack(_index: number, item: IItem): number { return item.id; } 

• in 99% of cases, $digest , $apply , $evalAsync and the like are cut without replacement;
• for an injecting service, we simply write it in the constructor constructor(private someService: SomeService) , the angular itself will understand where to get it;
• inside the derivative, the element on which it hangs is accessible via the constructor(private element: ElementRef) injectable constructor(private element: ElementRef) and initialized in the AfterViewInit hook ( ElementRef is not a DOM object itself, it is accessible by this.element.nativeElement );
• ng-include not without replacement, we use dynamic component creation;
• angular.extend , angular.merge , angular.forEach and the like is absent, use native js and lodash;
• angular.element and all its methods are missing. We use @ViewChild/@ContentChild and work through the native js;
• if you need to pull the change in the component with OnPush - inject private changeDetectorRef: ChangeDetectorRef and pull this.changeDetectorRef.markForCheck() ;
• we cut out from templates $ctrl. - access to Saint-you and methods directly by name;
• ng-bind-html="smth" -> [innerHTML]="smth"
• $sce -> import {DomSanitizer} from "@angular/platform-browser";
• ng-pural -> [ngPlural] https://angular.io/api/common/NgPlural
• ngClass cannot

 [ngClass]="{ [ styles.active ]: visible, [ styles.smth ]: smth }" 

so replace with array

 [ngClass]="[ visible ? styles.active : '', smth ? styles.smth : '' ]" 

• classes for ui-router services are imported from @uirouter/core and injected without the old $ prefix

 import {StateService, TransitionService} from "@uirouter/core"; constructor(stateService: StateService, transitionService: TransitionService) { 

• data attributes on components are attr.data-smth="" as attr.data-smth="" or [attr.data-smth]="" ;
• require in components / directives is replaced by the component class injection directly in the constructor of the current component contructor(private parentComponent: ParentComponent) . Angulyar himself will see that this is a component, and hook him. For fine tuning there are decorators @Host (searches among parents), @Self (searches directly on the component), @Optional (may or may not, if not, the variable will be undefined). You can throw several @Host() @Optional() parentComponent: ParentComponent . It is possible to requisition components / directives in components / directives;
• two-way binding in its components has become more explicit and requires the indication of Output with the same name and the postfix Change .

 export class SmthComponent { @Input() variable: string; @Output() variableChange = new EventEmitter<string>(); <vim-smth [(variable)]="localVar"></vim-smth> 

• possible transludal angularis components in the angular component. The named transcloud must be checked: it works or not (in the angular it is made through selectors)

 <!-- angular --> <ng-content></ng-content> <!-- angularjs --> <vim-angular-component> transcluded data </vim-angular-component>