angular2 – Michał Sakwa – Blog programistyczny

SignalR w ASP.NET Core i Angular – implementacja po stronie klienta

20 maja 2017 Michał Sakwa 1 komentarz

Dzisiaj pora na kolejny post dotyczący wykorzystania SignalR w ASP.NET Core. Ostatnim razem pisałem o implementacji po stronie serwera, tym razem zajmiemy się klientem aplikacji z wykorzystaniem frameworka Angular. Poniżej zamieszam odnośniki do powiązanych postów.

Część pierwsza: SignalR w ASP.NET Core – instalacja i uruchomienie

Część druga: SignalR w ASP.NET Core i Angular – przykładowa implementacja

Połączenie z serwerem

Gdy pisałem o konfiguracji, podałem na przykładzie w jaki sposób możemy połączyć się z serwerem. W tym celu wykorzystałem tzw. resolver w Angularze. Działa on na takiej zasadzie, że zapytanie wykonane w nim wykonuje się przed załadowaniem naszego komponentu, czyli np. planszy do gry. Poniżej przedstawię trochę inny przykład, gdzie ręcznie wywołujemy funkcję odpowiedzialną za połączenie. Na początek dodajemy fabrykę, która potrafi utworzyć nam nowe połączenie.

//Connection factory
import { SignalR, ISignalRConnection } from '../../lib/ng2-signalr';
import { Injectable } from '@angular/core';

@Injectable()
export class SignalRConnectionFactory {

    constructor(private _signalR: SignalR) { }

    createConnection(): Promise<ISignalRConnection> {
        return this._signalR.connect();
    }
}

//Connection factory

import { SignalR, ISignalRConnection } from '../../lib/ng2-signalr';

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

@Injectable()

export class SignalRConnectionFactory {

constructor(private _signalR: SignalR) { }

createConnection(): Promise<ISignalRConnection> {

return this._signalR.connect();

}

Fabrykę wykorzystujemy tylko do nawiązania nowego połączenia. Jeżeli będę chciał wykorzystywać inne konfigurację niż standardowa, nie chcę dodawać tego kodu do klasy odpowiedzialnej za samo przetwarzanie komunikatów.

Dwustronna komunikacja

Następnie dodaję serwis, który będzie przetrzymywał otwarte połączenie z serwerem oraz rozsyłał komunikaty do komponentów w Angularze. Cały klient będzie miał tylko jedno otwarte połączenie, ponieważ otwarcie takiego połączenia jest czasochłonne. Dodatkowo nie ma sensu obciążać serwera wieloma połączeniami w ramach jednej aplikacji klienckiej. Poniżej przedstawiam taką klasę, która obsługuje dwa typy zdarzeń:

Połączenie klienta do serwera, inicjowane prze klienta
Zmiana drużyny która wykonuje ruch, inicjowane prze serwer

//Game hub
import { Injectable } from '@angular/core';
import { Observable } from 'rxjs/Observable';
import { SignalRConnectionFactory } from '../../core/signalr/signalr-connection.factory';
import { ISignalRConnection, BroadcastEventListener } from '../../lib/ng2-signalr';
import { TeamChanged } from "../game.models";

@Injectable()
export class GameHubService {

    private connection: ISignalRConnection;    
    private onSubscribed$: BroadcastEventListener<string>;
    private onTeamChanged$: BroadcastEventListener<TeamChanged>;

    constructor(private connectionFactory: SignalRConnectionFactory) { }

    connect() {
        return Observable
            .fromPromise(this.connectionFactory
                .createConnection())
            .map((connection) => {
                this.connection = connection;
                return true;
            });
    }

    public subscribeToGame(gameId: number) : Promise<string> {
        return this.connection
            .invoke("Subscribe", gameId);
    }

    public teamChanged(onTeamChanged: (args: TeamChanged) => void) {
        if (!this.onTeamChanged$)
            this.onTeamChanged$ = this.connection.listenFor('TeamChanged');

        this.onTeamChanged$.subscribe(onTeamChanged);
    }

    public subscribed(onSubscribed: (message: string) => void) {
        if (!this.onSubscribed$)
            this.onSubscribed$ = this.connection.listenFor('Subscribed');
        
        this.onSubscribed$.subscribe(onSubscribed);
    }

