NgModule Decorator Deep Dive


In this post I want to emphasize some facts that help you understand the “ANGULAR MODULES (NGMODULE)” article.

1.          The services classes have different behaviors from Components, Directives and Pipes (CDP) in Angular Injector.

a.     Service behaviors in injector:

                                        1.     Singleton Instance – When you register a service to the Injector, you get a singleton instance.

                                        2.     Bubble – When a component wants to inject a service, Angular first looks at the component injector (child) and if the service doesn’t exist, it searches in the parent component injector (“bubble”). The Injector continues to go up until it finds the service. The root parent Injector belongs to platform object.


b.      CDP behaviors in injector:

                                        1.     Not singleton – When you use a directive or component in a template, you get a new instance of the directive/component. For example, if you use same directive number of times in a template, you get many instances of the directive.

                                        2.     Not bubble – You can’t register a directive in a parent component and use it in a child component.


2.          If a module loads normally, it doesn’t create an injector. If a module loads in a lazy way, it creates an injector for the module scope.

3.          Split the properties of NgModel Decorator to two groups: one for services and one for CDP.

a.     Group I – Properties for services classes:

                                        1.     Providers

b.     Group II – Properties for CDP classes:

                                        1.     Declarations

                                        2.     Imports

                                        3.     Exports

                                        4.     Bootstrap


Now we can start to explain the NgModule properties:


Group I – Properties for services classes:

§  @NgModule.providers – all the classes listed here are registered to the application injector as singleton (not in each component or directive metadata @component.providers that declares in @NgModule.declarations property). Anybody can ask for this singleton instance.
We have one exception; the lazy module has it on Injector. Meaning, the services listed in module providers are registered in the module injector instead of the application injector. It makes this service only available
to this module.


Group II – Properties for CDP classes:

§  @NgModule.declarations – all the CDP listed here know each other. It is the same as to register each component (@Component.directives) to all the other’s components. This property affects only the classes (CDP) defined in this property.

Example: declarations = [Compoent1, Component2, Component3, Directive1, Directive2, Pipe1, Pipe2 ]



Note: Each component knows all the others. Directive and pipe don’t have a template so they don’t need to know anybody.


§  @NgModule.exports – List of components, directives and pipes (CDP) that will be visible to modules that import this module.


§  @NgModule.imports – Everything from the imported modules that declares as an export, in the imported modules, will be available to declarations of this module.



1.     ModuleA ( declarations=[ Component1], imports:[ModuleB] )

2.     ModuleB ( declarations=[ Component2, Component3], exports:[ Component3] )


                        Component1 can use Component3 in a template but can’t use Component2.


§  @NgModule.bootstrap – Array of components to bootstrap. Angular loads this array to the DOM during the bootstrap (application launch) process. Use it only in root module (main).

This post is not instead of reading the ANGULAR MODULES (NGMODULE)” article, it just to emphasize some points in the article to make it more readable. I hope this information is helpful for you; send feedback please :=).

The next course opens on 18 September. For more information click here.


השארת תגובה

פורסם ע"י ב- אוגוסט 30, 2016 ב- Angular 2.0, AngularJS Tips


Custom Group Validation in Angular 2


Angular 2 has improved the way we write custom validation. There are a lot of articles of how to do it. In this post I want to focus on how to build custom group validation in model driven development. I will build a custom group validation (CGV) that checks each item in the formArray that has a unique value.

The code for the model:

