Featured

My speaking and training schedule

I’ll be speaking at conferences and teaching various Angular-2 classes. Here’s the list of my upcoming engagements:

Online workshop on Angular 2, starts on September 11

* Private two-day Angular 2 Workshop at Princeton University, September  13-14

* Angular Summit, Boston,MA Sep 25-26

* Rich Web Experience, Clearwater, FL, Dec 6-9

If you’d like me to run an Angular 2 workshop for your organization please send an email at training@faratasystems.com.

Wrote a book on Angular 2. Do I know it?

Over the last year I spent a substantial portion of my time writing a book “Angular 2 Development with TypeScript”. I wrote it with my colleague, Anton Moiseev. We are already working on real-world projects in Angular 2 for our software product SureLC that automates the work of insurance agents. We also taught multiple public and private Angular 2 workshops.

This morning after reading yet another post titled “How to learn Angular 2?”, I’ve asked myself, “Do I know Angular 2?”. The honest answer is “Kinda”. Let me explain.

First, let’s define what a developer needs to know to be productive in an Angular 2 project. I’ll color the items as the slopes marked in the ski resorts.

Green – easy Almost flat
Blue – moderate. Can get nasty is the snow is not groomed
Red – difficult, but manageable for non-experts. The slops are steeper than blue
Black – really difficult. You have to be an expert to enjoy the ride.

Disclaimer. I can ski on black slopes, but I don’t enjoy the process. You won’t enjoy watching me going down the black slope, but I’ll arrive to the base.

skii_map

1. TypeScript. Yes, you can use other languages, but let’s get real. The framework is written in TypeScript, 90% of blog post and tutorials use TypeScript.

2. NPM package manager. America runs on Dunkin. The JavaScript world runs on packages. If a C-programmer writes a function to pad a string with spaces, JavaScript programmer tries to find an NPM package that does it and adds it as a dependency to his application.

3. Type definition files (*.d.ts). These files help TypeScript compiler understand the API of third-party libraries written in JavaScript. Starting from TypeScript 2.0 it’s relatively easy with the @types npm organization.

4. A module loader. Starting from EcmaScript 6 we think in modules, and it’s a good thing. Adding and maintaining multiple scrip tags for dependencies? No more. You’ll start with SystemJS and then most likely will switch to Webpack.

5. Unit testing framework. Go with Jasmine.

6. Test runner that allows to run unit tests against multiple browsers from a command line. Use Karma runner.

7. Module bundler. You need to bundle your app into a small number of files so the browser won’t make several hundreds of network requests to load Angular modules. We use Webpack.

8. Task runner. Don’t even think of starting writing the app before setting up your build automation process. Start with using npm scripts. If you’ll run into any limitations, add some Gulp scripts.

9. Angular Router. This piece has been completely rewritten three times over the last year. It’s turning into a really powerful component.

10. Dependency Injection. Works really well and is stable.

11. Forms API. It’s still changing, but is getting there.

12. Inter-component communications. It’s important to architect your applications properly so components communicate in a loosely coupled way.

13. Reactive extensions RxJS. For async communications Angular 2 uses Observables and Subscribers instead of Promises.

14. The Http module. Responsible for communication with Http servers

15. Change detection (Zone.js). This piece monitors all async changes in your components and updates the view. For most apps you don’t need to worry about it, but if you’ll need to optimize the performance of your app, plan to invest some serious efforts to learn it.

16. UI components. Angular Material 2 is in its infancy with only 15 available components. If you need to deploy your app in prod this year, go with Wijmo 5 or PrimeNG

17. Angular CLI. This tool is in its infancy as well. It allows to quickly generate the project components and create the build. It starts with downloading the entire Internet to your computer and then generates stuff. My position is wait and see.

18. IDE. I saved this item for the happy ending. The IDEs used for TypeScript and Angular 2 are almost as good as their peers in Java or C# world. We use WebStorm, but Visual Studio Code is also great.

It took me a while to get comfortable with all the items from this list. I don’t know everything, but I know where to look for a solution. The Angular documentation is sparse and lots of APIs are not documented yet. There are multiple blogs that help with solving specific tasks, but most of the blogs become outdated because Angular 2 is still changing. In particular, the introduction of @NgModule in RC.5 will force me to refactor lots of code.

