angular4 – 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.