    disconnect() {
        if (this.onSubscribed$)
            this.onSubscribed$.unsubscribe();
    }
}

//Game hub

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

import { Observable } from 'rxjs/Observable';

import { SignalRConnectionFactory } from '../../core/signalr/signalr-connection.factory';

import { ISignalRConnection, BroadcastEventListener } from '../../lib/ng2-signalr';

import { TeamChanged } from "../game.models";

@Injectable()

export class GameHubService {

private connection: ISignalRConnection;

private onSubscribed$: BroadcastEventListener<string>;

private onTeamChanged$: BroadcastEventListener<TeamChanged>;

constructor(private connectionFactory: SignalRConnectionFactory) { }

connect() {

return Observable

.fromPromise(this.connectionFactory

.createConnection())

.map((connection) => {

this.connection = connection;

return true;

});

}

public subscribeToGame(gameId: number) : Promise<string> {

return this.connection

.invoke("Subscribe", gameId);

}

public teamChanged(onTeamChanged: (args: TeamChanged) => void) {

if (!this.onTeamChanged$)

this.onTeamChanged$ = this.connection.listenFor('TeamChanged');

this.onTeamChanged$.subscribe(onTeamChanged);

}

public subscribed(onSubscribed: (message: string) => void) {

if (!this.onSubscribed$)

this.onSubscribed$ = this.connection.listenFor('Subscribed');

this.onSubscribed$.subscribe(onSubscribed);

}

disconnect() {

if (this.onSubscribed$)

this.onSubscribed$.unsubscribe();

}

Posiada ona kilka funkcji, omówię krótko każdą z nich.

connect – odpowiada za nawiązanie połączenia w ramach klienta. Połączenie jest przechowywanie w hubie i dzielone pomiędzy wszystkie komponenty.
disconnect– analogicznie do funkcji powyżej, zamyka ono połączenie z serwerem.
subscribeToGame – zdarzenie inicjowane po stronie klienta. Za jej pomocą dołączamy do kanału obecnej gry, dzięki temu otrzymamy komunikaty powiązane z grą.
subscribed – zdarzenie inicjowane po tym, jak nowy klient zapisze się do naszej gry.
teamChanged – zdarzenie inicjowane po tym, gdy jedna z drużyn wykona ruch, który spowoduje zmianę kolejki na inną drużynę.

Wykorzystanie serwisu w aplikacji

Gdy mamy już gotowy serwis, możemy wykorzystać go w naszej aplikacji. Na początek w głównym komponencie gry wywołujemy połączenie z serwerem.

//Main game component.
private connectToGame(gameId: number) {
    this.gameHub.connect()
        .mergeMap(connected => {
            if (connected) {
                return this.gameHub
                    .subscribeToGame(gameId)
            }
            Observable.throw("Could not connect to game hub");
        })
        .mergeMap(connectionId => {
            return this.gameService
                .getGame(gameId);
        })
        .subscribe(result => {
            this.game = result;
            this.board.initialize(this.game);
            this.sideNav.initialize(this.game);
        });
}

//Main game component.

private connectToGame(gameId: number) {

this.gameHub.connect()

.mergeMap(connected => {

if (connected) {

return this.gameHub

.subscribeToGame(gameId)

}

Observable.throw("Could not connect to game hub");

})

.mergeMap(connectionId => {

return this.gameService

.getGame(gameId);

})

.subscribe(result => {

this.game = result;

this.board.initialize(this.game);

this.sideNav.initialize(this.game);

});

}

Dzięki jej wywołaniu kolejno:

nawiązujemy połączenie z serwerem
zapisujemy się do gry
ładujemy dane gry
inicjalizujemy komponenty

Przykładem komponentu wykorzystującego ten serwis może być menu boczne aplikacji. Z jego poziomu drużyna może pominąć kolejkę, co będzie skutkowało zmianą obecnie aktywnej drużyny. Dodatkowo, gdy nastąpi zmiana drużyny, będziemy mogli nasłuchiwać na takie zdarzenie i wyświetlić drużynę wykonującą obecnie ruch.

//Sidenav component
import { Component, Input } from '@angular/core';

import { GameHubService, GameService } from '../services/game-services.imports';
import { Game, TeamChanged } from '../game.models';

@Component({
    selector: 'game-sidenav',
    templateUrl: './game-sidenav.component.html',
    styleUrls: ['./game-sidenav.component.scss']
})
export class GameSidenavComponent {

    game: Game;

    constructor(private gameHub: GameHubService,
        private gameService: GameService) { }

    private skipRound() {
        this.gameService
            .skipRound(this.game.id);
    }

    onTeamChanged(event: TeamChanged) {
        console.log(`Team changed. New team: ${event.newTeamId}. Previous team: ${event.lastTeamId}.`);
    }