In the Summer of 2015 Angular 2 was in Alpha, the API was changing weekly, but I didn’t complain:  I was an early adopter. The problem is that it’s Summer of 2016, but as of Release Candidate 4 the API is still changing and I remain an early adopter.

This list may look intimidating, but if you’ll invest enough time the results will be rewarding. I believe in 2017 Angular will become the most popular framework for developing of the front end of the medium and large web apps.

If you’re interested in learning Angular 2 in depth, enroll into one of our workshops. We’ll run the next public training   online starting from September 11, 2016. I can also deliver this workshop privately for your organization (send an email to training@faratasystems.com).

Angular 2: Guarding routes

In this blog I’ll show you how to guard routes in Angular 2 Router (currently at 3.0.0-beta.2).

Let’s consider some scenarios that require a certain validation to be performed to decide if the user (or a program) is allowed to navigate to or leave the route:

* Allow to open the route only if the user is authenticated and authorized to do so.

* Implement a multi-part form that consists of several components, and the user is allowed to navigate to the next form section only if the data entered in the current one is valid.

* Remind the user about the unsaved changes if he or she tries to navigate from the route.

The router has the hooks that give you more control over the navigation to/from a route, and you can use these hooks to implement the any of above scenarios to guard the routes.

Angular includes a number of component lifecycle hooks that allow you to handle important events in the life of a component. First, it worth noting that the route configuration is done outside of the components. You configure routes in an object of type RouterConfig, then give it to the provideRouter() function, which in turn is given to the function bootstrap() that loads your app.
The type RouterConfig is a collection of items that conforms to the Route interface shown below:

export interface Route {
 path?: string;
 pathMatch?: 'full' | 'prefix';
 component?: Type | string;
 redirectTo?: string;
 outlet?: string;
 canActivate?: any[];
 canDeactivate?: any[];
 data?: Data;
 resolve?: ResolveData;
 children?: Route[];
}

While configuring routes you’ll typically use two properties from this interface: path and component. For example, an app that has two links Home and Product Details can specify and bootstrap the routes as follows:

bootstrap(RootComponent, [
    provideRouter([
      {path: '',        component: HomeComponent},
      {path: 'product', component: ProductDetailComponent}]),
    {provide: LocationStrategy, useClass: HashLocationStrategy}
]);

But in this blog I’d like to you to get familiar with the properties canActivate and canDeactivate that allow you to hook up the routes with the guards. Basically you need to write a function(s) implementing the validating logic that will return either true or false and assign it to one of these properties. If canActivate() of the guard returns true, the user can navigate to the route. If canDeactivate() returns true, the user can navigate from the route. Since both canActivate and canDeactivate properties of Route accept an array as a value, you can assign multiple functions (the guards) if you need to check more than one condition to allow or forbid the navigation.

Let’s create a simple app with Home and Product Details links to illustrate how you can protect the product route from the users who are not logged in. To keep the example simple, we won’t use an actual login service, but will generate the login status randomly.

We’ll create a guard class that implements the interface CanActivate, which declares only one function to implement: canActivate(). This function should contain the application logic that returns true or false. If the function returns false (the user is not logged in) the application will not navigate to the route and will print the error message on the console.

import {CanActivate} from "@angular/router";
import {Injectable} from "@angular/core";

@Injectable()
export class LoginGuard implements CanActivate{

  canActivate() {
      return this.checkIfLoggedIn();
  }

  private checkIfLoggedIn(): boolean{

      // A call to the actual login service would go here
      // For now we'll just randomly return true or false

      let loggedIn:boolean = Math.random() < 0.5;

      if(!loggedIn){
          console.log("LoginGuard: The user is not logged in and can't navigate product details");
      }

      return loggedIn;
  }
}

As you see from the code, my implementation of the function canActivate() will randomly return true or false emulating the user’s logged in status.

The next step is to update the router configuration so it uses our guard. The code snippet below shows how the function provideRouter() can look like for the app that has Home and Product Detail routes and the latter is protected by our LoginGuard:

