Basisrezepte

In diesem Kapitel befinden sich Basisrezepte, die in späteren Rezepten als Zutaten benötigt werden. Der Code, der in den Lösungen gezeigt wird, kann kopiert und angepasst werden, um die Lösungen für weitere Rezepte zu implementieren. Es wird empfohlen, dieses Kapitel als Erstes zu lesen, um einen Überblick zu bekommen und sich erst dann mit den weiteren Rezepten zu beschäftigen. Das Ziel des Kapitels ist, einen schnellen Einstieg in die Grundlagen und die Hauptbauteile von Angular 2 Anwendungen zu ermöglichen.

Entwicklungsprozess für Angular 2 Projekte

Problem

Ich möchte einen möglichst einfachen Weg haben, ein Angular 2 Projekt zu initialisieren, zu bauen und das Resultat im Browser anzuschauen.

Zutaten

  • Node.js
  • npm
  • angular-cli

Lösung

Der derzeit einfachste Weg, ein Angular 2 Projekt zu starten, zu bauen und sich das Resultat im Browser anzuschauen, ist ein Tool namens “angular-cli”. Das Tool befindet sich noch im beta-Stadium. Nichtsdestotrotz werden wir es nutzen, da die Alternative (alles selbst einzurichten) sehr aufwändig ist.

Als Erstes müssen wir Node.js und npm installieren, damit wir im zweiten Schritt angular-cli installieren können. Am einfachsten können wir Node.js installieren, indem wir es von der offiziellen Webseite herunterladen. Bei der Installation von Node.js, wird npm mit installiert. Jetzt können wir angular-cli installieren mit:

1 npm install -g angular-cli@1.0.0-beta.19

Wir installieren angular-cli global und können es daher in jedem Angular 2 Projekt nutzen.

Jetzt können wir ein Projekt initialisieren. Dafür gibt es die Kommandos “new” und “init”.

1 ng new projektName --skip-git

Dieses Kommando wird ein Verzeichnis mit dem Namen “projektName” erzeugen. Darin wird das Tool die nötigen Verzeichnisse/Dateien anlegen und alle Abhängigkeiten mittels npm installieren. Falls --skip-git nicht angegeben wird, wird angular-cli auch ein git-Repository anlegen, vorausgesetzt, dass wir nicht schon in einem git-Repository sind.

Das init-Kommando macht das gleiche wie das new-Kommando aber für ein existierendes Verzeichnis.

1 ng init --name projektName

Falls --name projektName nicht angegeben wird, wird der Name des Verzeichnisses als Projektname benutzt.

Anwendung starten

Nachdem alle Abhängigkeiten installiert worden sind, können wir die Anwendung starten. Angular-cli hat einen eingebauten HTTP-Server, den wir dafür nutzen können. Um den Server zu starten, müssen wir im Projekt-Verzeichnis (das mit der package.json-Datei) folgendes Kommando aufrufen:

1 ng serve