    initialize(game: Game) {
        this.game = game;
        this.gameHub.teamChanged(this.onTeamChanged);
    }
}

//Sidenav component

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

import { GameHubService, GameService } from '../services/game-services.imports';

import { Game, TeamChanged } from '../game.models';

@Component({

selector: 'game-sidenav',

templateUrl: './game-sidenav.component.html',

styleUrls: ['./game-sidenav.component.scss']

})

export class GameSidenavComponent {

game: Game;

constructor(private gameHub: GameHubService,

private gameService: GameService) { }

private skipRound() {

this.gameService

.skipRound(this.game.id);

}

onTeamChanged(event: TeamChanged) {

console.log(`Team changed. New team: ${event.newTeamId}. Previous team: ${event.lastTeamId}.`);

}

initialize(game: Game) {

this.game = game;

this.gameHub.teamChanged(this.onTeamChanged);

}

Mamy tutaj trzy elementy na które należy zwrócić uwagę:

initialize – tutaj komponent zgłasza chęć otrzymywania komunikatów związanych ze zmianą aktywnej drużyny. teamChanged przyjmuje funkcję, która wykona się za każdym razem, gdy takie zdarzenie nastąpi.
onTeamChanged – wspomniana wyżej funkcja, która wykona się po wystąpieniu zdarzenia zmiany drużyny. Tutaj wyświetlony zostanie tylko komunikat w konsoli.
skipRound – pominięcie tury. Nie odwołujemy się tutaj bezpośrednio do SignalR’a, ale wykonujemy zwykłe zapytanie do serwera. On później roześle informacje o zmianie aktywnej drużyny

Podsumowanie

Wydaje mi się, że w tych trzech wpisach pokazałem, jak wykorzystać w naszej aplikacji bibliotekę SignalR i tworzyć aplikacje działające w czasie rzeczywistym. Zachęcam do wypróbowania jej we własnym zakresie. Jeżeli jednak miałbym być szczery, to na chwilę obecną proponuję wykorzystanie tej biblioteki w starszej wersji frameworka, chyba że tak jak ja chcecie po prostu pobawić się z nowszą wersją frameworka .NET. Co prawda, pojawił się już ASP.NET Core Preview 1, ale nie jest to wersja stabilna. Taka pojawi się dopiero pod koniec obecnego roku.

Zmienne środowiskowe w Angular

7 kwietnia 201710 kwietnia 2017 Michał Sakwa Zostaw komentarz

Często, gdy pracujemy nad naszą aplikacją musimy korzystać z innych adresów dla naszego API na produkcji, a innego lokalnie. Między innymi w takich przypadkach przychodzą nam z pomocą zmienne środowiskowe aplikacji. Dzisiaj chciałem pokazać jak w szybki sposób dodać możliwość obsługi zmiennych środowiskowych w naszej aplikacji wykorzystującej Angulara. Myślałem że będzie to coś, co jest dostępne out of the box, jednak nie zawsze tak jest. Jeżeli korzystacie z Angular-CLI, macie dostęp do nich w katalogu environments. Ja pokażę jak łatwo coś takiego zaimplementować w sytuacji, gdy nie mamy takiego udogodnienia. Mój przykład opiera się o aplikację, która powstała z szablonu dostępnego w dotnet CLI o którym pisałem w poprzednich postach. Moja aplikacja wykorzystuje Webpacka.

Implementacja serwisu z konfiguracją

Moje rozwiązanie nie jest idealne, ponieważ obsługuje jedynie dwie wersje aplikacji: lokalną czyli developerską, oraz produkcyjną. Jeżeli chcielibyśmy mieć możliwość obsługi innego środowiska, należy dodać kilka dodatkowych elementów, np. task w Gulpie, który podmieniałby nasze konfiguracje. Ja nie będę się tutaj rozpisywał na ten temat. Rozwiązanie składa się z kilku elementów. Na początek dodajemy plik app.config.ts, który przechowuje nasze zmienne.

//Application configuration
import { IConfig } from './app.iconfig';

export class DevConfig implements IConfig{
    public API_URL: string = "http://localhost:8080/api/";
}

export class ProdConfig implements IConfig {
    public API_URL: string = "http://production.site.com/api/";
}

//Application configuration

import { IConfig } from './app.iconfig';

export class DevConfig implements IConfig{

public API_URL: string = "http://localhost:8080/api/";

}

export class ProdConfig implements IConfig {

public API_URL: string = "http://production.site.com/api/";

}

Plik ten zawiera dwie klasy, które implementują interfejs IConfig. Dzięki temu nigdy nie przeoczymy żadnej zmiennej podczas dodawania konfiguracji. Poniżej przykład takiego intefejsu.

//Configuration interface

export interface IConfig {
    API_URL: string;
}

//Configuration interface

export interface IConfig {

API_URL: string;

}

Następnie dodajemy serwis, który będzie przekazywany wewnątrz aplikacji.

import { Injectable, isDevMode } from '@angular/core';

import { DevConfig, ProdConfig } from './app.config';
import { IConfig } from './app.iconfig';

@Injectable()
export class ConfigService {
    cfg: IConfig;
    constructor() {
        if (isDevMode())
            this.cfg = new DevConfig();
        else
            this.cfg = new ProdConfig();
    }