provideRouter([
  {path: '',        component: HomeComponent},
  {path: 'product', component: ProductDetailComponent,
                    canActivate:[LoginGuard]}
])

Adding one or more guards to the array given to the canActivate property will automatically invoke all guards one after the other. If any of the guards returns false, the navigation to the route will be prohibited.

But who will instantiate the class LoginGuard? Angular will do it for us using its dependency injection mechanism, but you have to mention this class in the list of providers which are needed for injection to work. We’ll just add the name LoginGuard to the list of providers in the bootstrap() function of our app:

bootstrap(RootComponent, [
    provideRouter([
      {path: '',        component: HomeComponent},
      {path: 'product', component: ProductDetailComponent,
                        canActivate:[LoginGuard]}]),
    LoginGuard,
    {provide: LocationStrategy, useClass: HashLocationStrategy}
]);

The complete code of the main app script is shown next:

import {bootstrap} from '@angular/platform-browser-dynamic';
import {Component} from '@angular/core';
import {LocationStrategy, HashLocationStrategy} from '@angular/common';
import {provideRouter, ROUTER_DIRECTIVES} from '@angular/router';

import {HomeComponent} from './components/home';
import {ProductDetailComponent} from './components/product';

import {LoginGuard} from './guards/login.guard';

@Component({
    selector: 'basic-routing',
    directives: [ROUTER_DIRECTIVES],
    template: `
        <a [routerLink]="['/']">Home</a>
        <a [routerLink]="['/product']">Product Details</a>
        <router-outlet></router-outlet>
    `
})
class RootComponent {}

bootstrap(RootComponent, [
    provideRouter([
      {path: '',        component: HomeComponent},
      {path: 'product', component: ProductDetailComponent,
                        canActivate:[LoginGuard]}]),
    LoginGuard,
    {provide: LocationStrategy, useClass: HashLocationStrategy}
]);

If you run this app and will try to lick on the Product Details link, it’ll either navigate to this route or print the error message on the browser console depending on the randomly generated value in the LoginGuard. The snapshot below was taken after the user tried to click on the Product Details link, but the LoginGuard “decided” that the user is not logged in.

ch3_loginguard

But if our unpredictable LoginGuard “decided” that the user is logged in, the screen will look as follows after clicking on the Product Details link:

nonguarded

Dependency Injection Benefit. Since a guard is injected into your app, you can use it as any other object. For example, you can inject it in your RootComponent:

 constructor (private _loginGuard:LoginGuard){}

Then invoke any methods defined on the guard class, e.g.:

 this._loginGuard.changeLoginStatus(true);

Our LoginGuard implements the method canActivate() without providing any arguments to it. But this method can be used with the following signature:

canActivate(destination: ActivatedRouteSnapshot,
            state: RouterStateSnapshot)

The values of the ActivatedRouteSnapshot and RouterStateSnapshot will be injected by Angular automatically and may become quite handy if you want to analyze the current state of the router. For example, if you’d like to know the name of the route the user tried to navigate to, this is how to do it:

canActivate(destination: ActivatedRouteSnapshot,
            state: RouterStateSnapshot) {

      console.log(destination.component.name);
   ...
}

Implementing the CanDeactivate interface that would control the process of navigating from a route works similarly. Just create a guard class that implements the method canDeactivate(), for example:

import {CanDeactivate, Router} from "@angular/router";
import {Injectable} from "@angular/core";

@Injectable()
export class UnsavedChangesGuard implements CanDeactivate{

    constructor(private _router:Router){}

    canDeactivate(){
      return window.confirm("You have unsaved changes. Still want to leave?");
    }
}

Don’t forget to add the canDeactivate property to the route configuration and inject the new guard in bootstrap(), e.g.:

bootstrap(RootComponent, [
    provideRouter([
      {path: '',        component: HomeComponent},
      {path: 'product', component: ProductDetailComponent,
          canActivate:[LoginGuard], canDeactivate:[UnsavedChangesGuard]}
    ]),
    LoginGuard, UnsavedChangesGuard,
    {provide: LocationStrategy, useClass: HashLocationStrategy}
]);