namesArray = new FormArray([], this.customGroupValidation );
myForm =
new FormControl("
    names    :


I use the FormArray class instead of FormGroup in the names field because the number of names is unknown; it is dynamic. The user can add multiple names.


The template code:


<form [formGroup]="myForm">
    name : <
input type="text" formControlName="inputName"
button (click)="add()">Add</button><br
div class="left"
        names: <
ul formArrayName="names"
li *ngFor="let item of namesArray.controls; let i = index"
input type="text" [formControlName]="i"
button (click)="removeAt(i)">X</button><br
div *ngIf="namesArray.hasError('duplicate')"
            duplicate entries



The code for add and remove names:

new FormControl(this.myForm.get('inputName'


Now let’s see the custom group validation method. I used groupBy method of lodash library to detect if there are any groups of more than one item, which means that we have duplicate names.

customGroupValidation (formArray) {
let isError = false
result = _.groupBy( formArray.controls , c => c.value );
for (let prop in
result) {
if (result[prop].length > 1
) {

            isError = true;
(item:FormControl) {
                item._status =

0]._status = 'VALID';           

if(isError){ return {'duplicate':'duplicate entries'


The result of the custom group validation is that every time we add or change name to a value that already exists in the formArray, the two formControl with the same value will be invalid. In addition the parent formArray will also be invalid.


If I delete or change one of the duplicates names, the form will go back to be valid (in this case ‘Eyal’ name).

I hope this information was helpful for you. Try the live example.

This is one of many examples that I show in my AngularJS 2 course (.html"ng-course).

The next course opens on 18 September. For more information click .html"heHYPERLINK ""rHYPERLINK ""e.

תגובה אחת

פורסם ע"י ב- אוגוסט 28, 2016 ב- Angular 2.0, AngularJS Tips


Tips and Tricks 1 – Angular 2 Routing

When you use RouterModule.forRoot method to register the routes for the router object, the method has a second parameter of type ExtraOptions interface.

export interface ExtraOptions {


enableTracing = true :

Print to the console the navigation events: NavigationStart, RoutesRecognized and NavigationEnd. It can be very helpful information.


useHash = true:

Change the location strategy from path to hash. This is a short version of:

{ provide:LocationStrategy, useClass: HashLocationStrategy }. In the development environment I prefer to work with hash because it doesn’t break in F5 (reload).

The next Angular 2 course ( is going to be on 18, 21, 25, & 28 in September.

השארת תגובה

פורסם ע"י ב- אוגוסט 21, 2016 ב- Angular 2.0, AngularJS Tips


Angular2 in memory web api

Angular2 in memory web api


באנגולר 2 אפשר להשתמש בספריה ‘angular2-in-memory-web-api’ כדי לבטל את התקשורת הפיזית לשרת ולעבוד מול מידע שנמצא בזיכרון, טוב לבדיקות.

שלב ראשון מחלקה שתחזיק את המידע בזיכרון. ראו קוד:

export class InMemoryDataService {
createDb() {
return { users:[
// users resource
// user object
// user object
// users objects



1.     אנגולר יקרה למתודה createdDb בפעם הראשונה שתנסו לפעיל את המחלקה Http.

2.     ה- users מחליפים את ה- resource ב- web-API שעליו ניתן לעשות פעולות CRUD ע"פ החוקים של REST. למשל ‘app/users/12’ תביא את המשתמש עם id שווה ל- 12.


שלב שני בניית מערך לשימוש ה- Injector הראשי.


export const HTTP_IN_MEMORY = [
    { provide: XHRBackend, useClass: InMemoryBackendService },
    { provide: SEED_DATA , useClass: InMemoryDataService },
    { provide: InMemoryBackendConfig, useValue: { delay: 600 } }

1.     השרות XHRBackend הוא זה שמבצע בפועל את התקשורת לשרת, לכן 
צריך להחליף אותו עם השרות InMemoryBackendService שבמקום לבצע
תקשורת יקרא ל- SEED_DATA, שזה בעצם המחלקה שאנחנו כתבנו, 
שיוצרת את מבנה הנתונים בזיכרון.

2.     השרות InMemoryBackendConfig מאפשר לנו לתת הגדרות של התנהגות,
כמו למשל המתנה של 600 MS בין הקריאה לחזרת התשובה. 
ניתן לראות את כל האפשרויות בממשק הבא:

export interface InMemoryBackendConfigArgs {
    // default response options
    defaultResponseOptions?: ResponseOptions;
    // delay (in ms) to simulate latency
    delay?: number;
    // false (default) if ok when object-to-delete not found; else 404     
    delete404?: boolean;
    // host for this service
    host?: string;
    // root path before any API call
    rootPath?: string;
שלב אחרון: חיבור ל- bootstrap.
bootstrap(App,[ HTTP_IN_MEMORY ]);


השרות הזה יכול לעזור לכם בפיתוח ובבדיקות. אשמח לקבל פידבקים.


מאמר זה הוא חלק התוכן שאני מעביר בקורסים שלי.
הקורס הבא יהיה ב- 18 לספטמבר. לפרטים נוספים הירשמו כאן:


השארת תגובה

פורסם ע"י ב- יולי 4, 2016 ב- Angular 2.0, Uncategorized


Angular 2 The Clock Component

באנגולר 2 אחרי כל אירוע אסינכרוני יש tick שנקרה ע"י ה-zone. אם יש הרבה אירועים אסינכרוניים בשנייה אנחנו יכולים לגרום לבעיית ביצועים.

בפוסט זה אני רוצה להסביר איך לכתוב רכיב שעון בדיוק של 50 ms. בחרתי את הקוד הבסיסי  לשעון שלי:

let t = new
this.time =

return i < 10 ? `0${i}`
: i; }


שימו לב:

אני משתמש ב- setTimeout ולא ב- setInterval כדי לא ליצור עומס על ה- queue במידה וה- UI Thread עמוס ואז הוא לא מצליח למשוך מהתור את הפונקציות בקצב שה- setInterval מיצר אותם.


שלב א: לעבוד מחוץ לאנגולר

אני לא רוצה שכל 50 ms יבוצע tick במערכת. (המשמעות של tick  היא שאנגולר עובר על עץ הרכיבים ובודק מה השתנה ואז מעדכן את ה- UI. ראו פוסטים בנושא. ) לכן אני אשתמש ברכיב ה- NgZone.

constructor(zone:NgZone) {}
ngOnInit(){> {
הקוד הנ"ל מוציא את ה- setTimeout ממנגנון ה- zone. כלומר עכשיו ה- 50 ms לא גורמים ל- tick.

שלב ב: לעדכן את המסך

אני אשתמש ביכולות של ה- ChangeDetectorRef והפונקציה detectChanges, מחשבת את כל החלקים הדינאמים בתבנית (למשל {{}} או [] ). ראו קוד:

    selector: 'clock',
    template: `<span>{{time}}</span>`
export class Clock extends BaseDemo{
    time:string = '00:00:00:000';
    isDestroy:boolean = false;
                cd:ChangeDetectorRef) {}
    ngOnInit(){;> {
        if(this.isDestroy) return;
        let t = new Date();
        this.time = `
    formatNum(i){ return i < 10 ? `0${i}` : i; }
        this.isDestroy = true;



יש הרבה רכיבים שיש להם תדירות גבוהה של עדכון מסך. שימוש ברכים אלו יגרמו ל- tick שיגרום לעדכן את כל האפלקציה. בפוסט זה אני מראה לכם איך לשלוט בתדר העידכון ע"י ניתוק מה- zone וקריאה ל- detectChanges כל פעם שרוצים לעדכן את הרכיב על המסך. עדכון זה לא גורם ל- tick.

כמו תמיד אשמח לפידבקים.

למידע נוסף בנושא, אשמח לראות אותכם בקורס אנגולר  2 שלי ng-course.

תגובה אחת

פורסם ע"י ב- יוני 25, 2016 ב- Angular 2.0, Uncategorized


Pure Pipe vs. Impure Pipe


בפוסט זה אני רוצה להסביר את ההבדלים בין שני סוגי ה- Pipe. בשביל להסביר את ההבדלים בניתי את שני ה-pipes הבאים, ראו קוד:

import {Pipe} from '@angular/core';
let counter:number = 0
export class MyPipe implements
PipeTransform {
number = 0
(){ counter++; }
) {
return `n: ${name} v: ${value} c2: ${this.counter2++} c1:${counter}`
@Pipe({ name:
'myPurePipe', pure: true
export class MyPurePipe extends
constructor(){ super
(); }
@Pipe({ name:
'myImpurePipe', pure: false
export class MyImpurePipe extends
constructor(){ super
(); }


נשתמש ב-Pipes באופן הבאה:

myPurePipe  : {{ 1  | myPurePipe  : 'a' }}

myPurePipe  : {{ 1  | myPurePipe  : 'a' }}
myImpurePipe: {{ 2  | myImpurePipe: 'b' }}

myImpurePipe: {{ 2  | myImpurePipe: 'b' }}






Num of Instances

Num of Executes








Many == Ticks



א.    Pipe מסוג pure לא נוצרים מספר מופעים, כלומר זה singleton. המתודה transform מופעלת כאשר יש tick רק עם ה- inputs שונים מה-tick הקודם. במקרה שלנו 1 ו- ‘a’ לא משתנים ולכן ה- myPurePipe  פועל רק פעם אחת  כפול מספר הפעמים שאני משתמש בו בתבנית, כלומר 2.

ב.     Pipe מסוג impure נוצר instance כמספר הפעמים שהוא מופיעה בתבנית. בנוסף הוא מופעל כל tick.

שאלה: באיזה סוג של pipe אני צריך להשתמש?

כאשר משתמשים ב-pure תחשבו על מתודה דטרמיניסטית, אם מקבלים את אותו הקלט נחזיר תמיד את אותו הפלט. מכאן נובע שאנחנו לא צריכים מספר מופעים.

Pipe שהוא impure הוא לא דטרמיניסטית ולכן צריך להפעיל אותו בכל tick. יש סבירות גבוהה שאנחנו נצטרך לשמור נתונים שונים לכל pipe שמופיע בתבנית ולכן אנחנו צריכים מספר מופעים כדי לשמור את הנתונים השונים. דוגמא:

@Pipe({ name: 'sumRandomPipe', pure : false })
export class SumRandomPipe implements
PipeTransform {
number = 0
number, max:number
) {
this.sum +=  Math.floor(Math.random() * (max – min + 1
)) + min;
return this



כל אירוע אסיכרוני, timers ,UI ותקשורת גורמים ל-ticks מכאן נובע שב- impure צריך לבצע כל פעם מחדש את המתודה transform בלי קשר אם הקלט השתנה או לא, זה יכול לגרום לנו לבעיית ביצועים. בנוסף לא נשכח שלכל שימוש ב-pipe נוצר instance ושימוש מופרז יכול ליצור בעיות של זיכרון.

כמו תמיד כל תגובה מבורכת.

אשמח לראות אותכם בקורס שלי על AngularJS 2.



השארת תגובה

פורסם ע"י ב- יוני 15, 2016 ב- Angular 2.0


DoCheck vs. DoChanges

בפוסט זה אני רוצה להסביר את תהליך עידכון המסך באפלקציות שנכתבו ב-angular 2. תהליך העדכון של המסך ב-Angular מורכב מ-3 חלקים עקריים.

1. זיהוי הצורך בעידכון המסך (NgZone):

מנגנון זה אחראי על הפעלת מנגנון העידכון (tick). בלי הפעלת ה-tick לא יתעדכן המסך.  איך NgZone עושה את זה ניתן לקרוא כאן.

2. זיהוי השינוים ב- State של ה- Component וה- Directive ועידכון התבנית בהתאם:

מנגנון זה נקרה ChangeDetector. לכל Component נוצר ChangeDetector יחודי ע"פ התבנית של ה- Component. כל ביטוי ( השימוש ב- {{expression}} או [property]='expression' ) בתבנית יוצר ב- ChangeDetector סוג של watcher. ניתן לקורא על זה כאן וכאן.

3. מעבר על עץ ה- Components:

כאשר מופעל ה- tick אנגולר בודק את השינויים ע"פ סעיף 2 ב- Root Component. בנוסף הוא הוא עובר לילדים של Root Component. האבא מעביר לבן את השינויים דרך ה- inputs שמוגדרים בבן. במילים פשוטות האבא מבצע השמה לתכונות של הבן אם הוא מזהה שינוי ב- inputs. ראה דוגמא:


זו התבנית של האבא. כאשר ה- ChangeDetector של האבא מזהה שה- expression קיבל ערך חדש, מתבצע השמה של הערך החדש ב- property1 של רכיב הבן.

לפני שמתבצעת ההשמה ב-property1 מופעלים אצל הבן ה-hooks  שהוא מימש. עכשיו הגענו לרגע האמת שאפשר להסביר את ההבדל בין שני ה- hooks, הראשון ngOnChanges והשני ngDoCheck.

בדוגמא שלמעלה אם ה- expression שווה לערך מסוג primitive , האנגולר מסוגל לזהות שינויים בערך של ה- expression. במקרים אלו אם נשתמש ב- ngOnChanges אנגולר יספק לנו ערך ישן וערך חדש.

שאלה: למה צריך את ה- ngOnChanges אם בסופו של דבר נגיע ל- setter של ה- property ששם אנחנו יודעים גם לזהות ערך קודם וערך חדש?

תשובה: אכן השימוש בזה לא שכיח, רוב ה- Directives של אנגולר לא משתמשים בזה.  NgModel משתמש ב- ngOnChanges, ע"פ דעתי אפשר לכתוב את הקוד הנ"ל גם בלי ngOnChanges.

שאלה: האם אנגולר מסוגל לזהות שינויים בתוך אובייקט או מערך ב- Input?

תשובה: לא.

בדוגמא למעלה אם ה- expression מחזיר אובייקט, אנגולר לא מסגול לזהות שינויים באובייקט ( זה כולל גם מערכים ) וכתוצאה מכך גם ה- setter של ה- property לא יתבצע, כאשר יש שינוי באובייקט.

שאלה: מה עושים?

תשובה: ngDoCheck.

כאשר אנחנו צריכים Input מסוג אובייקט או מערך אנחנו צריכים להשתמש ב- ngDoCheck. הפעלת המתודה ngDoCheck אומרת לכותב ה- Component זה הזמן שלך לבדוק מה השתנה ולעדכן את ה- properties בהתאם.

שאלה: איך בודקים מה השתנה באובייקט או במערך?

תשובה: באנגולר יש את שני המחלקות SimpleChange ו- IterableDiffers שבעזרתם אנחנו יכולים לזהות שינויים. פוסט בנושא ניתן לקורא כאן.

ראו טבלה של Directives שמשתמשים במחלקות אלו:

Differ Class


Input Type















שאלה: אני שאלה קטנה, למה אנחנו צריכים לדעת את כל זה?

תשובה: ביצועים…

יש מספר פרמטרים שמשפיעים על הביצועים:

1. מספר ה- expressions ב- Template.

2. תדירות ה- tick.

3. גודל העץ שצריך לסרוק ב- tick.

מכאן נובע שאם נצליח להקטין כל אחד מהסעיפים, נצליח לשפר את הביצועים.


איך עושים את זה בפוסט הבא.

אם אהבתם את הפוסט אתם מוזמנים לבוא לקורס שלי ב-Angular 2.

לפרטים לחצו כאן.

תגובה אחת

פורסם ע"י ב- יוני 2, 2016 ב- Angular 2.0