In der Konsole steht dann, zu welcher URL wir navigieren müssen, um die Demo-Anwendung von angular-cli zu sehen (Zeile: “Serving on http://…”). Das Nette an diesem Webserver ist der Live-Reload-Support. Das heißt, wenn wir Änderungen im Code machen, werden diese sofort im Browser sichtbar, ohne dass wir das Projekt selbst erneut kompilieren müssen.

Diskussion

Alle Rezepte in diesem Buch wurden mit angular-cli initialisiert. Es ist also nicht nötig ng init oder ng new aufzurufen. Es reicht, wenn npm install aufgerufen wird, um die Abhängigkeiten zu installieren. Danach können wir, wie oben gezeigt, mit ng serve die Anwendung starten.

Da das Tool eine eigene Meinung hat, wie die Verzeichnisstruktur, eine Komponente usw. auszusehen hat, wurden aus den Code-Beispielen ein paar Verzeichnisse/Dateien, die nicht für das jeweilige Beispiel relevant sind, gelöscht bzw. angepasst. Wir wollen nicht, dass überflüssige Verzeichnisse, Dateien und Code-Zeilen uns vom eigentlichen Thema eines Rezeptes ablenken. Wir schauen uns also nur die relevanten Dateien für ein Rezept an und ignorieren den Rest. Auch gewisse Abhängigkeiten wurden aus der package.json-Datei entfernt, um die Installationszeit zu verkürzen. Es ist also möglich, dass nicht alle angular-cli Kommandos mit jedem Rezept funktionieren. Für die meisten Rezepte ist das src-Verzeichnis am Wichtigsten. Darin befindet sich der Code für eine Angular 2 Anwendung. Mehr Informationen über die Verzeichnisstruktur gibt es in Appendix-B: angular-cli.

Weitere Ressourcen

Angular 2 Anwendung

Problem

Ich möchte von Null auf eine Angular 2 Anwendung implementieren.

Zutaten

  • angular-cli
  • app.module.ts-Datei, die das Hauptmodul der Anwendung definiert
  • NgModule-Decorator für die Moduldefinition (@NgModule)
  • app.component.ts-Datei, die die Hauptkomponente der Anwendung definiert
  • Component-Decorator für die Komponentendefinition (@Component)
  • main.ts-Datei. Diese Datei initialisiert (bootstrap) die Angular 2 Anwendung
  • index.html-Datei, um die nötigen Bibliotheken zu laden und die Anwendung zu starten

Lösung

Als Erstes werden wir uns die app.component.ts-Datei anschauen. Diese Datei befindet sich im Unterverzeichnis “src/app”.

app.component.ts
1 import { Component } from '@angular/core';
2 
3 @Component({
4   selector: 'app-root',
5   template: '<div>Hello World!</div>'
6 })
7 export class AppComponent {}

Erklärung:

Diese Datei definiert die Haupt- und in diesem Fall einzige Komponente unserer Anwendung. Sie ist ein ECMAScript-Modul (ESM). Jede Datei, die das Keyword import bzw. das Keyword export beinhaltet ist ein ESM.

  • Zeile 1: Hier importieren wir die nötigen Abhängigkeiten aus dem @angular/core-Paket. Dafür nutzen wir eine ESM import-Anweisung
  • Zeilen 3-6: Hier definieren wir eine Komponente mittels TypeScript-Decorator
    • Zeile 4: Die selector-Eigenschaft definiert das Tag in dem die Komponente gerendert werden soll. Hier wird die Komponente im Tag <app-root> gerendert
    • Zeile 5: Der Wert der template-Eigenschaft ist ein Angular-Template. Es wird später von Angular kompiliert und zwischen <app-root> und </app-root> hinzugefügt. Das kompilierte Angular-Template wird als “View” der Komponente bezeichnet
  • Zeile 7: Definiert eine TypeScript-Klasse, die die Logik für die Komponente beinhaltet. In diesem Fall ist die Klasse leer, da wir keine Logik benötigen
    • Gleichzeitig wird die Klasse (und somit die Komponente) mit einer ESM export-Anweisung exportiert

Jetzt sehen wir uns unser Hauptmodul (app.module.ts) an. Diese Datei befindet sich auch im Unterverzeichnis “src/app”.

app.module.ts
 1 import { NgModule } from '@angular/core';
 2 import { BrowserModule } from '@angular/platform-browser';
 3 
 4 import { AppComponent } from './app.component';
 5 
 6 @NgModule({
 7   imports: [ BrowserModule ],
 8   declarations: [ AppComponent ],
 9   bootstrap: [ AppComponent ]
10 })
11 export class AppModule { }

Erklärung:

  • Zeile 1: Hier wird der NgModule-Decorator aus @angular/core importiert
  • Zeile 2: Importiert das BrowserModule aus @angular/platform-browser. Dieses bietet uns Funktionaliät an, die wir benötigen, wenn wir Angular im Browser nutzen wollen
  • Zeilen 6-10: Hier wird unser Modul mittels @NgModule definiert
    • Zeile 7: Damit wir funktionalität von anderen Angular-Module in unser Modul nutzen können, müssen diese im imports-Array stehen
    • Zeile 8: Hier wird unsere Komponente deklariert. Somit ist das Modul und Angular von ihre Existenz informiert
    • Zeile 9: Hier wird die Komponente definiert, die bei der Initialisierung der Anwendung als erstes initialisiert werden soll

Als nächstes werden wir uns die main.ts-Datei anschauen. Diese befindet sich im Unterverzeichnis “app”.

main.ts
1 import './polyfills.ts';
2 
3 import { platformBrowserDynamic } from '@angular/platform-browser-dynamic';
4 
5 import { AppModule } from './app';
6 
7 platformBrowserDynamic().bootstrapModule(AppModule);

Erklärung:

  • Zeile 1: Hier importieren wir eine Datei mit verschiedenen Polyfills die von Angular gebraucht werden. Falls nötig, können in dieser Datei weitere Polyfills für unsere Anwendung definieren
  • Zeile 5: Hier importieren wir unser Hauptmodul. Wenn wir aus einem Verzeichnis importieren (hier “./app”), wird automatisch in der index.ts-Datei nach dem passendem Namen (hier “AppModule”) gesucht. Diese Datei ist ein sogenanntes barrel und wird von angular-cli automatisch angelegt
  • Zeile 7: Das Hauptmodul wird der Initialisierungsfunktion (bootstrapModule) übergeben und die Anwendung wird initialisiert

Als Letztes schauen wir uns die index.html-Datei an. Diese befindet sich ebenfalls im Unterverzeichnis “app”.

index.html
1 ...
2 
3 <body>
4   <app-root>Loading...</app-root>
5 </body>

Erklärung:

Wir schauen uns nur ein Ausschnitt aus der Datei an und zwar den Teil, in dem unsere Anwendung gerendert wird (Zeile 4). Initial wird “Loading…” angezeigt bis Angular initialisiert wird.

Um den Beispiel-Code aus Github im Browser anzuzeigen, müssen wir mittels npm install die Abhängigkeiten installieren und dann mit ng serve den Server starten.

Diskussion

Unser Code-Beispiel nutzt Angular im Entwicklungsmodus. Darüber informiert uns auch Angular, wenn wir im Browser die Konsole offen haben. Im Rezept “Angular 2 in Produktion nutzen” wird beschrieben wie wir Angular 2 im Produktionsmodus nutzen können.

Angular-Plattformen

Angular definiert verschiedene sogenannte Plattformen, die eine Umgebung schaffen in der eine Angular-Anwendung laufen kann. Diese Plattformen definieren z. B. wann die Angular-Templates kompiliert werden oder stellen z. B. DOM-Anbindungen zur Verfügung. Je nach dem wo die Anwendung laufen soll, z. B. im Browser, Server usw. gibt es auch eine entsprechendes Plattform-ES-Modul/-npm-Paket. Wir haben “platform-browser-dynamic” verwendet weil unsere Anwendung im Browser mit Just-In-Time (JIT) Kompilierung arbeiten soll. In diesem Fall bedeutet JIT, dass die Templates im Browser kompiliert werden. Angular bietet auch die Option, Templates Ahead-Of-Time (AOT) beim bauen der Anwendung zu kompilieren. In so einem Fall würden wir in der main.ts “platform-browser” statt “platform-browser-dynamic” verwenden.

Bootstrap

Der/die eine oder andere Leser/Leserin mag sich jetzt fragen, warum wir nicht einfach eine TypeScript-Datei mit der Moduldefinition und der bootstrap-Funktion haben. Natürlich hätten wir das auch machen können, aber die Aufspaltung in zwei Dateien bringt ein Vorteil mit sich. Wir vermischen die Moduldefinition nicht mit der Initialisierung der Anwendung. Die Moduldefinition ist allgemein und könnte auf unterschiedlichen Plattformen verwendet werden. Die bootstrap-Funktion ist Plattformspezifisch. Jede Plattform hat eine eigene bootstrap-Funktion, die genau weiß wie die Anwendung initialisiert werden soll, damit diese auch auf der Plattform laufen kann. Das heißt, dass wir theoretisch mehrere Initialisierungsdateien haben könnten (z. B. eine für den Browser und eine für den Server), die das gleiche Hauptmodul verwenden. Die Aufspaltung erhöht also die Wiederverwendbarkeit des Moduls.

Code

Code auf Github

Live Demo auf angular2kochbuch.de

Weitere Ressourcen

  • Informationen über ECMAScript-Module
  • Weitere Eigenschaften des Component-Decorators sind auf der Angular 2 Webseite beschrieben: @Component
  • Weitere Eigenschaften des NgModule-Decorators sind auf der Angular 2 Webseite beschrieben: @NgModule
  • Weitere Informationen über Angular-Module gibt es hier
  • Mehr Informationen zu Decorators in TypeScript gibt es hier
  • Weitere Informationen zu Angular-Templates gibt es in Appendix A: Template-Syntax

Eine Komponente definieren

Problem

Ich möchte weitere Komponenten nutzen, um meine Anwendung modularer zu gestalten.

Zutaten

  • Angular 2 Anwendung
  • Datei für die neue Komponente (second.component.ts)
  • Anpassungen an der Hauptkomponente (app.component.ts), die wir im Rezept “Angular 2 Anwendung” definiert haben
  • Anpassungen am Hauptmodul (app.module.ts)

Lösung

second.component.ts
1 import { Component } from '@angular/core';
2 
3 @Component({
4   selector: 'app-second',
5   template: '<div>My Name is ...</div>'
6 })
7 export class SecondComponent {}

Erklärung:

Diese Datei ist auch ein ESM und beinhaltet die Komponentendefinition für eine Komponente namens “SecondComponent”. Genau wie unsere Hauptkomponente definiert diese die selector- und template-Eigenschaften.

app.component.ts
1 import { Component } from '@angular/core';
2 
3 import { SecondComponent } from './second.component';
4 
5 @Component({
6   selector: 'app-root',
7   template: '<div>Hello World!</div><app-second></app-second>'
8 })
9 export class AppComponent {}

Erklärung:

  • Zeile 3: Hier importieren wir unsere zweite Komponente
  • Zeile 7: Wir haben den Tag <app-second></app-second> zum Angular-Template hinzugefügt. Zu beachten ist, dass der Tag-Name gleich dem Selektor in Zeile 4 in der second.component.ts-Datei sein muss
app.module.ts
 1 import { NgModule } from '@angular/core';
 2 import { BrowserModule } from '@angular/platform-browser';
 3 
 4 import { AppComponent }  from './app.component';
 5 import { SecondComponent } from './second.component';
 6 
 7 @NgModule({
 8   imports: [ BrowserModule ],
 9   declarations: [ AppComponent, SecondComponent ],
10   bootstrap: [ AppComponent ]
11 })
12 export class AppModule { }

Erklärung:

  • Zeile 9: Hier deklarieren wir unsere neue Komponente, so dass wir diese in “AppComponent” nutzen können

Diskussion

Jede Komponente, Direktive und Pipe muss in genau einem Modul deklariert werden und gehört dann zu diesem Modul. Wenn wir diese nicht deklarieren, können wir sie in der Anwendung nicht nutzen. Falls wir eine Komponente, Direktive oder Pipe in mehr als ein Modul deklarieren, wird Angular eine Exception schmeißen.

Die Komponente “SecondComponent” ist jetzt eine Unterkomponente (auf Englisch child component) unserer Hauptkomponente. Indem wir Komponenten im Modul deklarieren und dann im Template nutzen, können wir beliebig große Komponentenbäume erzeugen. Tatsächlich ist eine Angular 2 Anwendung nur ein Baum von Komponenten, mit der Hauptkomponente an der Spitze und beliebig vielen Unterkomponenten.

Selektoren

Es wird empfohlen, ein Präfix für den Selektor der Komponente zu nutzen. Deshalb ist der Selektor der “SecondComponent” nicht nur “second”, sondern “app-second”. Der Präfix hat zwei Funktionen:

  • Einerseits zeigt dieser, dass eine Komponente von uns implementiert worden ist und nicht aus einer externen Quelle importiert wird
  • Anderseits können wir das Präfix nutzt, um anzugeben zu welchem Teil/Modul unserer Anwendung eine Komponente gehört

Bei größeren Anwendungen ist es nicht ungewöhnlich, die Anwendung auf mehrere Unterverzeichnisse zu verteilen, wobei jedes Verzeichnis ein Feature bezeichnet. Z. B. kann eine große Anwendung einen Nutzerbereich und einen Adminbereich haben. In so einem Fall können alle Komponenten des Nutzerbereichs das Präfix “user” erhalten und alle Komponenten des Adminbereichs das Präfix “admin”. Natürlich würden wir in so einem Fall auch für jedes Feature ein eigenes Angular-Modul definieren.

Code

Code auf Github

Live Demo auf angular2kochbuch.de

Weitere Ressourcen

  • Der Angular Styleguide gibt Hintergrundinformationen zu Namenskonventionen, zur Verzeichnisstruktur von Angular 2 Anwendungen und zu anderen Best Practices
  • Neue Komponenten können wir auch mit Hilfe des generate-Kommandos von angular-cli generieren. Mehr Informationen gibt es in Appendix-B: angular-cli

Einen Service definieren

Problem

Ich möchte einen Service definieren und nutzen, damit ich Teile meiner Logik und die Daten aus der Komponente entfernen kann.

Zutaten

  • Angular 2 Anwendung
  • Eine Datei für unseren Service (data.service.ts)
  • Injectable-Decorator (@Injectable)
  • Anpassungen an der app.component.ts- und der app.module.ts-Datei

Lösung

Was wir in der Angular-Welt einen Service nennen, ist im Grunde genommen nur eine TypeScript-Klasse. Services werden benutzt, um Daten und Logik außerhalb von Komponenten zu halten. Somit können wir die Methoden und die Daten eines Services in mehreren Komponenten wiederverwenden.

data.service.ts
 1 import { Injectable } from '@angular/core';
 2 
 3 const data = ['a', 'b', 'c'];
 4 
 5 @Injectable()
 6 export class DataService {
 7   data: Array<string>;
 8   constructor() {
 9     this.data = data;
10   }
11 
12   getData() {
13     return this.data;
14   }
15 }

Erklärung:

  • Zeile 5: Hier nutzen wir den Injectable-Decorator, um den Service als “Injectable” zu definieren
  • Zeilen 6-15: Diese Klasse repräsentiert unseren Service. Sie wird auch exportiert, so dass wir den Service in Komponenten und anderen Services nutzen können

Wir haben jetzt einen Service definiert und müssen jetzt diesen im Angular-Modul als Provider registrieren.

app.module.ts
 1 import { NgModule } from '@angular/core';
 2 import { BrowserModule } from '@angular/platform-browser';
 3 
 4 import { AppComponent } from './app.component';
 5 import { DataService } from './data.service';
 6 
 7 @NgModule({
 8   imports: [ BrowserModule ],
 9   declarations: [ AppComponent ],
10   bootstrap: [ AppComponent ],
11   providers: [ DataService ]
12 })
13 export class AppModule { }

Erklärung:

  • Zeile 11: Die providers-Eigenschaft teilt Angular mit, welche Service der Anwendung zur Verfügung stehen

Bis jetzt haben wir einen Service definiert und diesen mit dem Angular-Modul registriert, nun wollen wir den Service in unserer Komponente nutzen.

app.component.ts
 1 import { Component } from '@angular/core';
 2 import { DataService } from './data.service';
 3 
 4 @Component({
 5   selector: 'app-root',
 6   template: '<div>Hello World!</div>'
 7 })
 8 export class AppComponent {
 9   constructor(dataService: DataService) {
10     console.log(dataService.getData());
11   }
12 }

Erklärung:

  • Zeile 9: Hier definieren wir den “DataService” als Abhängigkeit unserer Komponente. Zur Laufzeit wird die Konstruktorfunktion eine Instanz des “DataService” erhalten
  • Zeile 10: Hier nutzen wir die getData-Methode der dataService-Instanz. Statt die Daten in der Konstruktorfunktion zu holen, ist es besser die Daten in der ngOnInit-Methode zu holen. Die ngOnInit-Methode wird im Rezept “Code ausführen bei der Initialisierung einer Komponente” gezeigt

Diskussion

Nach unserer kurzen Erklärung ist anzunehmen, dass zur Lösung noch einige Fragen offen sind. Was genau sind “providers”? Warum brauchen wir kein “new”, um den DataService zu instantiieren? Wir haben erwähnt, dass wir den Service als “Injectable” definieren. Aber was heißt das? Diese Fragen werden wir jetzt beantworten.

Dependency Injection

Angular nutzt Dependency Injection (DI), um Abhängigkeiten zu verwalten. Alle Provider werden mit dem sogenannten “Injector” registriert. Erst die Nutzung einer TypeScript-Klasse in einem Provider macht die Klasse zu einem Service.

Als Erstes wollen wir die Frage “Was genau sind ‘providers’?” beantworten. Kurz gesagt ist ein “Provider” ein Rezept, um für einen Konstruktorparameter einen Wert bereitzustellen. So ein Rezept besteht aus zwei Zutaten, ein Token und die Information welcher Wert zur Laufzeit übergeben werden soll. In unserem Beispiel sagt das Rezept dem Injector, dass ein Parameter vom Typ “DataService” (das Token) eine Instanz (der Wert) der DataService-Klasse braucht. Wir haben die Kurzform für einen Provider benutzt und in diesem Fall wird immer für die Klasse (das Token), die der providers-Array übergeben wird, eine Instanz erzeugt. Das beantwortet auch gleich die Frage “Warum brauchen wir kein ‘new’, um den “DataService” zu instantiieren?”. Der Injector tut das für uns. Das hat den Vorteil, dass wir als Nutzer des Services nicht wissen müssen, wie wir diesen instantiieren müssen. Ein weitere Vorteil ist, dass wir z. B. beim Testen für das “DataService”-Token einen anderen Wert übergeben können. Z. B. eine Klasse die ein “DataService”-Mock erzeugt.

Wie wir schon wissen, werden Typinformationen zur Compile-Zeit entfernt. Damit der Injector trotzdem weiß was für ein Wert ein Konstruktorparameter erwartet, wird diese Information in den Metadaten der Komponente gespeichert. Da Klassen keine Metadaten besitzen, müssen wir eine Klasse, die wir als Service benutzen wollen mit Hilfe des Injectable-Decorators als “Injectable” definieren. Somit erhält auch unser Service-Klasse Metadaten und kann dann Abhängigkeiten haben, die in den Metadaten gespeichert werden. Kurz gesagt ist ein “Injectable” Service ein Service, der Abhängigkeiten als Konstruktorparameter besitzen kann. Eigentlich brauchen wir den Injectable-Decorator nur, wenn wir für einen Service Abhängigkeiten als Konstruktorparameter definieren wollen. Obwohl unser Service keine Abhängigkeiten hat, haben wir den Decorator verwendet, damit zum Einen alle Services einheitlich sind und zum Anderen Fehler vermieden werden, falls wir später doch eine Abhängigkeit brauchen. Wir wissen jetzt also, was es bedeutet, einen Service als “Injectable” zu definieren und warum wir das machen.

Wir haben unsere Diskussion möglichst kurz gehalten. Eine ausführlichere Erklärung, wie Dependency Injection in Angular funktioniert und was passiert, wenn wir eine Klasse in mehrere providers-Array nutzen, würde den Rahmen eines Rezepts sprengen. Eine vollständige Erklärung, wie Dependency Injection funktioniert und was wir alles damit machen können, gibt es auf der Angular 2 Webseite: Dependency Injection und Hierarchical Dependency Injectors. Dort wird auch beschrieben, wie wir komplexere Provider-Rezepte nutzen können und was wir außer Services noch als Abhängigkeiten definieren können.

Code

Code auf Github

Live Demo auf angular2kochbuch.de

Weitere Ressourcen

  • Neue Services können wir auch mit Hilfe des generate-Kommandos von angular-cli generieren. Mehr Informationen gibt es in Appendix-B: angular-cli

Angular 2 in Produktion nutzen

Problem

Ich möchte meine Angular 2 Anwendung produktiv nutzen.

Zutaten

Lösung

Mit angular-cli ist es sehr einfach eine produktiv-Version von unserer Anwendung zu bauen. Tatsächlich hat ein neu initialisiertes Projekt schon den Code in der main.ts-Datei, den wir in diesem Rezept hinzufügen wollen. Auch die nötige environment-Dateien ist da schon vorhanden.

Als Erstes schauen wir uns die environment.prod.ts-Datei an. Diese befindet sich im Verzeichnis “src/environments”.

environment.prod.ts
1 export const environment = {
2     production: true
3 };

Erklärung:

Bei einem angular-cli-Projekt befinden sich im Verzeichnis “src/environments” zwei Dateien. Die eine mit Namen “environment.ts” und eine mit Namen “environment.prod.ts”. Eigentlich sind beide Dateien optional. Diese werden nur gebraucht, wenn wir sie in unserem Code referenzieren. Der Unterschied zwischen den zwei Dateien, ist der Wert für die production-Eigenschaft. Dieser ist true in der environment.prod.ts-Datei und false in der environment.ts-Datei.

Jetzt sehen wir warum es sinnvoll sein kann die environment-Dateien zu referenzieren.

main.ts
 1 import './polyfills.ts';
 2 
 3 import { platformBrowserDynamic } from '@angular/platform-browser-dynamic';
 4 import { enableProdMode } from '@angular/core';
 5 import { environment } from './environments/environment';
 6 import { AppModule } from './app/';
 7 
 8 if (environment.production) {
 9   enableProdMode();
10 }
11 
12 platformBrowserDynamic().bootstrapModule(AppModule);

Erklärung:

  • Zeile 5: Importiert eine environment-Datei. Ob es die environment.ts- oder die environment.prod.ts-Datei ist, wird von angular-cli zur Bauzeit definiert
  • Zeilen 8-10: Hier wird der Produktions-Modus von Angular aktiviert aber nur, wenn angular-cli die environment.prod.ts-Datei nutzt

Als letztes müssen wir unser Projekt mit der --prod-Option bauen.

1 ng build --prod

Sobald die --prod-Option benutzt wird, nutzt angular-cli die environment.prod.ts-Datei. In allen anderen Fällen z. B. beim ng serve wird die environment.ts-Datei benutzt.

Code

Code auf Github

Live Demo auf angular2kochbuch.de

Up next

Rezepte, um mit der Anzeige zu interagieren