For a fancier way of displaying confirmation dialogs use the MdDialog component from the Material Design 2 library (see https://github.com/angular/material2). This component will be released in the upcoming Alpha 7.

NOTE: If you want to delay the navigation to a route until certain data structures have been populated, use the property resolve from the Route interface. I’ll write a separate blog showing how to do it.

In this blog I didn’t show you the code of HomeComponent and ProductDetail component, but you can find them in the Github repo with the code samples from Chapter 3 from our book Angular 2 Development with TypeScript.

If you’re interested in learning Angular 2 in depth, enroll into one of our workshops. The next one we’ll run online starting from September 11, 2016.

Angular2, npm, and TypeScript: the first steps

Angular 2 is getting more and more stable. As of July of 2016 it reached the version Release Candidate 4 and I expect to see the official release of this framework not later than in October of this year.

While developing Angular 2 applications in TypeScript is easier than in JavaScript, the initial setup of the project may be intimidating. You need to be familiar with installing and configuring NPM packages and the process of transpiling of the code from TypeScript to JavaScript.

I’d like to offer you an extract from the video from the first session of our recent online training where I show how to install the TypeScript compiler, all required npm modules, and create configuration files for npm and the module loader SystemJS. In this video I was using Angular Release Candidate 1, but you can change the versions from rc.1 to rc.4 and everything will work fine.

Our next 6-week online workshop starts on September 11. It runs on weekends and will give you a solid understanding of how to work on the real-world project with Angular 2 and TypeScript.

If you’re reading this blog after September 11, check the schedule of our upcoming trainings at yakovfain.com.

Dear Publisher, please do not print our book

Disclaimer: I’ve been writing for many publishers and Manning’s process of book publishing is the best I’ve seen so far.

My colleague and I spent a year writing the book on Angular 2. At the same time the Angular team was releasing dozens of alphas, and we kept modifying the code and the text.

Then the Angular team released several betas of Angular 2, and we’ve modified the code and the text.

Then the Angular team released several Release Candidates of Angular 2, and we’ve modified the code and the text.

The good news. Manning has released six versions of MEAP of our book “Angular 2 Development with TypeScript”, which remains Manning’s bestseller for many weeks in a row.

We’re diligently updating the code and the text, but I don’t want this book to be printed on paper. Why? Because the Angular team (understandably) will keep changing the API, and the readers of the printed book will blame us for the outdated text.

This book as well as all other books on software should NOT be printed on paper. The authors should be able to keep changing drafts for as long as the software is being changed. If not printing is not an option, the publishers should offer a print-on-demand service for those readers who like paper.

Back to Angular 2. Over the last year the router has been re-written three times. The final re-write (known as Router 3.0) has been released AFTER the Release Candidate 1.

The Forms API has been changed (currently at 0.2.0) as well after the Release Candidate 1.

We write code in TypeScript, which is a great way to develop JavaScript applications with types support. To integrate the TypeScript code with tons of available JavaScript libraries we need so called type definition files (*.d.ts). There was a Type Definition manager tsd. It’s deprecated in favor of Typings. Cool. We changed everything to work with type declarations known as “ambient”. All of a sudden ambient no more. As of May 2016 it’s called “global”. OK. Changed the text and the code. But. If Manning will publish our book before TypeScript 2.0 is out, it’ll be outdated. Why? Because TypeScript 2.0 will introduce @types that will deprecate Typings.

There is more to whine about. Unit testing. It’s being changed as we speak. OK, we’ll re-write chapter 9 to remove anything specific to Jasmine.

Chapter 10. Build automation. We used Webpack cause it’s the tool to use for prod systems today. Meanwhile, Google shows wonders at the conferences with Angular CLI, which (I’m sure) will become the right way to automate builds of Angular apps. But not this year. At the time of this writing installing Angular CLI is like installing the whole content of npmjs.org. To put it simple, if you want to clone the entire NPM repo, write the following command: npm install -g angular-cli.

Now let’s talk about UI. The Material Design 2 is in the works. But. It has about 15 components now. Cool for demos and conferences, but not for the real world enterprise apps. It’s getting there, but not this year. So what you, the enterprise developer should do? Get Wijmo 5 components. It costs money and is not a silver bullet. But, there are not many choices as of yet.

Job offer. I got an email asking if I’m available for working on a two-month consulting project. The scope is to create an initial setup for Angular 2 projects, prepare the build scripts, and develop a library of reusable UI components. I can do all of this in two months except a library of reusable UI components. Sorry, I’ll pass on this opportunity. Get real. Next year. Maybe.

We’re running our ongoing training classes using our book as a textbook. This allows us to keep our training materials as well as Manning eBook up to date. But I hate to see the future comments pointing at the places where our printed text is wrong.

I used to own a large library of software books, but during the last year I threw away (left at the curb for recycling) about 50 books on software that were printed before 2011. Next month I’ll get rid of all books that were printed before 2014. Unless the book is about data structures or algorithms it’ll go to recycling.

I really like the Manning’s workflow in publishing books. But it’ll be even better if this book will never be printed. We already sold about two thousand e-book downloads. Let’s keep selling files, and we’ll keep them up to date. There is a MEAP program for drafts, and a similar program is needed to keep the drafts updated after the book is “finished”. Dear Manning, please do not print our book or print it on demand!

Starting an Angular 2 RC.4 project

This blog is updated on July 28, 2016

The current version of Angular is Release Candidate 4. Starting from RC.1 the Angular 2 framework is distributed as a set of scoped npm packages. Any imports of the Angular classes will be done from @angular instead of angular2, for example:

import {bootstrap} from '@angular/platform-browser-dynamic';
import {Component} from '@angular/core';

The content of package.json, index.html, and the configuration of the SystemJS loader has to be changed accordingly (comparing to Beta releases). This post is an modified extract of our book Angular 2 Development with Typescript, and it’ll show you how to get started with a new Angular 2 RC.4 project.

To start a new project managed by npm, create a new directory (e.g. angular-seed) and open it in the command window. Then run the command npm init -y, which will create the initial version of the package.json configuration file. Normally npm init asks several questions while creating the file, but the -y flag makes it accept the default values for all options. The following example shows the log of this command running in the empty angular-seed directory.

$ npm init -y

Wrote to /Users/username/angular-seed/package.json:

{
  "name": "angular-seed",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC"
}

Most of the generated configuration is needed either for publishing the project into the npm registry or while installing the package as a dependency for another project. We’ll use npm only for managing project dependencies and automating development and build processes.

Because we’re not going to publish it into the npm registry, you should remove all of the properties except name, description, and scripts. Also, add a “private”: true property because it’s not created by default. It will prevent the package from being accidentally published to the npm registry. The package.json file should look like this:

{
  "name": "angular-seed",
  "description": "An initial npm-managed project for Chapter 2",
  "private": true,
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  }
}