    get ApiUrl(): string {
        return this.cfg.API_URL;
    }
}

import { Injectable, isDevMode } from '@angular/core';

import { DevConfig, ProdConfig } from './app.config';

import { IConfig } from './app.iconfig';

@Injectable()

export class ConfigService {

cfg: IConfig;

constructor() {

if (isDevMode())

this.cfg = new DevConfig();

else

this.cfg = new ProdConfig();

}

get ApiUrl(): string {

return this.cfg.API_URL;

}

Tutaj, w zależności od tego, czy uruchomiliśmy aplikację lokalnie, czy na produkcji, tworzymy instancję klasy zawierającej nasze konfiguracje. Funkcja isDevMode sprawdza na jakim środowisku jesteśmy. W moim przypadku to Webpack uruchamia aplikację w odpowiednim trybie (podczas publishu na produkcję dodawana jest opcja env.prod, o tym więcej w dokumentacji dotnet CLI). W serwisie definiujemy tyle pól, ile potrzebujemy. Ja użyłem tutaj składni Typescipt’u, która pozwala na dodawanie getterów. Możemy taką klasę podzielić na mniejsze, jeżeli nie chcemy mieć jednej dużej klasy z całą konfiguracją. Taki serwis możemy wstrzykiwać w inne serwisy lub komponenty naszej aplikacji, oraz podmieniać ją na inną podczas testów.

Podsumowanie

Jest to rozwiązanie, które można jeszcze rozwinąć, ale obecnie spełnia moje wszystkie wymagania. Dodatkowo jest bardzo proste w implementacji i działa automatycznie, bez konieczności wykonywania innych operacji podczas rozwoju aplikacji, takich jak uruchamianie skryptów. Mam nadzieję, że komuś się przyda!

Routing w Angular2 – pierwsze kroki

2 kwietnia 201710 kwietnia 2017 Michał Sakwa Zostaw komentarz

Dzisiaj chce przedstawić jak w szybki sposób dodać routing do naszej aplikacji z frameworkiem Angular. Podczas tego procesu można natknąć się na kilka problemów, o których tutaj wspomnę. Do dzieła!

Routing krok po kroku

Moje przykłady podaję na projekcie, który powstał przy użyciu dotnet CLI. Po zainstalowaniu .NET Core SDK, w konsoli wpisujemy dotnet new --install Microsoft.AspNetCore.SpaTemplates::*. Daje nam to dostęp do wielu szablonów projektów. Następnie wpisujemy dotnet new angular i mamy gotowy projekt z którym można pracować! Po więcej informacji na ten temat odsyłam na bloga jednego z autorów tych szablonów, Steve’a Sandersona. Opisał to wszystko ładnie w tym poście.

Wracając do routingu, na początek definiujemy moduł, w którym powiemy aplikacji jak ma się zachowywać, gdy użytkownik będzie chciał wejść w podany przez niego adres na naszej stronie. Później zaimportujemy go do głównego modułu, który jest uruchamiany jako pierwszy. Moduł routingu składa się z kilku części. Na początek importujemy potrzebne komponenty:

--Import komponentów frameworka

import { NgModule } from '@angular/core';
import { Routes, RouterModule, PreloadAllModules } from '@angular/router';

import { MainComponent } from './main.component';
import { CatComponent } from './cat/cat.component';

--Import komponentów frameworka

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

import { Routes, RouterModule, PreloadAllModules } from '@angular/router';

import { MainComponent } from './main.component';

import { CatComponent } from './cat/cat.component';

Dekorator NgModule potrzebny jest do zdefiniowania modułu. Routes oraz RouterModule potrzebne są już do napisania kodu, który pozwoli nam na nawigację wewnątrz aplikacji. Następnie importowaliśmy komponenty, które sami dodaliśmy i chcemy wyświetlić. Następnie pora na przekazanie aplikacji jak ma się zachowywać, czyli definicję ścieżek.

-- Routes

const routes: Routes = [
    {
        path: '',
        component: MainComponent,
        children: [
            {
                path: '',
                component: CatComponent,
            },
            {
                path: 'dog',
                loadChildren: './dog/dog.module#DogModule'
            }
        ]
    }
];

@NgModule({
    imports: [RouterModule.forRoot(routes)],
    exports: [RouterModule]
})
export class AppRoutingModule { }

export const routableComponents = [
    MainComponent, CatComponent 
];

-- Routes

const routes: Routes = [

{

path: '',

component: MainComponent,

children: [

{

path: '',

component: CatComponent,

{

path: 'dog',

loadChildren: './dog/dog.module#DogModule'

}

]

}

];

@NgModule({

imports: [RouterModule.forRoot(routes)],

exports: [RouterModule]

})

export class AppRoutingModule { }

export const routableComponents = [

MainComponent, CatComponent

];

Import RouterModule.forRoot(routes) załatwi nam sprawę routingu.

Dzięki takiej definicji, po otwarciu aplikacji, od razu zobaczymy komponent CatComponent. Został on jawnie zaimportowany na starcie aplikacji. W tym przykładzie pokażę także jeszcze jedną ważną sprawę na którą trzeba zwrócić uwagę, w momencie gdy dodajemy routing do naszej aplikacji. CatComponent został pobrany od razu gdy weszliśmy na stronę aplikacji, mogło to wpłynąć na czas otwarcia aplikacji. Takie podejście nazywamy EagerLoading. Jeżeli byłby on duży, mogłoby to w znaczący sposób wpłynąć na to, jak użytkownik będzie odbierał naszą aplikację. Z kolei DogModule zostanie załadowany dopiero wtedy, gdy będziemy chcieli wejść do niego. Będzie wtedy można zauważyć małe opóźnienie przed otwarciem tej strony. Ta metoda z kolei nazywana jest LazyLoading. Dzięki temu, że komponent załadowany będzie później, cała strona będzie ładować się szybciej. Coś za coś, idziemy tutaj na kompromis. Jednak nie musi tak być. Wcześniej w imporcie komponentów z @angular/router zaimportowałem jeszcze klasę PreloadAllModules. Jeżeli definicję modułu zmienimy na następującą:

--Lazy loading 

@NgModule({
    imports: [RouterModule.forRoot(routes, { preloadingStrategy: PreloadAllModules })],
    exports: [RouterModule]
})
export class AppRoutingModule { }

--Lazy loading

@NgModule({

imports: [RouterModule.forRoot(routes, { preloadingStrategy: PreloadAllModules })],

exports: [RouterModule]

})

export class AppRoutingModule { }

Moduł DogModule , oraz wszystkie inne które tak dodamy do routingu pobrane zostaną w tle po uruchomieniu aplikacji. Dzięki temu zyskujemy zarówno szybkość ładowania całej aplikacji, jak i responsywność podczas przechodzenia pomiędzy stronami. Ważna uwaga: żeby LazyLoading działał w projekcie wykorzystującym Webpacka, musimy zainstalować paczkę angular-router-loader, a następnie użyć ją w pliku webpack.config.js podczas konfiguracji plików .ts.

-- angular-router-loader

--config...
module: {
   rules: [
    {
     test: /\.ts$/,
     include: /ClientApp/,
     use: [
       'awesome-typescript-loader?silent=true',
       'angular2-template-loader',
       'angular-router-loader'
     ]
    },
--config...
 },

-- angular-router-loader

--config...

module: {

rules: [

{

test: /\.ts$/,

include: /ClientApp/,

use: [

'awesome-typescript-loader?silent=true',

'angular2-template-loader',

'angular-router-loader'

]

--config...

Kolejnym istotnym punktem jest stała routableComponents którą eksportujemy razem z modułem. Dzięki temu że tutaj dodajemy moduły, nie trzeba będzie ich na nowo importować w głównym module.Należy pamiętać, że każdy komponent który jest używany musi być dodany do declarations.

-- Main module of application
import { NgModule } from '@angular/core';
import { UniversalModule } from 'angular2-universal';

import { AppRoutingModule, routableComponents } from './app.routing.module';

@NgModule({
    imports: [
        UniversalModule,
        AppRoutingModule
    ],
    declarations: [
        routableComponents
    ],
    bootstrap: [MainComponent],
})
export class AppModule { }

-- Main module of application

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

import { UniversalModule } from 'angular2-universal';

import { AppRoutingModule, routableComponents } from './app.routing.module';

@NgModule({

imports: [

UniversalModule,

AppRoutingModule

declarations: [

routableComponents

bootstrap: [MainComponent],

})

export class AppModule { }

Teraz pozostaje tylko dodać moduł DogModule:

--Dog Module

import { NgModule } from '@angular/core';
import { DogRoutingModule, routableComponents } from './dog.routing.module';

@NgModule({
    imports: [DogRoutingModule],
    declarations: [routableComponents]
})
export class DogModule { }

--Dog Module

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

import { DogRoutingModule, routableComponents } from './dog.routing.module';

@NgModule({

imports: [DogRoutingModule],

declarations: [routableComponents]

})

export class DogModule { }

Oraz moduł routingu DogRoutingModule:

--Dog routing module

import { NgModule } from '@angular/core';
import { Routes, RouterModule } from '@angular/router';

import { DogComponent } from './dog.component';

const routes: Routes = [{ path: '', component: DogComponent }];

@NgModule({
    imports: [RouterModule.forChild(routes)],
    exports: [RouterModule]
})
export class TutorialRoutingModule { }

export const routableComponents = [DogComponent];

--Dog routing module

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

import { Routes, RouterModule } from '@angular/router';

import { DogComponent } from './dog.component';

const routes: Routes = [{ path: '', component: DogComponent }];

@NgModule({

imports: [RouterModule.forChild(routes)],

exports: [RouterModule]

})

export class TutorialRoutingModule { }

export const routableComponents = [DogComponent];

Dla takich małych modułów może się wydawać, że to spory narzut, jeżeli chodzi o ilość pracy. Ale jeżeli nasze komponenty są bardziej rozbudowane i mają swoje ścieżki podrzędne, dzięki temu nasz główny komponent nie rozrośnie się do niebotycznych rozmiarów. Dodajemy także separację do logiki naszej aplikacji, co wpływa na przejrzystość kodu.

Na koniec dodajemy nasz MainComponent, czyli główną stronę aplikacji:

--Main component
import { Component } from '@angular/core';

@Component({
    selector: 'app',
    templateUrl: './main.component.html'
})
export class MainComponent { }

--Main component

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

@Component({

selector: 'app',

templateUrl: './main.component.html'

})

export class MainComponent { }

Oraz szablon dla tego komponentu:

-- Main component template

<div>
 <h1>My app</h1>
 <nav>
  <ul>
   <li><a [routerLink]="['/']" >Cats</a></li>
   <li><a [routerLink]="['/dog']" >Dogs</a></li>
  </ul>
 </nav>

 <router-outlet></router-outlet>
</div>

-- Main component template

<div>

<nav>

<ul>

</ul>

</nav>

<router-outlet></router-outlet>

</div>

W szablonie możemy zobaczyć dwa ważne elementy: routerLink oraz router-outlet. routerLink to odpowiednik ng-href z pierwszego Angulara, czyli po prostu doda nam odpowiedni adres dla odnośnika na podstawie podanej nazwy ścieżki. router-outlet to najważniejszy element tutaj, czyli miejsce gdzie wstawione zostaną nasze komponenty, w poprzedniej wersji ng-view. Dodatkowo należy pamiętać także o dodaniu do znacznika head wartość <base href="/">, bez tego routing nie zadziała.

Podsumowanie

Przedstawiłem tutaj jedynie część możliwości jakie daje nam Angular jeżeli chodzi o routing. W kolejnych postach przedstawię bardziej skomplikowane przypadki: przekazywanie parametrów w adresie scieżki, RouteGuards, czyli mechanizm pozwalający na np. blokowanie wejścia do niektórych fragmentów aplikacji oraz wykorzystanie więcej niż jednego router-outlet.

Wprowadzenie do Angular 2

22 marca 201710 kwietnia 2017 Michał Sakwa Zostaw komentarz

Dzisiaj chciałem opisać w kilku punktach najważniejsze cechy frameworka Angular dla użytkowników, którzy nie mieli z nim jeszcze styczności. Na wstępnie trzeba zaznaczyć, że twórcy odeszli od nazwy Angular 2 (głównie z powodu wporwadzenia Semantic Versioning). Od teraz wersje 1.x.x nazywamy AngularJS, a do wydań oznaczonych jako 2.x.x i dalej będziemy używali krótkiej nazwy Angular. Można o tym poczytać tutaj.

Czym jest Angular?

Angular to framework służący do rozwijania aplikacji webowych oraz na platformy mobilne. Nie jest to kolejna wersja swojego poprzednika, został napisany całkowicie od nowa. Wersje te nie są ze sobą kompatybilne. Na pierwszy rzut oka widać, że dwójka bardzo różni się od swojego pierwowzoru. Poniżej postaram się przedstawić te różnice i pokazać, że pomimo tego że są to całkiem inne narzędzia, developerzy korzystający z jedynki będą mogli wykorzystać część swojego doświadczenia podczas pracy z nowym wydaniem.

Wybór języka

Twórcy Angulara dają nam wybór w kwestii języka, którym będziemy się posługiwać podczas pisania naszych aplikacji. Do wyboru mamy następujące opcje:

ES5, czyli po prostu JavaScript. Ten sam, który był najczęściej wykorzystywany podczas rozwoju aplikacji w starym AngularJS.
ES6/ES2015, jest to rozszerzenie standardowego języka JavaScript, dodające nowe funkcje. Nie wszystkie przeglądarki go wspierają, dlatego podczas rozwoju aplikacji wykorzystujących ES6 należy korzystać z kompilatorów np. Babel.
TypeScript wprowadza do JavaScript’u jeszcze więcej możliwośći np. typy, dzięki czemu łatwiej wyłapywać błędy podczas pisania aplikacji. Jest rozszerzeniem ES6, i tak samo jak on, wymaga kompilatora. Więcej na jego temat można poczytać w tym miejscu.
Dart jest to język programowania stworzony przez firmę Google. Po więcej informacji na temat tego języka zapraszam tutaj.

W dalszej części tego artykuły będę posługiwał się przykładami napisanymi w TypeScripcie.

Moduły

Obie wersje Angulara przedstawiają koncepcję modułu, jako swego rodzaju punkt wejścia dla naszej aplikacji. W pierwszej wersji definiowaliśmy go w następujący sposób:

(function () {
  angular
    .module('app', []);
})();

(function () {

angular

.module('app', []);

})();

W nawiasach kwadratowych podawaliśmy zależności z których chcieliśmy korzystać w naszej aplikacji. Następnie musieliśmy oznaczyć w HTMLu gdzie nasza aplikacji ma się znajdować:

<html ng-app="app">

1	<html ng-app="app">

Teraz definiujemy go w następujący sposób:

import { NgModule } from '@angular/core';
import { BrowserModule  } from '@angular/platform-browser';

import { MyComponent } from './my.component';

@NgModule({
  imports: [BrowserModule],
  declarations: [...],
  bootstrap: [...],
})
export class AppModule { }

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

import { BrowserModule } from '@angular/platform-browser';

import { MyComponent } from './my.component';

@NgModule({

imports: [BrowserModule],

declarations: [...],

bootstrap: [...],

})

export class AppModule { }

Moduł tym razem służy do oznaczenia z jakich elementów nasza aplikacja będzie się składała. Do tego celu służy dekorator @NgModule, który używamy w połączeniu z klasą modułu. Wskazujemy, z jakich modułów dostarczanych z zewnątrz będziemy korzystać (imports) np. RouterModule lub BrowserModule. Deklarujemy (declarations) z jakich komponentów będziemy korzystać w naszej aplikacji. Może się ona składać z setek lub tysięcy małych komponentów. Definiujemy tutaj także komponent wejściowy przy użyciu słowa bootstrap. Komponent ten zostaje uruchomiony jako pierwszy. W górnej części tego pliku znajdują się importy, czyli mechanizm TypeScriptu, który pozwala na użycie innych bibliotek w naszej aplikacji. Modułom dokładniej przyjrzymy się w kolejnych postach.

Kontrolery i Komponenty

Angular odszedł od koncepcji kontrolerów, używanych w pierwszej wersji. Kontrolery były definiowane w widoku:

  <div ng-controller="MyController as ctrl">
    <h3>{{ctrl.title}}</h3>
  </div>

<h3>{{ctrl.title}}</h3>

</div>

Następnie dodawany był kod, który przedstawiał jego logikę.

(function () {
  angular
    .module('app', [])
    .controller('MyController', MyController);

  function MyController() {
    var ctrl = this;
    ctrl.title = 'My title';
  }
})();

(function () {

angular

.module('app', [])

.controller('MyController', MyController);

function MyController() {

var ctrl = this;

ctrl.title = 'My title';

}

})();

Obecnie w widoku używamy tylko nazwy naszego komponentu np.:

<my-component></my-component>

1	<my-component></my-component>

Sam komponent zaś definiuje jego logikę oraz wygląd:

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

@Component({
  selector: 'my-component',
  template: `
    <div>
         <h3>{{title}}</h3>
    <div>
  `
})
export class MyComponent {
  title = 'My title';
}

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

@Component({

selector: 'my-component',

template: `

<div>

<h3>{{title}}</h3>

<div>

})

export class MyComponent {

title = 'My title';

}

Importujemy tutaj dekorator komponentu, który pozwala nam na jego definicje. Wskazujemy selector, który będzie wskazywał na nasz komponent w HTMLu, jego wygląd poprzez template (można oczywiście dodać ten szablon w osobnym pliku), oraz logikę komponentu w klasie.

Dyrektywy

Dyrektywy dostępne w Angularze uległy znacznym zmianom, ale dalej są obecne. Popularne w pierwszej wersji dyrektywy to na przykład ng-repeat oraz ng-if. W nowej wersji zostały one zastąpione przez *ngFor oraz *ngIf. Nazywamy je Structural directives, ponieważ wpływają na strukturę naszej strony (powielają elementy, usuwają etc). Są poprzedzane znakiem *. Przykłady dla AngularJS:

<!-- AngularJS -->
<div ng-if="cats.length">
    <h1>List of cats</h1>
    <ul>
        <li ng-repeat="cat in cats">{{cat.name}}</li>
    </ul>
</div>

<ul>

</ul>

</div>

A teraz nowa wersja:

<!-- Angular -->
<div *ngIf="cats.length">
    <h1>List of cats</h1>
    <ul>
        <li *ngFor="let cat of cats">{{cat.name}}</li>
    </ul>
</div>

<ul>

</ul>

</div>

Różnice nie są wielkie, oprócz samej składni, dla *ngFor dochodzi także słowo kluczowe let, które definiuje zmienną lokalną.
Oprócz tego, w Angularze usunięte zostają inne dyrektywy, takie jak ng-src, ng-style, ng-href. Podobnie jest z dyrektywami, które służyły do obsługi zdarzeń np. ng-click czy ng-focus. Zamiast tego, możemy podpiąć się bezpośrednio do atrybutów lub zdarzeń w HTML, na przykład:

<!-- Angular -->
<div [style.visibility]="story ? 'visible' : 'hidden'">
  <img [src]="imagePath">
  <br/>
  <a [href]="link">{{story}}</a>
  <button (click)="doStuff()">Ok</button>
</div>

<br/>

<a [href]="link">{{story}}</a>

</div>

Do właściwości podpinamy się poprzez nawiasy kwadratowe [], a do zdarzeń nawiasy okrągłe (). Daje nam to dużo możliwości, ponieważ nie musimy już polegać na tym, czy interesująca nas dyrektywa istnieje. Zamiast tego korzystamy po prostu z atrybutów oraz zdarzeń w HTMLu.

Data binding

Tutaj także jest wiele podobieństw, chociaż ponownie składnia trochę się różni. O ile dalej możemy korzystać z nawiasów klamrowych {{...}} aby wyświetlić dane lub tworzyć wyrażenia, to two-way oraz one-way binding znany z poprzednika wygląda trochę inaczej. Działa tutaj ten sam mechanizm, który pokazałem w dyrektywach. One-way binding, w którym zmiany wychodzą z widoku do kodu, odbywa się poprzez użycie nawiasów okrągłych (). Tutaj przykładem mogą być eventy, gdzie zdarzenie wysyła nam informacje do naszej klasy. Wysyłanie danych z klasy do widoku odbywa się poprzez nawiasy kwadratowe [] (wykorzystując atrybuty, klasy, style, właściwości) lub klamrowe {} (mechanizm ten nazywa się Interpolation). Two-way binding, czyli przesył danych w obie strony, odbywa się zarówno przy użyciu nawiasów kwadratowych i okrągłych [(...)]. Składnia ta wydaje się dziwna, ale jest w 100% spójna z tym co powiedzieliśmy wcześniej: dane zarówno wysyłane są z widoku do kodu, oraz z kodu do widoku.

<div>
    <input [(ngModel)]="myObject.name">
</div>

<div>

</div>

Zamiast nawiasów mamy możliwość korzystania z prefixów bind- lub on- dla komunikacji w jedną stronę, lub bindon- w obie strony. Przykłady:

<div>
    <h3 bind-innerText="name"></h3>
    <input bindon-ngModel="name">
    <button on-click="doStuff()">Ok</button>
</div>

<div>

</div>

Serwisy

W pierwszym Angularze mieliśmy do wyboru kilka metod, które pozwalały na dodawanie serwisów do aplikacji. Dzięki nim byliśmy w stanie wyciągnąć w jedno miejsce logikę, która powtarzała się w wielu fragmentach aplikacji lub pozwalały na komunikację pomiędzy różnymi jej elementami. Czasem pojawiał się problem: którą metodę wybrać? Do wyboru były popularne Factory, Service czy Provider, a także Constants oraz Values. Ten element został całkowicie zmieniony w nowej wersji. Zamiast wybierać dostępne mechanizmy, po prostu dodajemy klasę, która ma w sobie określoną funkcjonalność, a następnie używamy jej w dowolnym miejscu.

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

@Injectable()
export class CatsService {
  getCats = () => [
    { id: 1, name: 'Garfield' },
    { id: 2, name: 'Mruczek' }
  ];
}

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

@Injectable()

export class CatsService {

getCats = () => [

{ id: 1, name: 'Garfield' },

{ id: 2, name: 'Mruczek' }

];

}

Należy jedynie dodać dekorator @Injectable, który pozwoli na wstrzyknięcie naszego serwisu np. do komponentu. O tym opowiem w kolejnym akapicie.

Dependency Injection

Dependency Injection to wzorzec architektoniczny, polegający na wstrzykiwaniu zależności do naszego kodu. Jeżeli chcemy odseparować z komponentu logikę np. pobierania użytkowników z bazy danych, a w samym komponencie zająć się jedynie ich wyświetlaniem, możemy zrobić to w łatwy sposób. Pobieranie danych wyciągamy do Serwisu, czyli innej klasy, a w komponencie wskazujemy na to, że potrzebujemy dostać obiekty do wyświetlenia. W module dodajemy komponent i serwis:

import { NgModule } from '@angular/core';
import { BrowserModule  } from '@angular/platform-browser';

import { CatsComponent } from './cats.component';
import { CatsService } from './cats.service';

@NgModule({
  imports: [BrowserModule],
  declarations: [CatsComponent],
  providers: [CatsService],
  bootstrap: [CatsComponent],
})
export class AppModule { }

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

import { BrowserModule } from '@angular/platform-browser';

import { CatsComponent } from './cats.component';

import { CatsService } from './cats.service';

@NgModule({

imports: [BrowserModule],

declarations: [CatsComponent],

providers: [CatsService],

bootstrap: [CatsComponent],

})

export class AppModule { }

W komponencie wskazujemy, że potrzebujemy serwisu (używamy tutaj CatsService z poprzedniego akapitu), który zwróci nam nasze obiekty do wyświetlenia:

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

import { CatsService } from './cats.service';

@Component({
  selector: 'my-cats',
   templateUrl: './cats.component.html',
})
export class CatsComponent {
  cats = this.catsService.getVehicles();

  constructor(private catsService: CatsService) { }
}

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

import { CatsService } from './cats.service';

@Component({

selector: 'my-cats',

templateUrl: './cats.component.html',

})

export class CatsComponent {

cats = this.catsService.getVehicles();

constructor(private catsService: CatsService) { }

}

W ten sposób nasz komponent będzie w stanie wyświetlić listę naszych kotów, bez wiedzy skąd trzeba je pobrać!

Podsumowanie

Oczywiście, to co tutaj przedstawiłem to tylko część dobrodziejstw które oferuje nam Angular. Mamy jeszcze Routing, który został znacznie uproszczony, filtry, które teraz nazywają się Pipes oraz wiele innych. Wydaje mi się, że pomimo wielu różnic które pojawiły się w nowej wersji (wiele z nich moim zdaniem dobrych), kilka konceptów znanych z pierwszego wydania tego frameworka można zastosować w nowych aplikacjach, które będą już korzystały z najnowszej edycji. Dzięki temu próg wejścia w tą technologię jest dla weteranów AngularJS znacznie mniejszy.

Na dzisiaj to tyle. Tematy, które nie zostały tutaj poruszone na pewno pojawią się w przyszłości. Postaram się także rozwinąć bardziej szczegółowo to, o czym już mówiłem. Zapraszam do komentowania!