The scripts configuration allows you to specify commands that you can run in the command window. By default, npm init creates the test command, which can be run like this: npm test. Let’s replace it with the start command that we’ll be using for launching the live-server that’s we’ll add to the generated package.json a bit later. Here’s the configuration of the scripts property:

{
  ...
  "scripts": {
    "start": "live-server"
  }
}

You can run any npm command from the scripts section using the syntax npm run mycommand, e.g. npm run start. You can also use the shorthand npm start command instead of npm run start. The shorthand syntax is available only for predefined npm scripts (see the npm documentation at https://docs.npmjs.com/misc/scripts).

Now we want npm to download Angular to this project as a dependency. We want Angular with its dependencies to be downloaded to our project directory. We also want local versions of SystemJS, live-server, and the TypeScript compiler.

npm packages often consist of bundles optimized for production use that don’t include the source code of the libraries. Let’s add the dependencies and devDependencies sections to the package.json file right after the license line:

    "dependencies": {
    "@angular/common": "2.0.0-rc.4",
    "@angular/compiler": "2.0.0-rc.4",
    "@angular/core": "2.0.0-rc.4",
    "@angular/forms": "^0.2.0",
    "@angular/http": "2.0.0-rc.4",
    "@angular/platform-browser": "2.0.0-rc.4",
    "@angular/platform-browser-dynamic": "2.0.0-rc.4",
    "@angular/router": "3.0.0-beta.2",
    "@types/es6-shim": "0.0.27-alpha",
    "reflect-metadata": "^0.1.3",
    "rxjs": "5.0.0-beta.6",
    "systemjs": "^0.19.31",
    "zone.js": "^0.6.12"
  },
  "devDependencies": {
    "live-server": "1.0.0",
    "typescript": "^2.0.0"
  }

NOTE:This version uses the very latest version of Angular Router, which is currently 3.0.0-beta.2.

Now run the command npm install on the command line from the directory where your package.json is located, and npm will start downloading the preceding packages and their dependencies into the node_modules folder. After this process is complete, you’ll see dozens of subdirectories in node_modules, including @angular, systemjs, live-server, and typescript.

angular-seed
├── index.html
├── package.json
└── app
└── app.ts
├──node_modules
    ├── @angular
    ├── systemjs
    ├── typescript
    ├── live-server
    └── …

In the angular-seed folder, let’s create a slightly modified version of index.html with the following content:

<!DOCTYPE html>
<html>
<head>
  <title>Angular seed project</title>
  <script src="node_modules/zone.js/dist/zone.js"></script>
  <script src="node_modules/typescript/lib/typescript.js"></script>
  <script src="node_modules/reflect-metadata/Reflect.js"></script>
  <script src="node_modules/systemjs/dist/system.src.js"></script>
  <!-- script src="node_modules/rxjs/bundles/Rx.js"></script -->
  <script src="systemjs.config.js"></script>
  <script>
    System.import('app').catch(function (err) {console.error(err);});
  </script>
</head>
<body>
<app>Loading...</app>
</body>
</html>

The script tags load the required dependencies of Angular from the local directory node_modules. The Angular modules will be loaded according to the SystemJS configuration file systemjs.config.js. Note the commented out script tag for Rx.js. I’ll show you two ways of configuring SystemJS, and in the first version this line is not needed.

Configuring SystemJS. Take 1.

The SystemJS configuration file systemjs.config.js can look as follows:

System.config({
    transpiler: 'typescript',
    typescriptOptions: {emitDecoratorMetadata: true},
    map: {
        'app' : 'app',
        'rxjs': 'node_modules/rxjs',
        '@angular'                    : 'node_modules/@angular'
      },
      packages: {
        'app'                              : {main: 'main', 
                                              defaultExtension: 'ts'},
        'rxjs'                             : {main: 'index.js'},
        '@angular/core'                    : {main: 'index.js'},
        '@angular/common'                  : {main: 'index.js'},
        '@angular/compiler'                : {main: 'index.js'},
        '@angular/router'                  : {main: 'index.js'},
        '@angular/platform-browser'        : {main: 'index.js'},
        '@angular/platform-browser-dynamic': {main: 'index.js'}
      }
});

NOTE:This version loads all Angular modules as separate files, which causes the browser to make 300+ network requests. No good.

In the section packages we mapped the name app to main.ts, so let’s create a directory called app inside angular-seed, and inside the app directory create an main.ts file, as follows.

----
import {bootstrap} from '@angular/platform-browser-dynamic';
import {Component} from '@angular/core';

@Component({
  selector: 'app',
  template: `<h1>Hello {{ name }}!</h1>`})
class AppComponent {
  name: string;
  constructor() {
    this.name = 'Angular 2';
  }
}

bootstrap(AppComponent);

Here we import Component and bootstrap from Angular, which is already preloaded into the local directory node_modules.

Start the application by executing the npm start command from the angular-seed directory, and it’ll open your browser and show the message “Loading…” for a couple of seconds, followed by “Hello Angular 2!”. If you check the Network panel in Chrome Developer tools, it shows more than 300 network requests and 5.3Mb of the downloaded code. Not all of this code is Angular though. SystemJS uses the TypeScript compiler in the browser, and it weighs 3Mb.

Configuring SystemJS. Take 2.

To lower the number of network requests and the download size let’s change the systemjs.config.js to use the minimized and bundled versions of Angular packages:

System.config({
    transpiler: 'typescript',
    typescriptOptions: {emitDecoratorMetadata: true},
    map: {
      '@angular': 'node_modules/@angular'
    },
    paths: {
      'node_modules/@angular/*': 'node_modules/@angular/*/bundles'
    },
    meta: {
      '@angular/*': {'format': 'cjs'}
    },
    packages: {
        'app'                              : {main: 'main', 
                                              defaultExtension: 'ts'},
       '@angular/core'            :{main: 'core.umd.min.js'},
       '@angular/common'          :{main: 'common.umd.min.js'},
       '@angular/compiler'        :{main: 'compiler.umd.min.js'},
       '@angular/platform-browser':{main: 'platform-browser.umd.min.js'},
       '@angular/platform-browser-dynamic': 
                            {main:'platform-browser-dynamic.umd.min.js'}
    }
});

NOTE: I’ve removed the Rx.js configuration from this version of systemjs.config.js, and you’ll need to uncomment the line that loads Rx.js in the index.html shown earlier.

If you run the same application now, it’ll make only 14 network requests and the download size is 4.5MB. Much better, isn’t it? In chapter 10 of our book we explain how to minimize a small Angular app to 150Kb with Webpack.

You can find the source code of the initial angular-seed project at https://github.com/Farata/angular2typescript/tree/master/chapter2/angular-seed.

That’s all there is to it for the Hello World type application.

I’d like to thank Anton Moiseev, my coauthor of the Angular 2 book for his contribution to this blog. We often run online Angular 2 trainings, and if you’re interested in learning Angular 2 in depth, join one of our workshops (see the dates of the upcoming trainings at https://yakovfain.com/ ).

Angular 2: Exposing Child Component’s API

In Angular 2 a parent component can pass the data to its child via binding to the child’s input parameter marked with the annotation @Input(). I’ll blog about it later, but you can see how it can be done in my blog on implementing the Mediator design pattern.

In this blog I’ll show you another scenario when the parent component simply needs to use the API exposed by the child. You’ll see how a parent component can use the child’s API from both the template and the TypeScript code.

Let’s create a simple application where a child component has the method greet() that will be invoked by the parent. Our Child component will look like this:

@Component({
    selector: 'child',
    template: `<h3>Child</h3>`

})
class Child {
    greet(name) {
        console.log(`Hello from ${name}.`);
    }
}

To illustrate different techniques of calling the child’s API, the parent will use two instances of the same child component.

<child #child1></child>
<child #child2></child>

Here use local template variables that are used to for getting a reference to DOM object that represents an HTML component in the browser’s window. The names of local template variables must start with the hash sign.

To access the first child component from the TypeScript code, the parent component App will declare a variable of type Child annotated with `@ViewChild`. This annotation is provided by Angular for getting a reference to child components. This code will also invoke the method greet() declared in the Child component:

@ViewChild('child1')
firstChild: Child;
  // invoke the child's API
this.firstChild.greet('Child 1');

The second child will be accessed not from the code, but from the parent’s template as simple as this:

<button (click)="child2.greet('Child 2')">Invoke greet() on child 2</button>

The entire code of the application that uses both techniques is shown below.

import {bootstrap} from 'angular2/platform/browser';
import {Component, ViewChild, AfterViewInit} from 'angular2/core';

@Component({
    selector: 'child',
    template: `<h3>Child</h3>`

})
class Child {
    greet(name) {
        console.log(`Hello from ${name}.`);
    }
}

@Component({
    selector: 'app',
    directives: [Child],
    template: `
    <h1>Parent</h1>
    <child #child1></child>
    <child #child2></child>

    <button (click)="child2.greet('Child 2')">Invoke greet() on child 2</button>
  `
})
class App implements AfterViewInit {
    @ViewChild('child1')
    firstChild: Child;

    ngAfterViewInit() {
        this.firstChild.greet('Child 1');
    }
}

bootstrap(App);

If you’ll run this application in the browser with Developer Panel open, it’ll immediately invoke the method greet() on the first child and will print the greeting on the console. This is an illustration of using of the child’s API from the TypeScript code. If you click on the button, the method greet() will be invoked on the second child, which is an illustration of the using child’s API from the template. The browser’s window will look as follows:

child_api

Note that in the above example I used the parent’s component lifecycle hook ngAfterViewInit() for invoking the API on the first child. The child’s greet() method doesn’t change its UI and simply prints the message on the console. But if you’d try to change the UI from greet() Angular would throw an exception that the UI is changed after ngAfterViewInit() was fired. The reason being that this hook is called in the same event loop for both parent and child components, and Angular by default runs in the development mode which does an additional change detection run to check the bindings, and it wouldn’t like the fact that UI has changed again on the same event.

There are two ways to deal with this issue:
1. either run the application in the production mode – invoke enableProdMode() before the bootstrap() – so Angular won’t do the additional bindings check
2. Use setTimeout() for the code updating UI to run it in the next event loop.

If you’re interesting in learning Angular 2, consider enrolling into one of our training classes. The current schedule is published here.

My two cents on the npm scandal

If you haven’t heard the story, here’s the gist of it. A guy named Azer Koçulu published 250(!) open source packages in the popular repository npmjs.org, which is a central repo for all JavaScript developers (it’s like Maven Central for Java developers).  One of the packages was named kik. Unfortunately for Azer (and all of us), there is a company with the same name, and they decided to publish the package with the same name on NPM. Due to the name conflicts, they contacted Azer asking him to rename his package that was already used by many users. Here’s the Kik corporation’s  version of the story. And this is what Azer wrote.

This is really sad. I’m with Azer 100%. There is a corporate world and there is an open source world. The corporate world loves using free and open source libraries and frameworks that help them making money. But they won’t think twice and will invest hundreds of thousands of dollars to win the case against Azer if need be.

Why a company with 270 million users rejected Azer’s offer to buy the name from him for mere $30K? Because they are a bunch of dicks as Azer correctly put it. They want free stuff.

There should be some international law that will make the commercial and the open source worlds live in parallel dimensions. If one corp uses a trademarked term from another corp, it can be sued. But they should not reach out to the open source world imposing their rules there.

We are using the JavaScript framework Jasmine for unit testing. I have a suspicion that there are some other uses of the word Jasmine.  Beside being a plant, a trading companya nail salon in Brooklyn,NY, a Thailand telecom company there are thousands establishments that use this word in their names. Now any of them can write a package that prints Hello World (even a plant can do it), and write a letter to NPM to remove the jasmine package from there.

Guys, this may open a can of worms. kik.com should back off!

Part 2 or is my application at risk

You might by thinking, “I don’t really care cause I’m not using any of Azer’s packages. I’m using Angular developed by a large company that employs hundreds of lawyers”. Wrong. In modern JavaScript ecosystem it’s very difficult to use just one thing. I’ll give you an example using one our simple projects that uses five npm packages: Angular 2, TypeScript, Jasmine, Karma, and live-server. I’ll give you a little quiz. How many packages will be installed on your computer to get these five things? Just take a look at the end of log file of the “npm install” command that I ran on my computer to install these five things.

log

That’s right. Those five packages had dependencies and 263 npm packages where installed on my computer in less than a minute. Some of them were developed by big companies, but most of them were developed by one person like Azer.

To be more specific, my application heavily depends on module loader called SystemJS (see the package #259), which was developed by the guy named Guy Bedford, a respected developer who contributed tons of code to the open source community (btw, Guy is also the author of JSPM package manager). What if for whatever reason Guy will become as angry as Azer and will remove SystemJS from npm? This will affect thousands of projects. These projects won’t stop working, because SystemJS is already installed locally, but lots and lots of people will need to spend time and find a replacement or start fixing builds, bugs and adding features to the local version of SystemJS instead of working on their applications.

Some open source developer nicely illustrated a scenario when an 11-line library responsible for left-padding strings was removed from npmjs.org. Check this out:) David Haney raises the right question, “Have we forgotten how to program?

Part 3 OMG, what do I do?

Nothing. Just accept the reality of today’s open source world. At least I live with an assumption that any of the above 263 packages may stop being developed any moment, and the versions I have already installed are the last ones. At least I have the source code…

Update. NPM has addressed this issue, and Azer won’t be able to unpublish his packages unless they are younger than 24 hours.