lernen sie die grundlagen von angular mit angu ferdinand ... (bu… · ferdinand malcher ·...

Malcher

Hop

peKopp

enahgenAn

gula

r Auflage2.

C

Grundlagen, fortgeschrittene Themen und Best Practices

Angular Ferdinand Malcher . Johannes Hoppe . Danny Koppenhagen

Auflage2.

inklusiveNativeScript und NgRx

9 783864 906466

Interesse am E-Book?www.dpunkt.plus

Thema• JavaScript• TypeScript• RxJS• Redux/NgRx• NativeScript• Best Practices und Testing

Leser• Webentwickler• JavaScript-Entwickler• App-Entwickler

Websitewww.angular-buch.com

€ 36,90 (D)ISBN 978-3-86490-646-6

Ferdinand Malcher . Johannes HoppeDanny Koppenhagen

Angular

Lernen Sie die Grundlagen von Angular mit diesem Praxisbuch!

Mit einem anspruchsvollen Beispielprojektführen wir Sie durch die Welt von Angular. Lernen Sie Schritt für Schritt, wie Sie modulare Single-Page-Anwendungen entwickeln.

Praktisch: Der Programmcode zu jeder einzelnen Entwicklungsphase ist auf GitHub verfügbar. So können Sie alle Schritte gut nachvollziehen und auch Teile überspringen.

Die Autoren sind erfahrene Workshopleiter und internationale Konferenzsprecher. In diesem praktischen Nachschlagewerk vermitteln sie die Best Practices aus der täglichen Arbeit mit Angular.

Neben den Grundlagen werden auch behandelt:

• Reaktive Programmierung mit RxJS• State-Management mit Redux• Testing mit Jasmine, Karma und Protractor• Routing und Modulsystem• HTTP und Interceptoren• Formularverarbeitung • Dependency Injection und Services• Internationalisierung (i18n)• Mobile Anwendungen mit NativeScript• Server-Side Rendering

Das Buch setzt Vorkenntnisse in JavaScript, HTML und CSS voraus. Wer noch nicht mit TypeScript vertraut ist, findet hier eine kompakte Einführung.

Auf der Website zum Buch werden außerdem regelmäßig Aktualisierungen und Neuigkeiten rund um Angular veröffentlicht.

Neu in dieser Auflage

• Durchgängig aktualisiert auf Angular 8 und neuere Versionen

• Kompakter Schnelleinstieg in Angular mit Stackblitz

• Ausführliches Kapitel zu RxJS und Observables

• Redux mit Reactive Extensions for Angular (NgRx)

• Server-Side Rendering mit Angular Universal

• HTTP-Interceptoren

Aktualisierte und erweiterte Auflage

x Vorwort

Umgangmit Aktualisierungen

Das Release einer neuen Major-Version von Angular bedeutet keines-wegs, dass alle Ideen verworfen werden und Ihre Software nach einemUpdate nicht mehr funktioniert. Auch wenn Sie eine neuere Angular-Version verwenden, behalten die in diesem Buch beschriebenen Kon-zepte ihre Gültigkeit. Die Grundideen von Angular sind seit Version 2konsistent und auf Beständigkeit über einen langen Zeitraum ausgelegt.Alle Updates zwischen den Major-Versionen waren in der Vergangen-heit problemlos möglich, ohne dass Breaking Changes die gesamte An-wendung unbenutzbar machen. Gibt es doch gravierende Änderungen,so werden stets ausführliche Informationen und Tools zur Migrationangeboten.

Alle Beispiele aus diesem Buch sowie zusätzliche Links und Hin-weise können Sie über eine zentrale Seite erreichen:

Die Begleitwebsitezum Buch

https://angular-buch.com

Unter anderem veröffentlichen wir dort zu jeder Major-Version einenArtikel mit den wichtigsten Neuerungen und den nötigen Änderungenam Beispielprojekt. Wir empfehlen Ihnen aus diesem Grund, unbedingteinen Blick auf die Begleitwebsite des Buchs zu werfen, bevor Sie begin-nen, sich mit den Inhalten des Buchs zu beschäftigen.

Anwen richtet sich das Buch?

Webentwickler mitJavaScript-Erfahrung

Dieses Buch richtet sich an Webentwickler, die einige Grundkenntnis-se mitbringen. Wir setzen allgemeine Kenntnisse in JavaScript voraus.Wenn Sie bereits ein erstes JavaScript-Projekt umgesetzt haben und Ih-nen Frameworks wie jQuery vertraut sind, werden Sie an diesem Buchsehr viel Freude haben. Mit Angular erwartet Sie das modulare Ent-wickeln von Single-Page-Applikationen in Kombination mit Unit- undUI-Testing.

TypeScript-Einsteigerund Erfahrene

Für die Entwicklung mit Angular nutzen wir die populäre Program-miersprache TypeScript. Doch keine Angst: TypeScript ist lediglich eineErweiterung von JavaScript, und die neuen Konzepte sind sehr eingän-gig und schnell gelernt.

LeseprobeAngular, 2. Auflage

Angular, 2. Auflage | Kostenlose Leseprobe | angular-buch.com | Urheberrechtlich geschützt

Angular

Liebe Leserin, lieber Leser,

das Angular-Ökosystem wird kontinuierlich verbessert. Bitte haben Sie Ver-

ständnis dafür, dass sich beim Entwickeln einige Dinge vom gedruckten Stand

unterscheiden können. Die Github-Repositorys halten wir hierzu stets auf dem

neuesten Stand.

Unter https://angular-buch.com/updates informieren wir Sie ausführlich über

Breaking Changes und neue Funktionen. Wir freuen uns auf Ihren Besuch.

Sollten Sie einen Fehler vermuten oder einen Breaking Change entdeckt

haben, so bitten wir Sie um Ihre Mithilfe! Bitte kontaktieren Sie uns hierfür

unter [email protected] mit einer Beschreibung des Problems. Wir

werden eine Lösung auf unserer Website bekannt machen, sodass alle Leser

des Buchs davon profitieren können.

Wir wünschen Ihnen viel Spaß mit Angular!

Alles GuteFerdinand, Johannes, Danny

Malcher_Angular_Titelei.fm Seite i Donnerstag, 9. Mai 2019 2:05 14


Zu diesem Buch – sowie zu vielen weiteren dpunkt.büchern – können Sie auch das entsprechende E-Book im PDF-Format herunterladen. Werden Sie dazu einfach Mitglied bei dpunkt.plus+:

www.dpunkt.plus

Ferdinand Malcher arbeitet als selbstständiger Entwickler, Beraterund Mediengestalter mit Schwerpunkt auf Angular, TypeScript undNode.js. Gemeinsam mit Johannes Hoppe hat er die Angular.Schulegegründet und bietet Workshops und Beratung zu Angular an.

@fmalcher01

Johannes Hoppe arbeitet als selbständiger Softwarearchitektund Berater für Angular, .NET und Node.js. Zusammen mitFerdinand Malcher hat er die Angular.Schule gegründet. Für seineCommunity-Tätigkeit rund ums Web wurde er mehrfach als Pro-gress Developer Expert ausgezeichnet. Johannes ist Organisatordes Angular Heidelberg Meetup.

@JohannesHoppe

Danny Koppenhagen arbeitet als Berater und Entwickler vonClient- und Serveranwendungen mit NodeJS, TypeScript undAngular. Sein Schwerpunkt liegt in der Entwicklung von Weban-wendungen im Enterprise-Umfeld sowie auf Apps mit Native-Script.

@d_koppenhagen

Sie erreichen das Autorenteam auf Twitter unter @angular_buch.

Malcher_Angular_Titelei.fm Seite ii Donnerstag, 9. Mai 2019 2:05 14


Ferdinand Malcher · Johannes Hoppe · Danny Koppenhagen

Angular

Grundlagen, fortgeschrittene Themen und Best Practices – inklusive NativeScript und NgRx

2., aktualisierte und erweiterte Auflage

Malcher_Angular_Titelei.fm Seite iii Donnerstag, 9. Mai 2019 2:05 14


Ferdinand Malcher, Johannes Hoppe, Danny [email protected]

Lektorat: René SchönfeldtLektoratsassistenz/Projektkoordinierung: Anja WeimerCopy-Editing: Anette Schwarz, DitzingenSatz: Da-TeX, LeipzigHerstellung: Stefanie WeidnerUmschlaggestaltung: Helmut Kraus, www.exclam.de Druck und Bindung: mediaprint solutions GmbH, 33100 Paderborn

Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISBN:Print 978-3-86490-646-6PDF 978-3-96088-712-6ePub 978-3-96088-713-3mobi 978-3-96088-714-0

2., aktualisierte und erweiterte Auflage 2019Copyright © 2019 dpunkt.verlag GmbHWieblinger Weg 1769123 Heidelberg

Hinweis:Dieses Buch wurde auf PEFC-zertifiziertem Papier aus nachhaltigerWaldwirtschaft gedruckt. Der Umwelt zuliebe verzichten wirzusätzlich auf die Einschweißfolie.

Schreiben Sie uns:Falls Sie Anregungen, Wünsche und Kommentare haben, lassen Sie es uns wissen: [email protected].

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Ver-wendung dieses Buches stehen.

5 4 3 2 1 0

Das Papier für diesesBuch stammt aus nach-haltig bewirtschaftetenWäldern und kontrol-lierten Quellen.

www.pefc.de

iX-EditionIn der iX-Edition erscheinen Titel, die vom dpunkt.verlag gemeinsam mit der Redaktion der Compu-terzeitschrift iX ausgewählt und konzipiert werden. Inhaltlicher Schwerpunkt dieser Reihe sindSoftware- und Webentwicklung sowie Administration.

Malcher_Angular_Titelei.fm Seite iv Donnerstag, 9. Mai 2019 2:05 14


vii

Vorwort

»Angular is one of the most adopted frameworks on the planet.«

Brad Green(Angular Engineering Director)

Angular ist eines der populärsten Frameworks für die Entwicklung vonSingle-Page-Applikationen. Das Framework wird weltweit von großenUnternehmen eingesetzt, um modulare, skalierbare und gut wartbareApplikationen zu entwickeln. Tatsächlich hat Angular seinen Ursprungbeim wohl größten Player des Internets – Google. Obwohl kommerzi-elle Absichten hinter der Idee stehen, wurde Angular von Anfang anquelloffen unter der MIT-Lizenz veröffentlicht. Im September 2016 er-schien Angular in der Version 2.0.0. Google setzte damit einen Meilen-stein in der Welt der modernen Webentwicklung: Das Framework nutztdie Programmiersprache TypeScript, bietet ein ausgereiftes Tooling undkomponentenbasierte Entwicklung. In kurzer Zeit haben sich rund umAngular ein umfangreiches Ökosystem und eine vielfältige Communitygebildet.

Die Entwicklung wird maßgeblich von einem dedizierten Teambei Google vorangetrieben, wird aber auch stark aus der Commu-nity beeinflusst. Angular gilt neben React.js (Facebook) und Vue.js(Community-Projekt) als eines der weltweit beliebtesten Webframe-works. Sie haben also die richtige Entscheidung getroffen und habenAngular für die Entwicklung Ihrer Projekte ins Auge gefasst.

Das Framework ist modular aufgebaut und stellt eine Vielzahl anFunktionalitäten bereit, um wiederkehrende Standardaufgaben zu lö-sen. Der Einstieg ist umfangreich, aber die Konzepte sind durchdachtund konsequent. Hat man die Grundlagen erlernt, so kann man denFokus auf die eigentliche Businesslogik legen. Opinionated

FrameworkHäufig verwendet man

im Zusammenhang mit Angular das Attribut opinionated, das wir imDeutschen mit dem Begriff meinungsstark ausdrücken können: Angu-lar ist ein meinungsstarkes Framework, das viele klare Richtlinien zuArchitektur, Codestruktur und Best Practices definiert. Das kann zuAnfang umfangreich erscheinen, sorgt aber dafür, dass in der gesam-


viii Vorwort

ten Community einheitliche Konventionen herrschen, Standardlösun-gen existieren und bestehende Bibliotheken vorausgewählt wurden.

Obwohl die hauptsächliche Zielplattform für Angular-Anwendun-gen der Browser ist, ist das Framework nicht darauf festgelegt: Durchseine Plattformunabhängigkeit kann Angular auf nahezu jeder Platt-form ausgeführt werden, unter anderem auf dem Server und nativ aufMobilgeräten.

GrundlegendeKonzepte

Sie werden in diesem Buch lernen, wie Sie mit Angular kompo-nentenbasierte Single-Page-Applikationen entwickeln. Wir werden Ih-nen vermitteln, wie Sie Abhängigkeiten und Asynchronität mithilfe desFrameworks behandeln. Weiterhin erfahren Sie, wie Sie mit Routingdie Navigation zwischen verschiedenen Teilen der Anwendung imple-mentieren. Sie werden lernen, wie Sie komplexe Formulare mit Vali-dierungen in Ihre Anwendung integrieren und wie Sie Daten aus einerHTTP-Schnittstelle konsumieren können.

Beispielanwendung Wir entwickeln mit Ihnen gemeinsam eine Anwendung, anhand de-rer wir Ihnen all diese Konzepte von Angular beibringen. Dabei führenwir Sie Schritt für Schritt durch das Projekt – vom Projektsetup überdas Testen des Anwendungscodes bis zum Deployment der fertig ent-wickelten Anwendung. Auf dem Weg stellen wir Ihnen eine Reihe vonTools, Tipps und Best Practices vor, die wir in mehr als zwei JahrenPraxisalltag mit Angular sammeln konnten.

Nach dem Lesen des Buchs sind Sie in der Lage,

n das Zusammenspiel der Funktionen von Angular sowie das Kon-zept hinter dem Framework zu verstehen,

n modulare, strukturierte und wartbare Webanwendungen mithilfedes Angular-Frameworks zu entwickeln sowie

n durch die Entwicklung von Tests qualitativ hochwertige Anwen-dungen zu erstellen.

Die Entwicklung von Angular macht vor allem eines: Spaß! Diesen En-thusiasmus für das Framework und für Webtechnologien möchten wirIhnen in diesem Buch vermitteln – wir nehmen Sie mit auf die Reise indie Welt der modernen Webentwicklung!


Vorwort ix

Versionen und Namenskonvention:Angular vs. AngularJSIn diesem Buch dreht sich alles um das Framework Angular. Sucht mannach dem Begriff »Angular« im Internet, so stößt man auch oft nochauf die Bezeichnung »AngularJS«. Hinter dieser Bezeichnung verbirgtsich die Version 1 des Frameworks. Mit der Version 2 wurde Angularvon Grund auf neu entwickelt. It’s just »Angular«.Die offizielle Bezeichnung für das neueFramework ist Angular, ohne Angabe der Programmiersprache und oh-ne eine spezifische Versionsnummer. Angular erschien im September2016 in der Version 2.0.0 und hat viele neue Konzepte und Ideen in dieCommunity gebracht. Weil es sich um eine vollständige Neuentwick-lung handelt, ist Angular nicht ohne Weiteres mit dem alten AngularJSkompatibel. Um Verwechslungen auszuschließen, gilt also die folgendeKonvention:

n Angular – das Angular-Framework ab Version 2 und höher (diesesBuch ist durchgängig auf dem Stand von Angular 7 bzw. der Beta-Version von Angular 8)

n AngularJS – das Angular-Framework in der Version 1.x.x

Long Term Support fürAngularJS

AngularJS, das 2009 erschien, ist zwar mittlerweile etwas in die Jah-re gekommen, viele Webanwendungen setzen aber weiterhin auf dasFramework. Die letzte Version 1.7 wurde im Sommer 2018 veröffent-licht und wird nach einer dreijährigen Phase mit Long Term Support(LTS) ab Juli 2021 nicht mehr unterstützt.�

Semantic VersioningSie haben also die richtige Entscheidung getroffen, Angular ab Ver-sion 2.0.0 einzusetzen. Diese Versionsnummer x.y.z basiert auf Seman-tic Versioning.� Der Release-Zyklus von Angular ist kontinuierlich ge-plant: Im Rhythmus von sechs Monaten erscheint eine neue Major-Version x. Die Minor-Versionen y werden monatlich herausgegeben,nachdem eine Major-Version erschienen ist.

Abb. 1Zeitleiste derEntwicklung vonAngular

�https://ng-buch.de/a/1 – AngularJS: Version Support Status�https://ng-buch.de/a/2 – Semantic Versioning 2.0.0


x Vorwort

Umgangmit AktualisierungenDas Release einer neuen Major-Version von Angular bedeutet keines-wegs, dass alle Ideen verworfen werden und Ihre Software nach einemUpdate nicht mehr funktioniert. Auch wenn Sie eine neuere Angular-Version verwenden, behalten die in diesem Buch beschriebenen Kon-zepte ihre Gültigkeit. Die Grundideen von Angular sind seit Version 2konsistent und auf Beständigkeit über einen langen Zeitraum ausgelegt.Alle Updates zwischen den Major-Versionen waren in der Vergangen-heit problemlos möglich, ohne dass Breaking Changes die gesamte An-wendung unbenutzbar machen. Gibt es doch gravierende Änderungen,so werden stets ausführliche Informationen und Tools zur Migrationangeboten.

Alle Beispiele aus diesem Buch sowie zusätzliche Links und Hin-weise können Sie über eine zentrale Seite erreichen:

Die Begleitwebsitezum Buch

https://angular-buch.com

Unter anderem veröffentlichen wir dort zu jeder Major-Version einenArtikel mit den wichtigsten Neuerungen und den nötigen Änderungenam Beispielprojekt. Wir empfehlen Ihnen aus diesem Grund, unbedingteinen Blick auf die Begleitwebsite des Buchs zu werfen, bevor Sie begin-nen, sich mit den Inhalten des Buchs zu beschäftigen.

Anwen richtet sich das Buch?Webentwickler mit

JavaScript-ErfahrungDieses Buch richtet sich an Webentwickler, die einige Grundkenntnis-se mitbringen. Wir setzen allgemeine Kenntnisse in JavaScript voraus.Wenn Sie bereits ein erstes JavaScript-Projekt umgesetzt haben und Ih-nen Frameworks wie jQuery vertraut sind, werden Sie an diesem Buchsehr viel Freude haben. Mit Angular erwartet Sie das modulare Ent-wickeln von Single-Page-Applikationen in Kombination mit Unit- undUI-Testing.

TypeScript-Einsteigerund Erfahrene

Für die Entwicklung mit Angular nutzen wir die populäre Program-miersprache TypeScript. Doch keine Angst: TypeScript ist lediglich eineErweiterung von JavaScript, und die neuen Konzepte sind sehr eingän-gig und schnell gelernt.


Vorwort xi

PraxisorientierteEinsteiger

In diesem Buch wird ein praxisorientierter Ansatz verfolgt. Sie wer-den anhand einer Beispielanwendung schrittweise die Konzepte undFunktionen von Angular kennenlernen. Dabei lernen Sie nicht nur dieGrundlagen kennen, sondern wir vermitteln Ihnen auch eine Vielzahlvon Best Practices und Erkenntnissen aus mehrjähriger Praxis mit An-gular.

Was sollten Sie mitbringen?Grundkenntnisse inJavaScript, HTML undCSS

Da wir Erfahrungen in der Webentwicklung mit JavaScript vorausset-zen, ist es für jeden Entwickler, der auf diesem Gebiet unerfahren ist,empfehlenswert, sich die nötigen Grundlagen zu erarbeiten. Darüberhinaus sollten Sie Grundkenntnisse im Umgang mit HTML und CSSmitbringen. Der dpunkt.verlag bietet eine große Auswahl an Einstiegs-literatur für HTML, JavaScript und CSS an. Sollten Sie über keiner-lei TypeScript-Kenntnisse verfügen: kein Problem! Alles, was Sie überTypeScript wissen müssen, um die Inhalte dieses Buchs zu verstehen,wird in einem separaten Kapitel vermittelt.

Sie benötigen Keine Angular-Vorkenntnisse nötig!

keinerlei Vorkenntnisse im Umgang mit Angular bzw.AngularJS. Ebenso müssen Sie sich nicht vorab mit benötigten Toolsund Hilfsmitteln für die Entwicklung von Angular-Applikationen ver-traut machen. Das nötige Wissen darüber wird Ihnen in diesem Buchvermittelt.

Für wen ist dieses Buch weniger geeignet?Um Inhalte des Buchs zu verstehen, Unerfahrene

Webentwicklerwerden Erfahrungen im Webumfeld

vorausgesetzt. Entwicklern ohne Vorkenntnisse in diesem Umfeld wirdder Einstieg schwerer fallen. Sie sollten sich zunächst die grundlegendenKenntnisse in den Bereichen HTML, JavaScript und CSS aneignen.

Kein NachschlagewerkWeiterhin ist dieses Buch nicht als Nachschlagewerk zu verstehen.Es werden nicht alle Möglichkeiten und Konzepte von Angular bis injedes Detail erläutert. Anhand des Beispielprojekts werden die wich-tigsten Funktionalitäten praxisorientiert vermittelt. O�zielle Angular-

DokumentationUm Details zu den

einzelnen Framework-Funktionen nachzuschlagen, empfehlen wir dieoffizielle Dokumentation für Entwickler.�

�https://ng-buch.de/a/3 – Angular Docs


xii Vorwort

Wie ist dieses Buch zu lesen?Einführung, Tools und

SchnellstartWir beginnen im ersten Teil des Buchs mit einer Einführung, in der Siealles über die verwendeten Tools und benötigtes Werkzeug erfahren.Im Schnellstart tauchen wir sofort in Angular ein und nehmen Sie mitzu einem schnellen Einstieg in das Framework und den Grundaufbaueiner Anwendung.

Einführung inTypeScript

Der zweite Teil vermittelt Ihnen einen Einstieg in TypeScript. Siewerden hier mit den Grundlagen dieser typisierten Skriptsprache ver-traut gemacht und erfahren, wie Sie die wichtigsten Features verwendenkönnen. Entwickler, die bereits Erfahrung im Umgang mit TypeScripthaben, können diesen Teil überspringen.

Beispielanwendung Der dritte Teil ist der Hauptteil des Buchs. Hier möchten wir mit Ih-nen zusammen eine Beispielanwendung entwickeln. Die Konzepte undTechnologien von Angular wollen wir dabei direkt am Beispiel vermit-teln. So stellen wir sicher, dass das Gelesene angewendet wird und jederAbschnitt automatisch einen praktischen Bezug hat.

Iterationen Nach einer Projekt- und Prozessvorstellung haben wir das Buch inmehrere Iterationen eingeteilt. In jeder Iteration gilt es Anforderungenzu erfüllen, die wir gemeinsam mit Ihnen implementieren.

n Iteration I: Komponenten & Template-Syntax (ab S. 69)n Iteration II: Services & Routing (ab S. 125)n Iteration III: HTTP & reaktive Programmierung (ab S. 181)n Iteration IV: Formularverarbeitung & Validierung (ab S. 261)n Iteration V: Pipes & Direktiven (ab S. 339)n Iteration VI: Module & fortgeschrittenes Routing (ab S. 387)n Iteration VII: Internationalisierung (ab S. 433)

Storys Eine solche Iteration ist in mehrere Storys untergliedert, die jeweils einThemengebiet abdecken. Eine Story besteht immer aus einer theore-tischen Einführung und der praktischen Implementierung im Beispiel-projekt.Refactoring Neben Storys gibt es Refactoring-Abschnitte. Dabei handelt essich um technische Anforderungen, die die Architektur oder den Code-stil der Anwendung verbessern.

Haben wir eine Iteration abgeschlossen, prüfen wir, ob wir unserenEntwicklungsprozess vereinfachen und beschleunigen können.Powertipps In denPowertipps demonstrieren wir hilfreiche Werkzeuge, die uns bei derEntwicklung zur Seite stehen.

Testing Nachdem alle Iterationen erfolgreich absolviert wurden, wollen wirdas Thema Testing genauer betrachten. Hier erfahren Sie, wie Sie IhreAngular-Anwendung automatisiert testen und so die Softwarequalitätsichern können. Dieses Kapitel kann sowohl nach der Entwicklung desBeispielprojekts als auch parallel dazu bestritten werden.


Vorwort xiii

DeploymentIm vierten Teil dreht sich alles um das Deployment einer Angular-Anwendung. Sie werden erfahren, wie Sie eine fertig entwickelte An-gular-Anwendung fit für den Produktiveinsatz machen.

WeiterführendeThemen

Im fünften und letzten Teil möchten wir Ihnen mit Server-Side Ren-dering, der Redux-Architektur und dem Framework NativeScript dreiAnsätze näherbringen, die über eine Standardanwendung hinausgehen.

SSRMit Server-Side Rendering (SSR) machen Sie Ihre Anwendung fit fürSuchmaschinen und verbessern zusätzlich die Geschwindigkeit beim in-italen Start der App. ReduxAnschließend stellen wir Ihnen das Redux-Patternund das Framework NgRx vor. Sie erfahren, wie Sie mithilfe von Re-dux den Anwendungsstatus zentral und gut wartbar verwalten können.

NativeScriptZum Schluss betrachten wir am praktischen Beispiel, wie wir Native-Script einsetzen können, um native mobile Anwendungen für verschie-dene Zielplattformen (Android, iOS etc.) zu entwickeln.

WissenswertesIm letzten Kapitel des Buchs finden Sie weitere Informationen zuwissenswerten und begleitenden Themen. Hier haben wir weiterfüh-rende Inhalte zusammengetragen, auf die wir im Beispielprojekt nichtausführlich eingehen.

Abtippen statt Copy & PasteWir alle kennen es: Beim Lesen steht vor uns ein großer AbschnittQuelltext, und wir haben wenig Lust auf Tipparbeit. Schnell kommtder Gedanke auf, ein paar Codezeilen oder sogar ganze Dateien ausdem Repository zu kopieren. Vielleicht denken Sie sich: »Den Inhaltanzuschauen und die Beschreibung zu lesen reicht aus, um es zu verste-hen.«

Abtippen heißt Lernenund Verstehen.

An dieser Stelle möchten wir aber einhaken. Kopieren und Einfügenist nicht dasselbe wie Lernen und Verstehen. Wenn Sie die Codebeispie-le selbst eintippen, werden Sie besser verstehen, wie Angular funktio-niert, und werden die Software später erfolgreich in der Praxis einset-zen können. Jeder einzelne Quelltext, den Sie abtippen, trainiert IhreHände, Ihr Gehirn und Ihre Sinne. Wir möchten Sie deshalb ermutigen:Betrügen Sie sich nicht selbst. Der bereitgestellte Quelltext im Reposi-tory sollte lediglich der Überprüfung dienen. Wir wissen, wie schwerdas ist, aber vertrauen Sie uns: Es zahlt sich aus, denn Übung machtden Meister!


xiv Vorwort

Beratung undWorkshopsWir, die Autoren dieses Buchs, arbeiten seit Langem als Berater undTrainer für Angular. Wir haben die Erfahrung gemacht, dass man An-gular in kleinen Gruppen am schnellsten lernen kann. In einem Work-shop kann auf individuelle Fragen und Probleme direkt eingegangenwerden – und es macht auch am meisten Spaß!

Schauen Sie auf https://angular.schule vorbei. Dort bieten wir IhnenAngular-Workshops in den Räumen Ihres Unternehmens oder in offe-nen Gruppen an. Das Angular-Buch verwenden wir dabei in unserenEinstiegskursen zur Nacharbeit. Haben Sie das Buch vollständig gele-sen, so können Sie direkt in die individuellen Kurse für Fortgeschritteneeinsteigen. Wir freuen uns auf Ihren Besuch.

Die Angular.Schule:Workshops und

Beratung

https://angular.schule

DanksagungDieses Buch hätte nicht seine Reife erreicht ohne die Hilfe und Unter-stützung verschiedener Menschen. Wir danken Gregor Woiwode fürdie Mitwirkung als Autor in der ersten Auflage. Besonderer Dank gehtan Michael Kaaden für seine unermüdlichen Anregungen und kriti-schen Nachfragen. Michael hat das gesamte Buch mehrfach auf Ver-ständlichkeit und Fehler abgeklopft, alle Codebeispiele nachvollzogenund viel wertvollen Input geliefert. Matthias Jauernig, Dilyana Pavlo-va, Silvio Böhme, Danilo Hoffmann und Jan-Niklas Wortmann dankenwir ebenso für die hilfreichen Anregungen und Korrekturvorschläge zurzweiten Auflage. Julian Steiner hat uns mit seiner Expertise zu Native-Script bei der Entwicklung der BookMonkey-Mobile-App unterstützt.Wertvolles Feedback zur ersten Auflage dieses Buchs haben uns au-ßerdem Nils Frohne, Johannes Hamfler, Stephan Hartmann, JohannesHofmeister, Alexander Szczepanski und Daniel Vladut zukommen las-sen.

Dem Team vom dpunkt.verlag, insbesondere René Schönfeldt undSabrina Dietze, danken wir für die persönliche Unterstützung und dieguten Anregungen zum Buch. Außerdem danken wir dem Angular-Team und der Community dafür, dass sie eine großartige Plattformgeschaffen haben, die uns den Entwickleralltag angenehmer macht.


xv

Aktualisierungen in der zweitenAu�age

Die Webplattform bewegt sich schnell, und so muss auch ein Frame-work wie Angular stets an neue Gegebenheiten angepasst werden undmit den Anforderungen wachsen. In den zwei Jahren seit Veröffentli-chung der ersten Auflage dieses Buchs haben sich viele Dinge geändert:Es wurden Best Practices etabliert, neue Features eingeführt, und einigewenige Features wurden wieder entfernt.

Die zweite Auflage, die Sie mit diesem Buch in Händen halten, wur-de deshalb grundlegend aktualisiert und erweitert. Wir möchten Ihneneinen kurzen Überblick über die Neuerungen und Aktualisierungen derzweiten Auflage geben. Alle Texte und Codebeispiele haben wir auf dieaktuelle Angular-Version aktualisiert.

Neue KapitelFolgende Kapitel und Abschnitte sind in dieser Auflage neu hinzuge-kommen:

n 10.3 Interceptoren: HTTP-Requests abfangen und transformieren(Seite 245)

n 19 Server-Side Rendering mit Angular Universal (Seite 537)n 24 Wissenswertes (Seite 641)

n 24.1 Container und Presentational Components (Seite 641)n 24.3 TrackBy-Funktion für die Direktive ngFor (Seite 646)n 24.4 Schematics: Codegenerierung mit der Angular CLI (Sei-

te 648)n 24.6 Angular Material und weitere UI-Komponentensammlungen

(Seite 654)n 24.11 Angular updaten (Seite 675)


xvi Aktualisierungen in der zweiten Au�age

Vollständig neu geschriebene KapitelEinige bereits in der ersten Auflage existierende Kapitel wurden für diezweite Auflage vollständig neu aufgerollt:

1 Schnellstart (Seite 3) Der Schnellstart basierte in der ersten Auf-lage auf einer lokalen Lösung mit SystemJS und Paketen aus einemCDN. Der neue Schnellstart setzt auf die Online-Plattform StackBlitzzum schnellen Prototyping von Webanwendungen.

10.2 Reaktive Programmierungmit RxJS (Seite 198) Das Prinzip derreaktiven Programmierung und das Framework RxJS haben in den letz-ten Jahren weiter an Bedeutung gewonnen. Das alte Kapitel zu RxJSlieferte nur einen kurzen Überblick, ohne auf Details einzugehen. Mitdieser Neufassung finden Sie jetzt eine ausführliche Einführung in diePrinzipien von reaktiver Programmierung und Observables, und es wer-den alle wichtigen Konzepte anhand von Beispielen erklärt. Im Gegen-satz zur ersten Auflage verwenden alle Beispiele im Buch die aktuelleSyntax von RxJS mit den Pipeable Operators.

12 Formularverarbeitung & Validierung: Iteration IV (Seite 261) Inder ersten Auflage haben wir sowohl Template-Driven Forms als auchReactive Forms gleichbedeutend vorgestellt. Wir empfehlen mittlerwei-le nicht mehr den Einsatz von Template-Driven Forms. Daher stellenwir zwar beide Ansätze weiterhin vor, legen aber im Kapitel zur For-mularverarbeitung einen stärkeren Fokus auf Reactive Forms. Das Pra-xisbeispiel wurde neu entworfen, um eine saubere Trennung der Zu-ständigkeiten der Komponenten zu ermöglichen. Die Erläuterungen imGrundlagenteil wurden neu formuliert, um besser für die Anforderun-gen aus der Praxis geeignet zu sein.

20 StateManagementmit Redux (Seite 553) In den letzten zwei Jah-ren hat sich unserer Ansicht nach das Framework NgRx gegen weitereFrameworks wie angular-redux klar durchgesetzt. Während die ersteAuflage in diesem Kapitel noch auf angular-redux setzte, arbeitet dasneue Kapitel durchgehend mit den Reactive Extensions for Angular(NgRx). Das neue Kapitel erarbeitet in der Einführung schrittweise einModell für zentrales State Management, um die Architektur von Reduxzu erläutern, ohne eine konkrete Bibliothek zu nutzen.


Aktualisierungen in der zweiten Au�age xvii

Stark überarbeitete und erweiterte Kapitel4 Einführung in TypeScript (Seite 27) Das Grundlagenkapitel zuTypeScript wurde neu strukturiert und behandelt zusätzlich auchneuere Features von ECMAScript/TypeScript, z. B. Destrukturierung,Spread-Operator und Rest-Syntax.

10.1 HTTP-Kommunikation:einServer-Backendanbinden (Seite181)Das HTTP-Kapitel setzt durchgehend auf den HttpClient, der mit An-gular 4.3 eingeführt wurde. Dabei wird der Blick auch auf die erwei-terten Features des Clients geworfen. Themen, die spezifisch für RxJSsind, wurden aus diesem Kapitel herausgelöst und werden nun im RxJS-Kapitel behandelt.

14.4.1 Resolver: asynchroneDatenbeimRoutingvorladen (Seite427)Resolver sind aus unserer Sicht nicht die beste Wahl, um reguläre Da-ten über HTTP nachzuladen. Der Iterationsschritt zu Resolvern wurdedeshalb aus dem Beispielprojekt entfernt, und das Thema wird in dieserAuflage nur noch in der Theorie behandelt.

15.1 i18n:mehrere SprachenundKulturen anbieten (Seite 433) DieMöglichkeiten zur Konfiguration des Builds wurden mit Angu-lar 6 stark vorangebracht. Viele zuvor notwendige Kommandozeilen-parameter sind nun nicht mehr notwendig, die Konfigurationsdateiangular.json löst diese ab. Dadurch konnten wir das Kapitel zur In-ternationalisierung (i18n) kürzen und verständlicher gestalten. Im Ge-gensatz zur ersten Auflage zeigen wir nicht mehr, wie man eine An-wendung im JIT-Modus internationalisiert, der hauptsächlich für dieEntwicklung vorgesehen ist, aber nicht für produktive Anwendungen.

17.1 Softwaretests (Seite 457) Das Kapitel zum Testen von Angular-Anwendungen wurde stark erweitert. Neben den reinen Werkzeugenwird der Fokus besonders auf Philosophien, Patterns und Herangehens-weisen gelegt. Zusätzlich werden die mitgelieferten Tools zum Testenvon HTTP und Routing betrachtet.

22 NativeScript: mobile Anwendungen entwickeln (Seite 601) ZurEntwicklung einer nativen mobilen Anwendung nutzen wir in diesemKapitel die neue Version 3 von NativeScript, die insbesondere Verbes-serungen in Sachen Codegenerierung und Wiederverwendbarkeit vonCode mitbringt.


xviii Aktualisierungen in der zweiten Au�age

24.9 Change Detection (Seite 661) Das Kapitel zur Change Detec-tion wurde für besseres Verständnis neu strukturiert. Insbesondere wirdauf Debugging und Strategien zur Optimierung eingegangen.

SonstigesFür die einzelnen Iterationsschritte aus dem Beispielprojekt bieten wireine Differenzansicht an. So können die Änderungen am Code zwischenden einzelnen Kapiteln besser nachvollzogen werden. Wir gehen daraufauf Seite 49 genauer ein.

Zu guter Letzt haben wir an ausgewählten Stellen in diesem BuchZitate von bekannten Persönlichkeiten aus der Angular-Communityaufgeführt. Die meisten dieser Zitate haben wir direkt für dieses Bucherbeten. Wir freuen uns sehr, dass so viele interessante und humorvolleWorte diesem Buch eine einmalige Note geben.


xix

Inhaltsverzeichnis

Vorwort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii

I Einführung 1

1 Schnellstart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.1 Das HTML-Grundgerüst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.2 Die Startdatei für das Bootstrapping . . . . . . . . . . . . . . . . . . . . . . . . 61.3 Das zentrale Angular-Modul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.4 Die erste Komponente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 Haben Sie alles, was Sie benötigen? . . . . . . . . . . . . . . . . . . . . 112.1 Visual Studio Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2 Google Chromemit Augury . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.3 Paketverwaltung mit Node.js und NPM . . . . . . . . . . . . . . . . . . . . . 142.4 Codebeispiele in diesem Buch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3 Angular CLI: der Codegenerator für unser Projekt . . . . . . . . 213.1 Das o�zielle Tool für Angular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.2 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.3 Die wichtigsten Befehle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

II TypeScript 25

4 Einführung in TypeScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.1 Was ist TypeScript und wie setzen wir es ein? . . . . . . . . . . . . . . . . 274.2 Variablen: const, let und var . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.3 Die wichtigsten Basistypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.4 Klassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.5 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.6 Weitere Features von TypeScript und ES2015 . . . . . . . . . . . . . . . . 39

4.6.1 Template-Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.6.2 Arrow-Funktionen/Lambda-Ausdrücke . . . . . . . . . . . . . . 39


xx Inhaltsverzeichnis

4.6.3 Spread-Operator und Rest-Syntax . . . . . . . . . . . . . . . . . . 414.6.4 Union Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.6.5 Destrukturierende Zuweisungen . . . . . . . . . . . . . . . . . . . 44

4.7 Decorators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

III BookMonkey 3: Schritt für Schritt zur App 47

5 Projekt- und Prozessvorstellung . . . . . . . . . . . . . . . . . . . . . . . 495.1 Unser Projekt: BookMonkey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495.2 Projekt mit Angular CLI initialisieren . . . . . . . . . . . . . . . . . . . . . . . . 535.3 Style-Framework Semantic UI einbinden . . . . . . . . . . . . . . . . . . . . 65

6 Komponenten & Template-Syntax: Iteration I . . . . . . . . . . . 696.1 Komponenten: die Grundbausteine der Anwendung . . . . . . . . 69

6.1.1 Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706.1.2 Komponenten in der Anwendung verwenden . . . . . . . 756.1.3 Template-Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766.1.4 Den BookMonkey erstellen . . . . . . . . . . . . . . . . . . . . . . . . . 85

6.2 Property Bindings: mit Komponenten kommunizieren . . . . . . . 976.2.1 Komponenten verschachteln . . . . . . . . . . . . . . . . . . . . . . . 976.2.2 Eingehender Daten�uss mit Property Bindings . . . . . . 986.2.3 Andere Arten von Property Bindings . . . . . . . . . . . . . . . . 1016.2.4 DOM-Propertys in Komponenten auslesen . . . . . . . . . . 1036.2.5 Den BookMonkey erweitern . . . . . . . . . . . . . . . . . . . . . . . . 104

6.3 Event Bindings: auf Ereignisse in Komponenten reagieren . . . . 1086.3.1 Native DOM-Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1096.3.2 Eigene Events de�nieren . . . . . . . . . . . . . . . . . . . . . . . . . . . 1126.3.3 Den BookMonkey erweitern . . . . . . . . . . . . . . . . . . . . . . . . 113

7 Powertipp: Styleguide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

8 Services & Routing: Iteration II . . . . . . . . . . . . . . . . . . . . . . . . . 1258.1 Dependency Injection: Code in Services auslagern . . . . . . . . . . 125

8.1.1 Abhängigkeiten anfordern . . . . . . . . . . . . . . . . . . . . . . . . . 1278.1.2 Services in Angular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1288.1.3 Abhängigkeiten registrieren . . . . . . . . . . . . . . . . . . . . . . . . 1288.1.4 Abhängigkeiten ersetzen . . . . . . . . . . . . . . . . . . . . . . . . . . . 1318.1.5 Abhängigkeiten anfordern mit @Inject() . . . . . . . . . . . 1348.1.6 Eigene Tokens de�nieren mit InjectionToken . . . . . . . . 1348.1.7 Multiprovider: mehrere Abhängigkeiten im selben

Token . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1368.1.8 Zirkuläre Abhängigkeiten au�ösen mit forwardRef . . . 136


Inhaltsverzeichnis xxi

8.1.9 Provider in Komponenten registrieren . . . . . . . . . . . . . . 1368.1.10 Den BookMonkey erweitern . . . . . . . . . . . . . . . . . . . . . . . . 137

8.2 Routing: durch die Anwendung navigieren . . . . . . . . . . . . . . . . . . 1418.2.1 Routen kon�gurieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1438.2.2 Routing-Modul einbauen . . . . . . . . . . . . . . . . . . . . . . . . . . 1448.2.3 Komponenten anzeigen . . . . . . . . . . . . . . . . . . . . . . . . . . . 1468.2.4 Root-Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1468.2.5 Routen verlinken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1478.2.6 Routenparameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1498.2.7 Verschachtelung von Routen . . . . . . . . . . . . . . . . . . . . . . . 1528.2.8 Routenweiterleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1548.2.9 Aktive Links stylen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1568.2.10 Route programmatisch wechseln . . . . . . . . . . . . . . . . . . . 1568.2.11 Den BookMonkey erweitern . . . . . . . . . . . . . . . . . . . . . . . . 158

9 Powertipp: Chrome Developer Tools . . . . . . . . . . . . . . . . . . . 169

10 HTTP & reaktive Programmierung: Iteration III . . . . . . . . . . 18110.1 HTTP-Kommunikation: ein Server-Backend anbinden . . . . . . . . 181

10.1.1 Modul einbinden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18310.1.2 Requests mit dem HttpClient durchführen . . . . . . . . . . 18310.1.3 Optionen für den HttpClient . . . . . . . . . . . . . . . . . . . . . . . 18510.1.4 Den BookMonkey erweitern . . . . . . . . . . . . . . . . . . . . . . . . 188

10.2 Reaktive Programmierung mit RxJS . . . . . . . . . . . . . . . . . . . . . . . . . 19810.2.1 Alles ist ein Datenstrom . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19810.2.2 Observables sind Funktionen . . . . . . . . . . . . . . . . . . . . . . . 20010.2.3 Das Observable aus RxJS . . . . . . . . . . . . . . . . . . . . . . . . . . . 20210.2.4 Observables abonnieren . . . . . . . . . . . . . . . . . . . . . . . . . . . 20310.2.5 Observables erzeugen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20510.2.6 Operatoren: Datenströme modellieren . . . . . . . . . . . . . . 20710.2.7 Heiße Observables, Multicasting und Subjects . . . . . . . 21310.2.8 Subscriptions verwalten & Memory Leaks vermeiden 21710.2.9 Flattening-Strategien für Higher-Order Observables . 22010.2.10 Den BookMonkey erweitern: Daten vom Server

typisieren und umwandeln . . . . . . . . . . . . . . . . . . . . . . . . . 22410.2.11 Den BookMonkey erweitern: Fehlerbehandlung . . . . . 22910.2.12 Den BookMonkey erweitern: Typeahead-Suche . . . . . 233

10.3 Interceptoren: HTTP-Requests abfangen und transformieren . 24510.3.1 Warum HTTP-Interceptoren nutzen? . . . . . . . . . . . . . . . . 24510.3.2 Funktionsweise der Interceptoren . . . . . . . . . . . . . . . . . . 24510.3.3 Interceptoren anlegen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24610.3.4 Interceptoren einbinden . . . . . . . . . . . . . . . . . . . . . . . . . . . 24810.3.5 Den BookMonkey erweitern . . . . . . . . . . . . . . . . . . . . . . . . 250


xxii Inhaltsverzeichnis

11 Powertipp: Augury . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257

12 Formularverarbeitung & Validierung: Iteration IV . . . . . . . . 26112.1 Angulars Ansätze für Formulare . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26212.2 Template-Driven Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262

12.2.1 FormsModule einbinden . . . . . . . . . . . . . . . . . . . . . . . . . . . 26312.2.2 Datenmodell in der Komponente . . . . . . . . . . . . . . . . . . . 26312.2.3 Template mit Two-Way Binding und ngModel . . . . . . . . . 26412.2.4 Formularzustand verarbeiten . . . . . . . . . . . . . . . . . . . . . . . 26512.2.5 Eingaben validieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26612.2.6 Formular abschicken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26712.2.7 Formular zurücksetzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26812.2.8 Den BookMonkey erweitern . . . . . . . . . . . . . . . . . . . . . . . . 269

12.3 Reactive Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28812.3.1 Warum ein zweiter Ansatz für Formulare? . . . . . . . . . . . 28812.3.2 Modul einbinden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28912.3.3 Formularmodell in der Komponente . . . . . . . . . . . . . . . . 28912.3.4 Template mit demModell verknüpfen . . . . . . . . . . . . . . 29212.3.5 Formularzustand verarbeiten . . . . . . . . . . . . . . . . . . . . . . . 29412.3.6 Eingebaute Validatoren nutzen . . . . . . . . . . . . . . . . . . . . . 29412.3.7 Formular abschicken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29612.3.8 Formular zurücksetzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29612.3.9 Formularwerte setzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29712.3.10 FormBuilder verwenden . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29812.3.11 Änderungen überwachen . . . . . . . . . . . . . . . . . . . . . . . . . . 29912.3.12 Den BookMonkey erweitern . . . . . . . . . . . . . . . . . . . . . . . . 300

12.4 Eigene Validatoren entwickeln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32012.4.1 Validatoren für einzelne Formularfelder . . . . . . . . . . . . . 32012.4.2 Validatoren für Formulargruppen und -Arrays . . . . . . . 32312.4.3 Asynchrone Validatoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32512.4.4 Den BookMonkey erweitern . . . . . . . . . . . . . . . . . . . . . . . . 328

12.5 Welcher Ansatz ist der richtige? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336

13 Pipes & Direktiven: Iteration V . . . . . . . . . . . . . . . . . . . . . . . . . 33913.1 Pipes: Daten im Template formatieren . . . . . . . . . . . . . . . . . . . . . . 339

13.1.1 Pipes verwenden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33913.1.2 Die Sprache fest einstellen . . . . . . . . . . . . . . . . . . . . . . . . . 34013.1.3 Eingebaute Pipes für den sofortigen Einsatz . . . . . . . . . 34213.1.4 Eigene Pipes entwickeln . . . . . . . . . . . . . . . . . . . . . . . . . . . 35313.1.5 Pipes in Komponenten nutzen . . . . . . . . . . . . . . . . . . . . . . 35513.1.6 Den BookMonkey erweitern: Datum formatieren

mit der DatePipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357


Inhaltsverzeichnis xxiii

13.1.7 Den BookMonkey erweitern: Observable mit derAsyncPipe au�ösen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358

13.1.8 Den BookMonkey erweitern: eigene Pipe für dieISBN implementieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362

13.2 Direktiven: das Vokabular von HTML erweitern . . . . . . . . . . . . . . 36513.2.1 Was sind Direktiven? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36513.2.2 Eigene Direktiven entwickeln . . . . . . . . . . . . . . . . . . . . . . . 36613.2.3 Attributdirektiven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36813.2.4 Strukturdirektiven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37313.2.5 Den BookMonkey erweitern: Attributdirektive für

vergrößerte Darstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37813.2.6 Den BookMonkey erweitern: Strukturdirektive für

zeitverzögerte Sterne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381

14 Module & fortgeschrittenes Routing: Iteration VI . . . . . . . . 38714.1 Die Anwendung modularisieren: Das Modulkonzept

von Angular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38714.1.1 Module in Angular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38714.1.2 Grundaufbau eines Moduls . . . . . . . . . . . . . . . . . . . . . . . . . 38814.1.3 Bestandteile eines Moduls deklarieren . . . . . . . . . . . . . . 38914.1.4 Anwendung in Feature-Module aufteilen . . . . . . . . . . . 39114.1.5 Aus Modulen exportieren: Shared Module . . . . . . . . . . 39414.1.6 Den BookMonkey erweitern . . . . . . . . . . . . . . . . . . . . . . . . 395

14.2 Lazy Loading: Angular-Module asynchron laden . . . . . . . . . . . . . 40514.2.1 WarumModule asynchron laden? . . . . . . . . . . . . . . . . . . 40614.2.2 Lazy Loading verwenden . . . . . . . . . . . . . . . . . . . . . . . . . . . 40614.2.3 Module asynchron vorladen: Preloading . . . . . . . . . . . . 41014.2.4 Den BookMonkey erweitern . . . . . . . . . . . . . . . . . . . . . . . . 411

14.3 Guards: Routen absichern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41614.3.1 Grundlagen zu Guards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41714.3.2 Guards implementieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41714.3.3 Guards verwenden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42014.3.4 Den BookMonkey erweitern . . . . . . . . . . . . . . . . . . . . . . . . 421

14.4 Routing: Wie geht’s weiter? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42714.4.1 Resolver: asynchrone Daten beim Routing vorladen . 42714.4.2 Mehrere RouterOutlets verwenden . . . . . . . . . . . . . . . . . 431

15 Internationalisierung: Iteration VII . . . . . . . . . . . . . . . . . . . . . 43315.1 i18n: mehrere Sprachen und Kulturen anbieten . . . . . . . . . . . . . 433

15.1.1 Was bedeutet Internationalisierung? . . . . . . . . . . . . . . . . 43315.1.2 Eingebaute Pipes mehrsprachig verwenden . . . . . . . . . 43415.1.3 Texte in den Templates übersetzen . . . . . . . . . . . . . . . . . 43615.1.4 Nachrichten mit dem i18n-Attribut markieren . . . . . . . 437


xxiv Inhaltsverzeichnis

15.1.5 Nachrichten extrahieren und übersetzen . . . . . . . . . . . . 43815.1.6 Feste IDs vergeben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43915.1.7 Die App für Übersetzungen kon�gurieren . . . . . . . . . . . 44015.1.8 Den BookMonkey erweitern . . . . . . . . . . . . . . . . . . . . . . . . 442

16 Powertipp: POEditor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451

17 Qualität fördernmit Softwaretests . . . . . . . . . . . . . . . . . . . . . 45717.1 Softwaretests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457

17.1.1 Testabdeckung: Was sollte man testen? . . . . . . . . . . . . . 45917.1.2 Testart: Wie sollte man testen? . . . . . . . . . . . . . . . . . . . . . . 45917.1.3 Test-Framework Jasmine . . . . . . . . . . . . . . . . . . . . . . . . . . . 46117.1.4 »Arrange, Act, Assert« mit Jasmine . . . . . . . . . . . . . . . . . . 46417.1.5 Test-Runner Karma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46617.1.6 E2E-Test-Runner Protractor . . . . . . . . . . . . . . . . . . . . . . . . . 46717.1.7 Weitere Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468

17.2 Tests mit Karma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47017.2.1 TestBed: die Testbibliothek von Angular . . . . . . . . . . . . . 47017.2.2 Isolierte Unit-Tests: Services testen . . . . . . . . . . . . . . . . . . 47117.2.3 Isolierte Unit-Tests: Pipes testen . . . . . . . . . . . . . . . . . . . . 47317.2.4 Isolierte Unit-Tests: Komponenten testen . . . . . . . . . . . . 47417.2.5 Shallow Unit-Tests: einzelne Komponenten testen . . . 47717.2.6 Integrationstests: mehrere Komponenten testen . . . . 48017.2.7 Abhängigkeiten durch Stubs ersetzen . . . . . . . . . . . . . . 48217.2.8 Abhängigkeiten durch Mocks ersetzen . . . . . . . . . . . . . . 48717.2.9 Leere Komponenten als Stubs oder Mocks einsetzen 48917.2.10 HTTP-Requests testen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49017.2.11 Komponenten mit Routen testen . . . . . . . . . . . . . . . . . . . 49417.2.12 Asynchronen Code testen . . . . . . . . . . . . . . . . . . . . . . . . . . 498

17.3 Tests mit Protractor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50017.3.1 Auf die Balance kommt es an . . . . . . . . . . . . . . . . . . . . . . . 50017.3.2 Protractor verwenden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50117.3.3 Elemente selektieren: Locators . . . . . . . . . . . . . . . . . . . . . 50217.3.4 Aktionen durchführen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50317.3.5 Asynchron mit Warteschlange . . . . . . . . . . . . . . . . . . . . . . 50417.3.6 Redundanz durch Page Objects vermeiden . . . . . . . . . . 50517.3.7 Eine Angular-Anwendung testen . . . . . . . . . . . . . . . . . . . 506

IV Das Projekt ausliefern: Deployment 511

18 Das Projekt ausliefern: Deployment . . . . . . . . . . . . . . . . . . . . 51318.1 Umgebungen kon�gurieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513


Inhaltsverzeichnis xxv

18.1.1 Abhängigkeit zur Umgebung vermeiden . . . . . . . . . . . . 51618.1.2 Kon�gurationen und Umgebungen am Beispiel:

BookMonkey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51718.2 Produktivmodus aktivieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51818.3 Build erzeugen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51918.4 Die Templates kompilieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522

18.4.1 Just-in-Time-Kompilierung (JIT) . . . . . . . . . . . . . . . . . . . . . 52218.4.2 Ahead-of-Time-Kompilierung (AOT) . . . . . . . . . . . . . . . . 523

18.5 Webserver kon�gurieren und die Anwendung ausliefern . . . . . 52618.6 Ausblick: Automatisches Deployment . . . . . . . . . . . . . . . . . . . . . . . 53018.7 Ausblick: Deployment mit Docker . . . . . . . . . . . . . . . . . . . . . . . . . . 531

V Weiterführende Themen 535

19 Server-Side Renderingmit Angular Universal . . . . . . . . . . . 53719.1 Single-Page-Anwendungen, Suchmaschinen und Start-

Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53819.2 Dynamisches Server-Side Rendering . . . . . . . . . . . . . . . . . . . . . . . . 54119.3 Statisches Pre-Rendering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54719.4 Wann setze ich serverseitiges Rendering ein? . . . . . . . . . . . . . . . . 551

20 State Management mit Redux . . . . . . . . . . . . . . . . . . . . . . . . . 55320.1 Ein Modell für zentrales State Management . . . . . . . . . . . . . . . . . 55420.2 Das Architekturmodell Redux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56420.3 Redux mit NgRx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567

20.3.1 Projekt vorbereiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56720.3.2 Store einrichten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56720.3.3 Schematics nutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56820.3.4 Grundstruktur des Stores . . . . . . . . . . . . . . . . . . . . . . . . . . . 56820.3.5 Feature anlegen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57020.3.6 Struktur des Feature-States de�nieren . . . . . . . . . . . . . . 57220.3.7 Actions: Kommunikation mit dem Store . . . . . . . . . . . . . 57320.3.8 Dispatch: Actions in den Store senden . . . . . . . . . . . . . . 57620.3.9 Reducer: den State aktualisieren . . . . . . . . . . . . . . . . . . . . 57720.3.10 Selektoren: Daten aus dem State lesen . . . . . . . . . . . . . . 58020.3.11 E�ects: Seitene�ekte ausführen . . . . . . . . . . . . . . . . . . . . 584

20.4 Redux und NgRx: Wie geht’s weiter? . . . . . . . . . . . . . . . . . . . . . . . . 58920.4.1 Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59020.4.2 Entity Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59020.4.3 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593

21 Powertipp: Redux DevTools . . . . . . . . . . . . . . . . . . . . . . . . . . . 597


xxvi Inhaltsverzeichnis

22 NativeScript: mobile Anwendungen entwickeln . . . . . . . . . 60122.1 Mobile Apps entwickeln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60122.2 Was ist NativeScript? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60222.3 Warum NativeScript? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60322.4 Hinter den Kulissen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60522.5 Plattformspezi�scher Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60622.6 Widgets und Layouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60722.7 Styling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60822.8 NativeScript und Angular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60922.9 Angular als Native App . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61022.10 NativeScript installieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61122.11 Ein Shared Project erstellen mit der Angular CLI . . . . . . . . . . . . . 61122.12 Den BookMonkey mit NativeScript umsetzen . . . . . . . . . . . . . . . 615

22.12.1 Das Projekt mit den NativeScript Schematicserweitern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616

22.12.2 Die Anwendung starten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61622.12.3 Das angepasste Bootstrapping für NativeScript . . . . . . 62022.12.4 Das Root-Modul anpassen . . . . . . . . . . . . . . . . . . . . . . . . . . 62122.12.5 Das Routing anpassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62322.12.6 Die Templates der Komponenten für NativeScript

anlegen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625

23 Powertipp: Android-Emulator Genymotion . . . . . . . . . . . . . 637

24 Wissenswertes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64124.1 Container und Presentational Components . . . . . . . . . . . . . . . . . 64124.2 Else-Block für die Direktive ngIf . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64524.3 TrackBy-Funktion für die Direktive ngFor . . . . . . . . . . . . . . . . . . . . 64624.4 Schematics: Codegenerierung mit der Angular CLI . . . . . . . . . . . 64824.5 Angular-Anwendungen dokumentieren und analysieren . . . . . 65024.6 Angular Material und weitere UI-Komponentensammlungen 654

24.6.1 Angular Material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65424.6.2 ng-bootstrap & ngx-bootstrap . . . . . . . . . . . . . . . . . . . . . . 65524.6.3 PrimeNG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65624.6.4 Kendo UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656

24.7 Lifecycle-Hooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65624.8 Content Projection: Inhalt des Host-Elements verwenden . . . . 66024.9 Change Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66124.10 Plattformen und Renderer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67324.11 Angular updaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67524.12 Upgrade von AngularJS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 677


Inhaltsverzeichnis xxvii

VI Anhang 683

A Befehle der Angular CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685

B Operatoren von RxJS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 691

C Matcher von Jasmine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695

D Abkürzungsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697

E Linkliste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707

Weiterführende Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715

Nachwort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 717

In dieser Leseprobe fehlen einige Buchseiten.Wenn du ab hier gerne weiterlesen möchtest, solltest du dieses Buch erwerben.

291

Teil IITypeScript

Woiwode_Trennseite II.fm Seite 291 Mittwoch, 12. April 2017 12:06 12


27

4 Einführung in TypeScript

»In any modern frontend project, TypeScript isan absolute no-brainer to me. No types, no way!«

Marius Schulz(Front End Engineer und Trainer für JavaScript)

Für die Entwicklung mit Angular werden wir die ProgrammierspracheTypeScript verwenden. Doch keine Angst – Sie müssen keine neue Spra-che erlernen, um mit Angular arbeiten zu können, denn TypeScript isteine Obermenge von JavaScript.

Wenn Sie bereits erste Erfahrungen mit TypeScript gemacht haben,können Sie dieses Kapitel überfliegen oder sogar überspringen. VieleEigenheiten werden wir auch auf dem Weg durch unsere Beispielan-wendung kennenlernen. Wenn Sie unsicher sind oder TypeScript undmodernes JavaScript für Sie noch Neuland sind, dann ist dieses Kapiteldas Richtige für Sie. Wir wollen in diesem Kapitel die wichtigsten Fea-tures von TypeScript erläutern, damit Sie für den Einstieg in Angularbestens gewappnet sind. Wir werden die wichtigsten Sprachelementevon TypeScript kennenlernen, sodass es uns im weiteren Verlauf desBuchs leichtfällt, die gezeigten Codebeispiele zu verstehen.

Sie können dieses Kapitel später als Referenz verwenden, wenn Siemit TypeScript einmal nicht weiterwissen. Auf geht’s!

4.1 Was ist TypeScript und wie setzen wir esein?

TypeScript ist eine Obermenge von JavaScript. Die Sprache greift dieaktuellen ECMAScript-Standards auf und integriert zusätzliche Fea-tures, unter anderem ein statisches Typsystem. Das bedeutet allerdingsnicht, dass Sie eine komplett neue Programmiersprache lernen müssen.Ihr bestehendes Wissen zu JavaScript bleibt weiterhin anwendbar, dennTypeScript erweitert lediglich den existierenden Sprachstandard. JedesProgramm, das in JavaScript geschrieben wurde, funktioniert auch inTypeScript.


28 4 Einführung in TypeScript

TypeScript integriertFeatures auskommenden

JavaScript-Standards.

TypeScript unterstützt neben den existierenden JavaScript-Featuresauch Sprachbestandteile aus zukünftigen Standards. Das hat den Vor-teil, dass wir das Set an Sprachfeatures genau kennen und alle ver-wendeten Konstrukte in allen gängigen Browsern unterstützt werden.Wir müssen also nicht lange darauf warten, dass ein Sprachfeature ir-gendwann einmal direkt vom Browser unterstützt wird, und könnenstattdessen sofort loslegen. Zusätzlich bringt TypeScript ein statischesTypsystem mit, mit dem wir schon zur Entwicklungszeit eine hervorra-gende Unterstützung durch den Editor und das Build-Tooling genießenkönnen.

TypeScript-Compiler TypeScript ist nicht im Browser lauffähig, denn zusammen mitdem Typsystem und neuen Features handelt es sich nicht mehr umreines JavaScript. Deshalb wird der TypeScript-Code vor der Aus-lieferung wieder in JavaScript umgewandelt. Für diesen Prozess istder TypeScript-Compiler verantwortlich. Man spricht dabei auch vonTranspilierung, weil der Code lediglich in eine andere Sprache übertra-gen wird. Alle verwendeten Sprachkonstrukte werden so umgewandelt,dass sie dieselbe Semantik besitzen, aber nur die Mittel nutzen, die tat-sächlich von JavaScript in der jeweiligen Version unterstützt werden.Die statische Typisierung geht bei diesem Schritt verloren. Das bedeu-tet, dass das Programm zur Laufzeit keine Typen mehr besitzt, dennes ist ein reines JavaScript-Programm. Durch die Typunterstützung beider Entwicklung und beim Build können allerdings schon die meistenFehler erschlagen werden.

Abbildung 4–1 zeigt, wie TypeScript die bestehenden JavaScript-Versionen erweitert. Der Standard ECMAScript 2016 hat keine nen-nenswerten Features gebracht, sodass dieser nicht weiter erwähnt wer-den muss. TypeScript vereint viele Features aus aktuellen und kommen-den ECMAScript-Versionen, sodass wir sie problemlos auch für ältereBrowser einsetzen können.

Verwirrung um die ECMAScript-Versionen

Der JavaScript-Sprachkernwurde über viele Jahre hinweg durch die EuropeanComputerManufacturers Association (ECMA)weiterentwickelt. Dabeiwurdendie Versionen zunächst fortlaufend durchnummeriert: ES1, ES2, ES3, ES4, ES5.

Noch während die nächste Version spezi�ziert wurde, war bereits der Na-me ES6 in aller Munde. Kurz vor Verö�entlichung des neuen Sprachstandardsentschied sich jedoch das technische Komitee der ECMA dazu, eine neue Na-menskonvention einzuführen. Da fortan jährlich eine neue Version erscheinensoll, wurde die Bezeichnung vom schon vielerseits etablierten ES6 zu ECMA-Script 2015 geändert.

Aufgrund der parallelen Entwicklung vieler Poly�lls und Frameworks �n-det man in einschlägiger Literatur und auch in vielen Entwicklungsprojektennoch die Bezeichnung ES6.


4.1 Was ist TypeScript und wie setzen wir es ein? 29

Abb. 4–1TypeScript undECMAScript

ES5

ES2015Klassen, Module,Arrow Functions

ES2018Spread Operator

TypeScriptStarke Typisierung

ES2017async/await

Abb. 4–2Unterstützungdurch den Editor:Type InformationOn Hover

TypeScript ist als Open-Source-Projekt bei der Firma Microsoft ent-standen.1 TypisierungDurch die Typisierung können Fehler bereits zur Entwick-lungszeit erkannt werden. Außerdem können Tools den Code genau-er analysieren. Dies ermöglicht Komfortfunktionen wie automatischeVervollständigung, Navigation zwischen Methoden und Klassen, einesolide Refactoring-Unterstützung und automatische Dokumentation inder Entwicklungsumgebung. TypeScript kompiliert in reines JavaScript(unter anderem nach ES5) und ist dadurch in allen Browsern und aufallen Plattformen ausführbar.

NeueJavaScript-Featuresauf einen Blick

Bei Interesse können Sie mithilfe einer Kompatibilitätstabelle2 einenguten Überblick erhalten, welche Features der verschiedenen Standardsbereits implementiert wurden.

1https://ng-buch.de/a/26 – TypeScript2https://ng-buch.de/a/27 – ECMAScript compatibility table


291

Teil IIIBookMonkey 3:

Schritt für Schritt zur App

Woiwode_Trennseite III.fm Seite 291 Mittwoch, 12. April 2017 12:11 12


69

6 Komponenten & Template-Syntax:Iteration I

»To be or not to be DOM. That’s the question.«

Igor Minar(Angular Lead Developer)

Nun, da unsere Projektumgebung vorbereitet ist, können wir beginnen,die ersten Schritte bei der Implementierung des BookMonkeys zu ma-chen. Wir wollen in dieser Iteration die wichtigsten Grundlagen vonAngular betrachten. Wir lernen zunächst das Prinzip der komponen-tenbasierten Entwicklung kennen und tauchen in die Template-Syntaxvon Angular ein. Zwei elementare Konzepte – die Property und EventBindings – schauen wir uns dabei sehr ausführlich an.

Die Grundlagen von Angular sind umfangreich, deshalb müssenwir viel erläutern, bevor es mit der Implementierung losgeht. Aller An-fang ist schwer, aber haben Sie keine Angst: Sobald Sie die Konzepteverinnerlicht haben, werden sie Ihnen den Entwickleralltag angeneh-mer machen!

6.1 Komponenten: die Grundbausteine derAnwendung

Wir betrachten in diesem Abschnitt das Grundkonzept der Kompo-nenten. Auf dem Weg lernen wir die verschiedenen Bestandteile derTemplate-Syntax kennen. Anschließend entwickeln wir mit der Listen-ansicht die erste Komponente für unsere Beispielanwendung.


70 6 Komponenten & Template-Syntax: Iteration I

6.1.1 Komponenten

Komponenten sind die Grundbausteine einer Angular-Anwendung. Je-de Anwendung ist aus vielen verschiedenen Komponenten zusammen-gesetzt, die jeweils eine bestimmte Aufgabe erfüllen. Eine Komponentebeschreibt somit immer einen kleinen Teil der Anwendung, z. B. eineSeite oder ein einzelnes UI-Element.

Hauptkomponente Jede Anwendung besitzt mindestens eine Komponente, die Haupt-komponente (engl. Root Component). Alle weiteren Komponenten sinddieser Hauptkomponente untergeordnet.Eine Komponente

besitzt immer einTemplate.

Eine Komponente hat außer-dem einen Anzeigebereich, die View, in dem ein Template dargestelltwird. Das Template ist das »Gesicht« der Komponente, also der Be-reich, den der Nutzer sieht.

An eine Komponente wird üblicherweise Logik geknüpft, die dieInteraktion mit dem Nutzer möglich macht.

Komponente: Klassemit Decorator

@Component()

Das Grundgerüst sieht wie folgt aus: Eine Komponente besteht auseiner TypeScript-Klasse, die mit einem Template verknüpft wird. DieKlasse wird immer mit dem Decorator @Component() eingeleitet. DasListing 6–1 zeigt den Grundaufbau einer Komponente.

Was ist ein Decorator?

Decorators dienen der Angabe von Metainformationen zu einer Komponen-te. Der Einsatz von Metadaten fördert die Übersichtlichkeit im Code, da Kon�-guration und Ablaufsteuerung sauber voneinander getrennt werden. Wermitder Verwendung von Decorators noch nicht vertraut ist, sollte sich den Ab-schnitt »Decorators« auf Seite 46 durchlesen.

Listing 6–1Eine simple

Komponente

@Component({selector: 'my-component',template: '<h1>Hallo Angular!</h1>'

})export class MyComponent { }

Metadaten Dem Decorator werden die Metadaten für die Komponente überge-ben. Beispielsweise wird hier mit der Eigenschaft template das Templa-te für die Komponente festgelegt.Selektor Im Property selector wird ein CSS-Selektor angegeben. Damit wird ein DOM-Element ausgewählt, an dasdie Komponente gebunden wird.


6.1 Komponenten: die Grundbausteine der Anwendung 71

Was ist ein CSS-Selektor?

Mit CSS-Selektoren wählen wir Elemente aus dem DOM aus. Es handelt sichum dieselbe Syntax, die wir in CSS-Stylesheets verwenden, um Elementeneinen Stil zuzuweisen. In Angular nutzen wir den Selektor unter anderem, umeine Komponente an eine Auswahl von Elementen zu binden. In Tabelle 6–1sind die geläu�gsten Selektoren aufgelistet. Selektoren können kombiniertwerden, um die Auswahl weiter einzuschränken. Die Möglichkeiten sind sehrvielfältig, und wir nennen an dieser Stelle nur einige Beispiele:

n div.active – Containerelemente, die die CSS-Klasse active besitzen

n input[type=text] – Eingabefelder vom Typ text

n li:nth-child(2) – jedes zweite Listenelement innerhalb desselbenElternelements

Tab. 6–1Geläu�geCSS-Selektoren

Selektor Beschreibung

my-element Elemente mit dem Namen my-elementBeispiel: <my-element></my-element>

[myAttr] Elemente mit dem Attribut myAttrBeispiel: <div myAttr="foo"></div>

[myAttr=bar] Elemente mit dem Attribut myAttr und Wert barBeispiel: <div myAttr="bar"></div>

.my-class Elemente mit der CSS-Klasse my-classBeispiel: <div class="my-class"></div>

Host-ElementDas Element, das durch den Selektor ausgewählt wurde, stellt dann dieLogik und das Template der Komponente bereit und wird deshalb alsHost-Element bezeichnet. Wir betrachten noch einmal das Listing 6–1:Verwenden wir das DOM-Element <my-component> in unserem Templa-te, so wird Angular den vorherigen Inhalt des Elements mit dem neuenInhalt der Komponente ersetzen. Das Element <my-component> wird dasHost-Element für diese Komponente, und es wird folgendes Markuperzeugt:

Listing 6–2Erzeugtes Markup fürdie KomponenteMyComponent

<my-component><h1>Hallo Angular!</h1>

</my-component>

Wir können dieses Element an beliebiger Stelle in unseren Templatesverwenden – es wird immer durch die zugehörige Komponente ersetzt.Auf diese Weise können wir Komponenten beliebig tief verschachteln,indem wir im Template einer Komponente das Host-Element einer an-



deren einsetzen usw. Diese Praxis schauen wir uns im nächsten Kapitelab Seite 97 genauer an.

Komponenten solltennur auf Elementnamen

selektieren.

Es ist eine gute Praxis, stets nur Elementnamen zu verwenden, umKomponenten einzubinden. Das Prinzip der Komponente – Templateund angeheftete Logik – kann durch ein eigenständiges Element amsinnvollsten abgebildet werden. Wenn wir auf die Attribute eines Ele-ments selektieren wollen, so sind Attributdirektiven ein sinnvoller Bau-stein. Wie das funktioniert und wie wir eigene Direktiven implementie-ren können, schauen wir uns ab Seite 365 an.

Das Template einer Komponente

Eine Komponente ist immer mit einem Template verknüpft. Das Tem-plate ist der Teil der Komponente, den der Nutzer sieht und mit demer interagieren kann. Für die Beschreibung wird meist HTML verwen-det� , denn wir wollen unsere Anwendung ja im Browser ausführen. In-nerhalb der Templates wird allerdings eine Angular-spezifische Syntaxeingesetzt, denn Komponenten können weit mehr, als nur statischesHTML darzustellen. Diese Syntax schauen wir uns im Verlauf diesesKapitels noch genauer an.

Um eine Komponente mit einem Template zu verknüpfen, gibt eszwei Wege:

n Template-URL: Das Template liegt in einer eigenständigen HTML-Datei, die in der Komponente referenziert wird (templateUrl).

n Inline Template: Das Template wird als (mehrzeiliger) String imQuelltext der Komponente angegeben (template).

In beiden Fällen verwenden wir die Metadaten des @Component()-Deco-rators, um die Infos anzugeben. Im Listing 6–3 sind beide Variantenzur Veranschaulichung aufgeführt.Eine Komponente

besitzt genau einTemplate.

Es kann allerdings immer nur einerder beiden Wege verwendet werden, denn eine Komponente besitzt nurein einziges Template. Die Angular CLI legt stets eine separate Dateifür das Template an, sofern wir es nicht anders einstellen. Das ist auchdie Variante, die wir Ihnen empfehlen möchten, um die Struktur über-sichtlich zu halten.

� Später im Kapitel zu NativeScript (ab Seite 601) werden wir einen Einsatz-zweck ohne HTML kennenlernen.



Listing 6–3Template einerKomponente de�nieren

@Component({

// Als Referenz zu einem HTML-TemplatetemplateUrl: './my-component.html',

// ODER: als HTML-String direkt im TypeScripttemplate: `<h1>

Hallo Angular!</h1>`,

// [...]})export class MyComponent { }

Bindings für dieKommunikationzwischen Komponenteund Template

Template und Komponente sind eng miteinander verknüpft und kön-nen über klar definierte Wege miteinander kommunizieren. Der Infor-mationsaustausch findet über sogenannte Bindings statt. Damit »flie-ßen« die Daten von der Komponente ins Template und können dortdem Nutzer präsentiert werden. Umgekehrt können Ereignisse im Tem-plate abgefangen werden, um von der Komponente verarbeitet zu wer-den. Diese Kommunikation ist schematisch in Abbildung 6–1 darge-stellt.

Abb. 6–1Komponente, Templateund Bindings imZusammenspiel

Um diese Bindings zu steuern, nutzen wir die Template-Syntax von An-gular, die wir gleich noch genauer betrachten. In den beiden folgendenStorys dieser Iteration gehen wir außerdem gezielt auf die verschiedenenArten von Bindings ein.

Der Style einer Komponente

Um das Aussehen einer Komponente zu beeinflussen, werden Style-sheets eingesetzt, wie wir sie allgemein aus der Webentwicklung ken-nen. Neben den reinen Cascading Style Sheets (CSS) können wir auchverschiedene Präprozessoren einsetzen: Sass, Less und Stylus werden di-rekt unterstützt. Welches Style-Format wir standardmäßig verwendenwollen, können wir auswählen, wenn wir die Anwendung mit ng newerstellen.



Normalerweise verwendet man eine große, globale Style-Datei, diealle gestalterischen Aspekte der Anwendung definiert. Das ist nicht im-mer schön, denn hier kann man leicht den Überblick verlieren, welcheSelektoren wo genau aktiv sind oder womöglich gar nicht mehr benö-tigt werden. Außerdem widerspricht eine globale Style-Definition demmodularen Prinzip der Komponenten.

Stylesheets vonKomponenten sind

isoliert.

Angular zeigt hier einen neuen Weg auf und ordnet die Styles direktden Komponenten zu. Diese direkte Verknüpfung von Styles und Kom-ponenten sorgt dafür, dass die Styles einen begrenzten Gültigkeitsbe-reich haben und nur in ihrer jeweiligen Komponente gültig sind. Stylesvon zwei voneinander unabhängigen Komponenten können sich damitnicht gegenseitig beeinflussen, sind bedeutend übersichtlicher und lie-gen immer direkt am »Ort des Geschehens« vor.

Ein Blick ins Innere: View Encapsulation

Styles werden einer Komponente zugeordnet und wirken damit auch nur aufdie Inhalte dieser Komponente. Die Technik dahinter nennt sich ViewEncapsu-lation und isoliert den Gültigkeitsbereich eines Anzeigebereichs von anderen.Jedes DOM-Element in einer Komponente erhält automatisch ein zusätzlichesAttribut mit einem zufälligen Bezeichner, siehe Screenshot. Die vom Entwick-ler festgelegten Styles werden abgeändert, sodass sie nur für dieses Attributwirken. So funktioniert der Style nur in der Komponente, in der er deklariertwurde. Es gibt noch andere Strategiender ViewEncapsulation, auf diewir aberhier nicht eingehen wollen.

Angular generiert automatisch Attribute für die View Encapsulation.

Die Styles werden ebenfalls in den Metadaten einer Komponente an-gegeben. Dafür sind zwei Wege möglich, die wir auch schon von denTemplates kennen:

n Style-URL: Es wird eine CSS-Datei mit Style-Definitionen einge-bunden (styleUrls).

n Inline Styles: Die Styles werden direkt in der Komponente definiert(styles).

Im Listing 6–4 werden beide Wege gezeigt. Wichtig ist, dass die Dateienund Styles jeweils als Arrays angelegt werden. Grundsätzlich empfehlenwir Ihnen auch hier, für die Styles eine eigene Datei anzulegen und in



der Komponente zu referenzieren. Die Angular CLI unterstützt beideVarianten.

Der herkömmliche Weg zum Einbinden von Styles ist natürlichtrotzdem weiter möglich: Wir können globale CSS-Dateien definie-ren, die in der gesamten Anwendung gelten und nicht nur auf Ebe-ne der Komponenten. Diesen Weg haben wir gewählt, um das Style-Framework Semantic UI einzubinden, siehe Seite 65.

Listing 6–4Style-De�nitionen inKomponenten

@Component({styleUrls: ['./my.component.css'],// ODERstyles: ['h2 { color:blue }','h1 { font-size: 3em }'

],// [...]

})export class MyComponent { }

6.1.2 Komponenten in der Anwendung verwenden

Rule of OneEine Komponente wird immer in einer eigenen TypeScript-Datei no-tiert. Dahinter steht das Rule of One: Eine Datei beinhaltet immer ge-nau einen Bestandteil und nicht mehr. Dazu kommen meist ein sepa-rates Template, eine Style-Datei und eine Testspezifikation. Diese vierDateien sollten wir immer gemeinsam in einem eigenen Ordner unter-bringen. So wissen wir sofort, welche Dateien zu der Komponente ge-hören.

Eine Komponente besitzt einen Selektor und wird automatisch andie DOM-Elemente gebunden, die auf diesen Selektor matchen. Dasjeweilige Element wird das Host-Element der Komponente. Das Prinziphaben wir einige Seiten zuvor schon beleuchtet.

Komponenten imAppModuleregistrieren

Damit dieser Mechanismus funktioniert, muss Angular die Kom-ponente allerdings erst kennenlernen. Die reine Existenz einer Kompo-nentendatei reicht nicht aus. Stattdessen müssen wir alle Komponentender Anwendung im zentralen AppModule registrieren.

Dazu dient die Eigenschaft declarations im Decorator @NgModule().Hier werden alle Komponenten� notiert, die zur Anwendung gehören.Damit wir die Typen dort verwenden können, müssen wir alle Kompo-nenten importieren.

� . . . und Pipes und Direktiven, aber dazu kommen wir später!


198 10 HTTP & reaktive Programmierung: Iteration III

Demo und Quelltext:https://ng-buch.de/bm3-it3-http

10.2 Reaktive Programmierungmit RxJS»RxJS is one of the best ways to utilize reactive programming practices

within your codebase. By starting to think reactively and treatingeverything as sets of values, you’ll start to find new possibilities of

how to interact with your data within your application.«

Tracy Lee(Google Developer Expert und Mitglied im RxJS Core Team)

Reaktive Programmierung ist ein Programmierparadigma, das in denletzten Jahren verstärkt Einzug in die Welt der Frontend-Entwicklunggehalten hat. Die mächtige Bibliothek Reactive Extensions für Java-Script (RxJS) greift diese Ideen auf und implementiert sie. Der wich-tigste Datentyp von RxJS ist das Observable – ein Objekt, das einenDatenstrom liefert. Tatsächlich dreht sich die Idee der reaktiven Pro-grammierung im Wesentlichen darum, Datenströme zu verarbeiten undauf Veränderungen zu reagieren. Wir haben in diesem Buch bereits mitObservables gearbeitet, ohne näher darauf einzugehen. Da Angular anvielen Stellen auf RxJS setzt, wollen wir einen genaueren Blick auf dasFramework und die ihm zugrunde liegenden Prinzipien werfen.

10.2.1 Alles ist ein Datenstrom

Bevor wir damit anfangen, uns mit den technischen Details von RxJSauseinanderzusetzen, wollen wir uns mit der Grundidee der reaktivenProgrammierung befassen: Datenströme. Wenn wir diesen Begriff ganzuntechnisch betrachten, so können wir das Modell leicht auf die alltäg-liche Welt übertragen. Unsere gesamte Interaktion und Kommunikati-on mit der Umwelt basiert auf Informationsströmen.

DerWecker klingelt. Das beginnt bereits morgens vor dem Aufstehen: Der Wecker klin-gelt (Ereignis), Sie reagieren darauf und drücken die Schlummertaste.Nach 10 Minuten klingelt der Wecker wieder, und Sie stehen auf.�

�Wir gehen natürlich davon aus, dass Sie die Schlummerfunktion mehr alseinmal benutzen, aber für das Beispiel soll es so genügen.


10.2 Reaktive Programmierungmit RxJS 199

Sie haben einen Strom von wiederkehrenden Ereignissen abonniert undverändern den Datenstrom mithilfe von Aktionen. Schon dieser Ablaufist von vielen Variablen und Entscheidungen geprägt: Wie viel Zeit ha-be ich noch? Was muss ich noch erledigen? Fühle ich mich wach odermöchte ich weiterschlafen?

Warten auf den BusSie gehen aus dem Haus und warten auf den Bus. Damit Sie in denrichtigen Bus steigen, ignorieren Sie zunächst alle anderen Verkehrsmit-tel, bis der Bus auf der Straße erscheint – Sie haben also einen Stromvon Verkehrsmitteln beobachtet, das passende herausgesucht und da-mit interagiert. Dafür haben Sie eine konkrete Regel angewendet: Ichbenötige den Bus der Linie 70.

Telefonieren undChatten

Im Bus klingelt das Telefon, Sie heben ab und sprechen mit demAnrufer. Beide Teilnehmer erzeugen einen Informationsstrom und rea-gieren auf die ankommenden Informationen. Aus einigen Teilen desGesprächs leiten Sie konkrete Aktionen ab (z. B. antworten oder et-was erledigen), andere Teile sind unwichtig. Während Sie telefonieren,vibriert das Handy, denn Sie haben eine Chatnachricht erhalten. Undnoch eine. Und noch eine. Die Nachrichten treffen nacheinander ein –Sie ignorieren die Ereignisse allerdings, denn das Chatprogramm puf-fert die Nachrichten, sodass Sie den Text auch später lesen können. Spä-ter sehen Sie, dass die Nachrichten von verschiedenen Personen stam-men: Einzelne Menschen haben Nachrichten erzeugt, die bei Ihnen ineinem großen Datenstrom eingetroffen sind.

Frühstück kaufenNach dem Aussteigen holen Sie sich beim Bäcker etwas zu essen: Siegehen in den Laden, beobachten den Datenstrom von Angeboten in derTheke, wählen ein Angebot aus und starten den Kaufvorgang. Schließ-lich verlassen Sie das Geschäft mit einem Brötchen. Was ist passiert?Ein Strom von eingehenden Kunden, die Geld besitzen, wurde umge-wandelt in einen Strom von ausgehenden Kunden, die nun Brötchenhaben. Der Angestellte beim Bäcker hat den Kundenstrom abonniertund die einzelnen Elemente mit Backwaren versorgt.

Wir könnten dieses Beispiel beliebig weiterführen, aber der Kernder Idee ist bereits erkennbar: Das komplexe System in unserer Weltbasiert darauf, dass Ereignisse auftreten, auf die wir reagieren können.Durch unsere Erfahrung wissen wir, wie mit bestimmten Ereignissenumzugehen ist, z. B. wissen wir, wie man ein Telefon bedient, ein Ge-spräch führt oder ein Brötchen kauft. Manche Ereignisse treten nur füruns und als Folge anderer Aktionen auf: Das Brötchen wird erst ein-gepackt, wenn wir es kaufen. Lösen wir die Aktion nicht aus, so fin-det kein Ereignis statt. Andere Ereignisse hingegen passieren auch ohnedass wir darauf einen Einfluss haben, z. B. der Straßenverkehr oder dasWetter. Unsere Aufgabe ist es, diese Ereignisse zu beobachten und pas-



send darauf zu reagieren. Sind wir nicht an den Ereignissen interessiert,passieren sie trotzdem.

Die Aufgabe von Software ist es, Menschen in ihren Aufgaben undAbläufen zu unterstützen. Daher finden wir viele Ansätze aus der ech-ten Welt eben auch in der Softwareentwicklung wieder.Ereignisse in der

SoftwareUnsere Anwen-

dungen sind von einer Vielzahl von Ereignissen und Einflüssen geprägt:Der Nutzer interagiert mit der Anwendung, klickt auf Buttons und fülltFormulare aus. API-Requests kommen vom Server zurück und Timerlaufen ab. Wir möchten auf all diese Ereignisse passend reagieren undweitere Aktionen anstoßen. Wenn Sie einmal an eine interaktive An-wendung wie Tabellenkalkulation denken, wird dieses Prinzip deutlich:Sie füllen ein Feld aus, das Teil einer komplexen Formel ist, und alle zu-gehörigen Felder werden automatisch aktualisiert.

Datenströme verarbeiten, zusammenführen, transformieren und fil-tern – das ist die Grundidee der reaktiven Programmierung.Alles ist ein Datenstrom. Das Modellgeht davon aus, dass sich alles als ein Datenstrom auffassen lässt: nichtnur Ereignisse, sondern auch Variablen, statische Werte, Nutzereinga-ben und vieles mehr. Zusammen mit den Ideen aus der funktionalenProgrammierung ergibt sich aus dieser Denkweise eine Vielzahl vonMöglichkeiten, um Programmabläufe und und Veränderungen an Da-ten deklarativ zu modellieren.

10.2.2 Observables sind Funktionen

Um die Idee der allgegenwärtigen Datenströme in unserer Software auf-zugreifen, benötigen wir zuerst ein Konstrukt, mit dem sich ein Daten-strom abbilden lässt. Wir wollen ein Objekt entwerfen, das über dieZeit nacheinander mehrere Werte ausgibt. Jeder, der an den Werten in-teressiert ist, kann den Datenstrom abonnieren. Dabei soll es drei Artenvon Ereignissen geben:

n Ein neues Element trifft ein (next).n Ein Fehler tritt auf (error).n Der Datenstrom ist planmäßig zu Ende (complete).

Wir erstellen dazu eine einfache JavaScript-Funktion mit dem Namenobservable(), die wir im weiteren Verlauf als Producer-Funktion be-zeichnen wollen. Als Argument erhält diese Funktion ein Objekt, dasdrei Eigenschaften mit Callback-Funktionen besitzt: next, error undcomplete. Dieses Objekt nennen wir Observer. Im Körper der Producer-Funktion führen wir nun beliebige Aktionen aus, so wie es eben für ei-ne Funktion üblich ist. Immer wenn etwas passiert, rufen wir eins derdrei Callbacks aus dem Observer auf: Wenn ein neuer Wert ausgege-ben werden soll, wird next() gerufen, sind alle Aktionen abgeschlossen,



rufen wir complete() auf, und tritt ein Fehler in der Verarbeitung auf,so nutzen wir error(). Diese Aufrufe können synchron oder zeitversetzterfolgen. Welche Aktionen wir hier ausführen, ist ganz unserer konkre-ten Implementierung überlassen.

Listing 10–17Producer-Funktion

function observable(observer) {setTimeout(() => {

observer.next(1);}, 1000);

observer.next(2);

setTimeout(() => {observer.next(3)observer.complete();

}, 2000);}

Damit in unserem Programm auch tatsächlich etwas passiert, rufen wirdie Producer-Funktion observable() auf und übergeben als Argumenteinen konkreten Observer, also ein Objekt mit den drei Callbacks next,error und complete.

Listing 10–18Funktionmit Observeraufrufen

const myObserver = {next: value => console.log('NEXT:', value),error: err => console.log('ERROR:', err),complete: () => console.log('COMPLETE')

};

observable(myObserver);

Das Programm erzeugt die folgende zeitversetzte Ausgabe, die sich auchauf einem Zeitstrahl darstellen lässt.

Listing 10–19Ausgabe desProgramms

NEXT: 2NEXT: 1NEXT: 3COMPLETE

Abb. 10–1Gra�sche Darstellungder Ausgabe



Reduzieren wir diese Idee auf das Wesentliche, so lässt sie sich wiefolgt zusammenfassen: Wir haben eine Funktion entwickelt, die Befehleausführt und ein Objekt entgegennimmt, das drei Callback-Funktionenenthält. Wenn im Programmablauf etwas passiert (synchron oder asyn-chron), wird eines dieser drei Callbacks aufgerufen. Die Producer-Funktion emittiert also nacheinander verschiedene Werte an den Ob-server.

Immer wenn die Funktion observable() aufgerufen wird, startet dasProgramm. Daraus folgt, dass nichts passiert, wenn niemand die Funk-tion aufruft. Starten wir die Funktion hingegen mehrfach, so werden dieRoutinen auch mehrfach ausgeführt. Was zunächst ganz offensichtlichklingt, ist eine wichtige Eigenschaft, auf die wir später noch zurück-kommen werden.

An dieser Stelle möchten wir Sie aber zunächst beglückwünschen!Wir haben gemeinsam unser erstes Observable entwickelt und habendabei gesehen: Ein Observable ist nichts anderes als eine Funktion.

10.2.3 Das Observable aus RxJS

ReactiveX, auch Reactive Extensions oder kurz Rx genannt, ist ein re-aktives Programmiermodell, das ursprünglich von Microsoft für das.NET-Framework entwickelt wurde. Die Implementierung ist sehr gutdurchdacht und verständlich dokumentiert. Die Idee erfreut sich großerBeliebtheit, und so sind sehr viele Portierungen für die verschiedens-ten Programmiersprachen entstanden. Der wichtigste Datentyp von Rx,das Observable, ist sogar mittlerweile ein Vorschlag für ECMAScript�geworden. RxJS ist der Name der JavaScript-Implementierung vonReactiveX.

Angular setzt intern stark auf die Möglichkeiten von RxJS, einigehaben wir sogar schon kennengelernt: Der EventEmitter ist ein Observ-able, der HttpClient gibt Observables zurück und auch Formulare undder Router propagieren Änderungen mit Observables.

Die Observable-Implementierung von RxJS folgt genau der Idee,die wir im letzten Abschnitt an unserem Funktionsbeispiel entwickelthaben: Wir rufen eine Funktion auf, übergeben einen Observer, und dieFunktion ruft die Callbacks aus dem Observer auf, sobald etwas pas-siert. RxJS bringt für sein Observable allerdings zusätzlich einen wohl-definierten Rahmen mit und befolgt einige Regeln. Dazu gehören unteranderem folgende Punkte:

�https://ng-buch.de/a/45 – GitHub: TC39 Observables for ECMAScript



n Der Datenstrom ist zu Ende, sobald error() oder complete() gerufenwurden. Es ist also nicht möglich, danach noch einmal reguläreWerte mit next() auszugeben.

n Das Observable besitzt die Methode subscribe(), mit der wir denDatenstrom abonnieren können. Abonnierte Daten können außer-dem wieder abbestellt werden.

n Ein Observable besitzt die Methode pipe(). Damit können wir so-genannte Operatoren an das Observable anhängen, um den Daten-strom zu verändern.

n Der fest definierte Datentyp Observable sorgt dafür, dass Observ-ables aus verschiedenen Quellen miteinander kompatibel sind.

Wir werden den Aufbau und die Funktionsweise eines solchen Observ-ables in den folgenden Abschnitten genauer betrachten. Behalten Sie da-bei das Funktionsbeispiel im Hinterkopf, denn Sie werden einige Dingewiedererkennen.

10.2.4 Observables abonnieren

Um die Daten aus einem Observable zu erhalten, müssen wir den Da-tenstrom abonnieren. Da wir nun ein »echtes« Observable nutzen,funktioniert dieser Aufruf ein wenig anders als in unserem einfachenFunktionsbeispiel – hat aber starke Ähnlichkeiten. Jedes Observablebesitzt eine Methode mit dem Namen subscribe(). Rufen wir sie auf,wird die Routine im Observable gestartet und das Objekt kann Werteausgeben.

Als Argument übergeben wir ein Objekt mit drei Callback-Funktio-nen next, error und complete. Erkennen Sie die Parallelen? Diesen Ob-server haben wir im vorherigen Beispiel bereits verwendet. Das Ob-servable ruft die drei Callbacks aus dem Observer auf und liefert aufdiesem Weg Daten an den Aufrufer.

Listing 10–20Observable abonnierenmit Observer

const myObserver = {next: value => console.log('NEXT:', value),error: err => console.error('ERROR:', err),complete: () => console.log('COMPLETE')

};

myObservable$.subscribe(myObserver);

Neben dieser etwas aufwendigen Schreibweise gibt es noch einen an-deren Weg. Anstatt ein Objekt mit drei Funktionen zu notieren, kön-nen wir die drei Callbacks auch einzeln nacheinander als Argumentevon subscribe() angeben. Das hat den Vorteil, dass wir nicht immer



alle drei Funktionen übergeben müssen: Sind wir nur an den regulä-ren Werten aus dem Observable interessiert, so reicht es aus, wenn wirdas erste Callback notieren. Diese Schreibweise ist auch der normaleund empfohlene Weg, den wir bereits im Kapitel zu HTTP verwendethaben.

Listing 10–21Observable abonnieren

mit Callbacks

// mit drei CallbacksmyObservable$.subscribe(

value => console.log('NEXT:', value),err => console.error('ERROR:', err),() => console.log('COMPLETE')

);

// mit einem CallbackmyObservable$

.subscribe(value => console.log('NEXT:', value));

Subscriptions beenden

Sobald wir Daten von einem Observable abonnieren, gehen wir einenVertrag ein: Das Observable liefert Daten, wir nehmen die Daten ent-gegen. Wie bei einem ordentlichen Vertrag üblich, lässt sich auch dieservon beiden Seiten kündigen. Beendet das Observable den Datenstrom(also durch error oder complete), so wird auch die Subscription auto-matisch beendet.

Aber auch der Programmablauf außerhalb des Observables kanndas Abonnement kündigen. Die Methode subscribe() gibt dazu ein Ob-jekt vom Typ Subscription zurück. Dieses Objekt wiederum besitzt eineMethode unsubscribe(), mit der wir das Abonnement beenden können.

Listing 10–22Subscription beenden

mit unsubscribe()

const subscription = myObservable$.subscribe(myObserver);

setTimeout(() => {subscription.unsubscribe();

}, 3000);

Memory Leaksvermeiden

Das Observable liefert danach keine Daten mehr, und der Speicher wirdwieder freigegeben. Das ist besonders wichtig, um Memory Leaks zuvermeiden, bei denen Speicher länger reserviert wird als nötig. Mit die-sem Thema werden wir uns demnächst noch beschäftigen.


257

11 Powertipp: Augury

Bei der Entwicklung mit Angular ist es oft hilfreich, Informationen überden aktuellen Status unserer Anwendung zu erhalten. Augury� ist einnützliches Werkzeug, mit dem wir die Anwendung zur Laufzeit unter-suchen und debuggen können.

Die wichtigsten Funktionen von Augury sind:

n Beziehungen zwischen Komponenten darstellen (Komponentenhier-archie)

n detaillierte Informationen zu Komponenten anzeigenn Abhängigkeiten darstellen (Injector Graph)n Informationen zur Change Detection anzeigenn den gesamten Routenbaum darstellenn Zustände und Werte anzeigen und modifizierenn Events auslösen

Installation

Das Tool ist als Erweiterung für Google Chrome verfügbar und kannüber den Extension Manager des Browsers installiert werden.�

Abb. 11–1Erweiterung Augury inGoogle Chrome

Nach der Installation taucht das Tool als zusätzlicher Reiter in denChrome Developer Tools auf.

�https://ng-buch.de/a/15 – Angular Augury�https://ng-buch.de/a/58 – Chrome Web Store: Augury


258 11 Powertipp: Augury

Der Component Tree

Beim ersten Aufruf von Augury gelangt man direkt zur Ansicht Com-ponent Tree (Abbildung 11–2). Diese Ansicht stellt eine Übersicht derKomponenten und deren Verschachtelung dar. Wenn wir mit demMauszeiger über einen Eintrag im Component Tree fahren, wird dieentsprechende Komponente im Browser hervorgehoben. Wählen wireine Komponente aus, so erscheinen im rechten Bereich weitere Detailsdieser Komponente. Es werden gesetzte Propertys und ggf. abhängigeProvider dargestellt.

Abb. 11–2Eigenschaften einer

KomponentemitAugury untersuchen

Auf der rechten Seite ist außerdem der Reiter Injector Graph zu se-hen. Hier werden die Abhängigkeiten einer Komponente grafisch dar-gestellt. Die Propertys lassen sich direkt über Augury editieren. Ändernwir einen Wert, so sehen wir sofort die Auswirkungen der Änderung.Ebenso können wir Events über eine entsprechende Eingabe und Betä-tigung des Buttons Emit auslösen.

Führen wir in der Anwendung eine Aktion aus (z. B. durch Klickeneines Buttons), hebt Augury alle betreffenden Komponenten farblichhervor, in denen der Change-Detection-Prozess angestoßen wird.

Im unteren Teil des Tools befindet sich ein Suchfeld, mit dem wirden gesamten Komponentenbaum nach einer bestimmten Komponenteoder Attributen durchsuchen können.

Der Router Tree

Das zweite große Feature von Augury ist der Reiter Router Tree. Hierwerden alle verfügbaren Routen und deren zugehörige Komponentengrafisch dargestellt. Es ist direkt ersichtlich, an welcher Stelle innerhalbdes Router Trees die Anwendung sich gerade befindet und welche Rou-ten von dort aus erreichbar sind.


11 Powertipp: Augury 259

Abb. 11–3Der Injector Graph vonAugury

Wählen wir einen Knoten im Baum aus, werden der Pfad, die zugehöri-ge Komponente und ggf. übergebene Daten angezeigt. Auch der RouterTree lässt sich nach Inhalten durchsuchen.

Zusammenfassung

Wir können mithilfe von Augury einen Überblick über unsere Kompo-nenten, Services und Routen erlangen. Wir sehen, welche Abhängigkei-ten diese zueinander haben, und können das Zusammenspiel bei Sta-tusänderungen verfolgen. Augury kann beim Debugging einer Angular-Anwendung helfen. Wir können direkt im Tool Werte manipulieren,Events auslösen und sehen, wie unsere Anwendung darauf reagiert.


291

Teil VWeiterführende Themen

Woiwode_Trennseite V.fm Seite 291 Mittwoch, 12. April 2017 12:14 12


553

20 State Management mit Redux

»NgRx provides robust state management for small and large projects.It enforces proper separation of concerns. Using it from the start

reduces the risk of spaghetti when the project evolves.«

Minko Gechev(Mitglied des Angular-Teams)

Wir haben in diesem Buch gelernt, wie wir eine Angular-Anwendungentwickeln, und haben dabei alle wichtigen Konzepte betrachtet. Unse-re Anwendung haben wir komponentenzentriert und serviceorientiertaufgebaut: Die Komponenten unserer Anwendung kommunizieren aufklar definierten Wegen über Property Bindings und Event Bindings. UmDaten zu erhalten und zu senden, nutzen die Komponenten verschiede-ne Services, in denen die HTTP-Kommunikation gekapselt ist oder überdie wir Daten austauschen können.

Diese Herangehensweise funktioniert im Prinzip sehr gut, und wirhaben so eine vollständige Anwendung entwickeln können. Unsere Bei-spielanwendung ist allerdings auch recht klein und übersichtlich – inder Praxis werden die Anwendungen hingegen wesentlich größer: VieleKomponenten greifen dann gleichzeitig auf geteilte Daten zu und wol-len dieselben Services nutzen. Auch die Performance spielt eine immergrößere Rolle, je komplexer die Anwendung wird. Wir erreichen mitder bisher vorgestellten Herangehensweise schnell einen Punkt, an demwir den Überblick über die Kommunikationswege verlieren. Es kommtimmer häufiger zu unerklärlichen Konstellationen, da man nicht mehrnachvollziehen kann, welche Komponente andere Komponenten bzw.Services aufruft und in welcher Reihenfolge dies geschieht. Gleichzei-tig führen die vielen Kommunikationswege zu entsprechend vielen Än-derungen an den Daten, die von der Change Detection� erkannt undverarbeitet werden müssen. Kurzum: Die Anwendung wird zunehmendschwerfälliger.

�Die Ideen und Hintergründe der Change Detection besprechen wir aus-führlich im Kapitel »Wissenswertes« ab Seite 661.


554 20 State Management mit Redux

Mit wachsender Größe der Anwendung ergeben sich immer wiederfolgende Fragen:

n Wie können wir Daten cachen und wiederverwenden, die überHTTP abgerufen wurden?

n Wie machen wir Daten für mehrere Komponenten gleichzeitig ver-fügbar?

n Wie reagieren wir an verschiedenen Stellen auf Ereignisse, die in derAnwendung auftreten?

n Wie verwalten wir die Daten, die über die gesamte Anwendung ver-teilt sind?

Zustände zentralisieren Eine häufige Lösung für all diese Herausforderungen ist die Zentralisie-rung. Liegen die Daten an einem zentralen Ort in der Anwendung vor,so können sie von überall aus genutzt und verändert werden. DiesenSchritt geht man häufig ganz selbstverständlich, indem man etwa aneiner geeigneten Stelle (z. B. im BookStoreService) einen Cache einbaut.Doch die Idee der Zentralisierung kann man noch viel weiter gehen:Bislang waren Komponenten die »Hüter« der Daten. Jede Komponen-te hatte ihren eigenen Zustand und bildete eine abgeschottete Einheitzu den anderen Komponenten. Diese Idee wollen wir nun auf den Kopfstellen. Die Komponenten sollen dazu ihre bisherige Kontrolle über dieDaten und die Koordination der Prozesse an eine zentrale Stelle abge-ben. Die Aufgabe der Komponenten ist es dann nur noch, Daten zulesen und Events an die zentrale Stelle zu senden. Diese Art der Zentra-lisierung stellt einen entscheidenden Unterschied zum bisherigen Vor-gehen dar, wo alle Zustände über den gesamten Komponentenbaumhinweg verteilt waren.

Wir wollen in diesem Kapitel besprechen, wie eine solche zentraleZustandsverwaltung (engl. State Management) realisiert werden kann.Dabei lernen wir das Architekturmuster Redux kennen und nutzen diepopuläre Bibliothek Reactive Extensions for Angular (NgRx), um denAnwendungszustand zu verwalten und unsere Prozesse zu koordinie-ren.

20.1 Ein Modell für zentrales StateManagement

Um uns der Idee des zentralen State Managements von Redux zu nä-hern, wollen wir zunächst ein eigenes Modell ohne den Einsatz einesFrameworks entwickeln. Wir beginnen mit einem einfachen Beispiel,verfeinern die Implementierung schrittweise und nähern uns so der fi-nalen Lösung an.


20.1 Ein Modell für zentrales State Management 555

Objekt in einem Service

Um alle Daten und Zustände zu zentralisieren, legen wir in einem zen-tralen Service ein Zustandsobjekt ab. Wir definieren die Struktur diesesObjekts mit einem Interface, um von einer starken Typisierung zu pro-fitieren. Als möglichst einfaches Beispiel dient uns eine Zahl, die manmithilfe einer Methode hochzählen kann. Unser State kann natürlichnoch weitere Eigenschaften besitzen; wir haben dies mit dem PropertyanotherProperty angedeutet.

Listing 20–1Servicemit zentralemZustand

export interface MyState {counter: number;anotherProperty: string;

}

@Injectable({ providedIn: 'root' })export class StateService {

state: MyState = {counter: 0,anotherProperty: 'foobar'

}

incrementCounter() {this.state.counter++;

}}

Unser Service hält ein Objekt mit einem initialen Zustand, das überdie Methode incrementCounter() manipulierbar ist. Alle Komponentenkönnen diesen Service anfordern und die Daten aus dem Objekt nut-zen und verändern. Die Change Detection von Angular hilft uns dabei,automatisch bei Änderungen die Views der Komponenten zu aktuali-sieren.

Listing 20–2Zentralen Zustand inder Komponenteverwenden

@Component({ /* ... */ })export class MyComponent {

constructor(public service: StateService) {}}

Den injizierten StateService können wir dann im Template nutzen, umdie Daten anzuzeigen und die Methode incrementCounter() auszulösen:

Listing 20–3Den Service imTemplate nutzen

<div class="counter">{{ service.state.counter }}

</div>



<button (click)="service.incrementCounter()">Increment

</button>

Wir haben in einem ersten Schritt unseren Zustand zentralisiert. DerMehrwert zu einer isolierten Lösung besteht darin, dass alle Kompo-nenten denselben Datensatz verwenden und anzeigen. Der Ort der Da-tenhaltung ist klar definiert und es gibt keine Datensilos bei den einzel-nen Komponenten.

Subject in einem Service

Wir haben den Anwendungszustand an einer zentralen Stelle unterge-bracht, allerdings hat die Lösung einen Nachteil. Mit der aktuellen Ar-chitektur können wir nur über Umwege programmatisch auf Änderun-gen an den Daten reagieren.� Eine Änderung am State wird zwar je-derzeit korrekt angezeigt, aber dies basiert allein auf den Mechanismender standardmäßigen Strategie für die Change Detection.� Wollen wirhingegen zusätzlich eine Routine anstoßen, sobald sich Daten ändern,haben wir aktuell keine direkte Möglichkeit dazu.

Subject: Observer undObservable

Um diesen Punkt zu verbessern, ergänzen wir den Service mit ei-nem Subject.� Das Subject ist ein Baustein, mit dem wir ein Event anmehrere Subscriber verteilen können. Ein Subject implementiert hierfürsowohl alle Methoden eines Observers (Daten senden) als auch die ei-nes Observables (Daten empfangen). Wenn der Zustand geändert wird,soll das Subject diese Neuigkeit mit einem Event bekannt machen, so-dass die Komponenten darauf reagieren können.

Für unser Beispiel eignet sich ein BehaviorSubject. Seine wichtigsteEigenschaft besteht darin, dass es den jeweils letzten Zustand speichert.Jeder neue Subscriber erhält die aktuellen Daten, ohne dass ein neuesEvent ausgelöst werden muss. Interessierte Komponenten können denDatenstrom also jederzeit abonnieren und auf die Ereignisse reagieren.Das BehaviorSubject muss mit einem Startwert initialisiert werden, derüber den Konstruktor übergeben wird.

Wir setzen zunächst die Eigenschaft state auf privat, sodass mannun gezwungen ist, das Observable state$ zu verwenden, anstatt di-

�Man könnte z. B. eine weitere Komponente und den Lifecycle-Hook ngOn-Changes() einsetzen.�Zur Funktionsweise und Optimierung der Change Detection in Angularhaben wir im Kapitel »Wissenswertes« ab Seite 661 einen Abschnitt un-tergebracht.

� Im Kapitel zu reaktiver Programmierung mit RxJS haben wir Subjects aus-führlich besprochen, siehe Seite 214.



rekt auf das Objekt zuzugreifen. Wird incrementCounter() aufgerufenund der State aktualisiert, so lösen wir das BehaviorSubject mit demaktuellen State-Objekt aus. So werden alle Subscriber über den neuenZustand informiert.

Listing 20–4Zentralen ZustandmitSubject verwenden


private state: MyState = { /* ... */ }

state$ = new BehaviorSubject<MyState>(this.state);

incrementCounter() {this.state.counter++;this.state$.next(this.state);

}}

Unsere Komponenten können nun die Informationen aus dem Subjectbeziehen. Der Operator map() hilft uns, schon in der Komponentenklas-se die richtigen Daten aus dem State-Objekt zu selektieren.

Listing 20–5Zustand vor derVerwendungtransformieren


counter$ = this.service.state$.pipe(map(state => state.counter)

);

// ...}

Im Template nutzen wir schließlich die AsyncPipe, um das Observablezu abonnieren.

Listing 20–6Ergebnis mit derAsyncPipe anzeigen

<div class="counter">{{ counter$ | async }}

</div>

<button (click)="service.incrementCounter()">Increment

</button>

Dieser Ansatz bietet einen Mehrwert zum vorherigen Beispiel: DieKomponenten teilen sich nicht nur die Daten, sie können auch reaktivÄnderungen entgegennehmen. Zusätzlich sind wir in der Lage, bei Be-darf die Strategie der Change Detection für die Komponente zu ändern



und so in einem komplexeren Szenario gegebenenfalls die Performancezu optimieren.

Unveränderlichkeit

Unser Beispiel hat sich gut entwickelt, hat aber noch ein grundlegendesDesignproblem. Wir halten unsere Daten in einem zentralen Objekt,das mit wachsender Größe der Anwendung ebenfalls größer wird. Al-le Änderungen werden direkt an diesem Objekt durchgeführt, und wirgeben es lediglich als Referenzparameter (Call by reference) an die Sub-scriber weiter. Wir stellen uns nun vor, das Objekt hätte viele weite-re Eigenschaften und eine verschachtelte Datenstruktur. Die Ereignissezum Ändern der Daten können weiterhin aus diversen Gründen ausge-löst werden.Objekte vergleichen Wie können wir nun effizient herausfinden, ob das Objektbzw. ein Teil der verschachtelten Datenstruktur verändert wurde? DieAntwort lautet: Wir können dies nicht ohne zusätzlichen Aufwand rea-lisieren. Um eine Änderung festzustellen, ist es notwendig, das Objektmit einer zuvor erstellten Kopie zu vergleichen. Da wir mit Referenzenarbeiten, müssen wir langwierig jede Eigenschaft der verschachteltenDatenstruktur mit dem Gegenstück aus der Kopie vergleichen.

Das wollen wir ändern, indem wir das Objekt unveränderlich(engl. immutable) machen. Zur Erstellung von unveränderlichen Ob-jekten gibt es mehrere Bibliotheken, darunter das Projekt Immuta-ble.js.� Für ein simples Szenario genügt auch die JavaScript-MethodeObject.freeze(). Damit können wir ein Objekt »einfrieren« und direkteÄnderungen an den Daten verhindern. Dadurch ändert sich ein grund-legender Aspekt: Da Änderungen nicht mehr direkt am bisherigen Ob-jekt möglich sind, werden wir gezwungen, das Objekt auszutauschen.

Kopie erzeugen Wir erzeugen hierfür bei jeder Änderung eine Kopie des vorherigen Ob-jekts mit einer Ausnahme: dem zu ändernden Wert. Eine Änderung fest-zustellen ist nun sehr einfach: Wir müssen lediglich Referenzen verglei-chen. Dies ist problemlos möglich, da wir durch die Unveränderlichkeitsicher sein können, dass keine Änderung durch direkte Manipulationdes Objekts möglich sein kann. Versehentliche Änderungen sind damitebenfalls ausgeschlossen.

Für unseren Anwendungsfall benötigen wir allerdings gar keineechte Unveränderlichkeit! Es reicht im Prinzip schon aus, nur so zutun, als wäre das Objekt unveränderlich, und dies konsequent beimProgrammieren einzuhalten. Wir können hierfür den Spread-Operator�nutzen und damit alle Eigenschaften kopieren.

�https://ng-buch.de/a/80 – Immutable.js�Den Spread-Operator und die Rest-Syntax haben wir im Kapitel zu Type-Script ab Seite 41 erklärt.



Im folgenden Listing 20–7 demonstrieren wir die Verwendung. DieMethode incrementCounter() nutzt den Spread-Operator, um eine Ko-pie des vorherigen Objekts und damit eine neue Referenz zu erzeugen.Im selben Schritt schreiben wir den neuen Wert des Zählers in die Ei-genschaft counter.

Listing 20–7Objekte unveränderlichbehandeln


// ...

incrementCounter() {this.state = {

...this.state,counter: this.state.counter + 1

}

this.state$.next(this.state);}

}

Wir haben durch die »Pseudo-Immutability« den Weg geebnet, um dieStrategie für die Change Detection zu optimieren: Wenn ein Objektbei einer Änderung stets eine neue Referenz erhält, so können wir inden Kindkomponenten die Strategie OnPush� einsetzen. Dies kann diePerformance der Anwendung entscheidend verbessern.

Nachrichten

EntkopplungWir wollen einen Schritt weiter gehen und das System noch mehr ent-koppeln. So wie der Service aktuell implementiert ist, muss für jedeAktion auch eine Methode existieren, die von der Komponente aufge-rufen wird, z. B. incrementCounter(). Idealerweise kennen die Kompo-nenten allerdings gar keine Details über die konkrete Implementierungder Zustandsverwaltung. Koppeln wir die Bausteine zu eng aneinander,so wird es mit wachsender Größe der Anwendung immer aufwendiger,grundlegende Änderungen oder Umstrukturierungen durchzuführen.

Anstatt also für jede Aktion eine Methode anzulegen, wollen wireine Reihe von Nachrichten vereinbaren, mit denen die Anwendung Er-eignisse erfassen und Aufforderungen formulieren kann. Welche Rou-tinen als Reaktion auf eine Nachricht anzustoßen sind, das entscheidetdie Zustandsverwaltung. Die Komponenten teilen lediglich mit, was inder Anwendung passiert.

�Auf die Change Detection und die Strategie OnPush gehen wir ab Seite 661genauer ein.



Der relevante Unterschied zu einem Methodenaufruf ist die Ent-kopplung: Dem System steht es frei, auf eine Nachricht zu reagierenoder sie zu ignorieren. Existiert für eine bestimmte Nachricht noch kei-ne Logik, so tritt kein Fehler auf, sondern die Nachricht wird schlicht-weg nicht behandelt. Ebenso können mehrere Teile der Anwendunggleichzeitig auf Nachrichten reagieren oder auch zeitversetzt die Nach-richt verarbeiten. Zeichnet man die Nachrichten auf, so bleibt durch dieHistorie der Nachrichten stets ersichtlich, was in welcher Reihenfolgepassiert ist.

Für das Zählerbeispiel können wir beispielsweise die NachrichtenINCREMENT, DECREMENT und RESET vereinbaren, die von den Komponentenzum Service geschickt werden können.

Listing 20–8Nachricht in denService senden


constructor(private service: StateService) {}

increment() {this.service.dispatch('INCREMENT');

}}

Trennung von Lesenund Schreiben

Wenn wir diese Architektur genauer betrachten, fällt auf, dass wir Le-sen und Schreiben für unser Zustandsobjekt vollständig voneinandergetrennt haben. Die Abonnenten wissen nicht, woher die Zustandsän-derungen stammen. Die Auslöser der Nachrichten wissen nicht, ob undwie der Zustand geändert wird und wer über die Änderungen infor-miert wird. Die Verantwortung wurde komplett an die zentrale Zu-standsverwaltung übertragen, und wir haben das System stark entkop-pelt.

Berechnung des Zustands auslagern

Mit der Idee von Nachrichten zum Datenaustausch und (Pseudo-)Un-veränderlichkeit im Hinterkopf wollen wir die Verwaltung des Zu-stands erneut überdenken. Bisher haben wir das State-Objekt im Servicegepflegt und bei Änderungen über das Subject ausgegeben. Der Servicehat dabei zwei Verantwortlichkeiten: den zentralen State zu halten undalle Änderungen zu berechnen.

Vermeidung vonGottobjekten

Für unser kurzes Beispiel mit einem Counter ist dies kein Pro-blem, denn wir haben nur wenige Zeilen Code. Wenn allerdings un-sere Anwendung und damit die Zustandsverwaltung komplexer wird,so wächst auch der zentrale Service mit jedem Feature immer weiter an.



Bald entsteht ein »Gottobjekt« (engl. God object), und das müssen wirverhindern.

Die Lösung des Problems besteht darin, die Berechnung des Zu-stands in eine weitere unabhängige Funktion auszulagern. Wenn wirdie Funktion richtig planen, so können wir die Berechnung bei zuneh-mender Komplexität auch in viele unabhängige Funktionen aufteilen.

ZustandsloseProgrammierung

Weiterhin sollten die ausgelagerten Funktionen keinen eigenen Zustandbesitzen (engl. stateless), sodass sie bei gleichen Eingangswerten stetsdie gleichen Ausgangswerte erzeugen. Dadurch werden die Funktioneneinfacher testbar.

Über die gesamte Laufzeit der Anwendung betrachtet basiert unserService auf einem Strom von Nachrichten, die jeweils Zustandsände-rungen auslösen können. Wir besitzen die Grundlage für ein reaktivesSystem, nun müssen wir uns diese Eigenschaft nur noch mithilfe un-serer ausgelagerten Funktionen zunutze machen. Dazu entwickeln wirzunächst die Funktion, die für jede eintreffende Nachricht entscheidet,ob und wie der Zustand verändert werden soll.

Den Datenfluss können wir dabei ganz einfach halten: Die Funk-tion erhält als Argumente den aktuell herrschenden Zustand und dieeintreffende Nachricht.

Listing 20–9Zustand berechnenanhand einer Nachricht

function calculateState(state: MyState, message: string): MyState {switch(message) {

case 'INCREMENT': {return {

...state,counter: state.counter + 1

}};

case 'DECREMENT': {return {

...state,counter: state.counter - 1

};}

case 'RESET': {return { ...state, counter: 0 };

}

default: return state;}

}



Der Zustand wird also durch jede eintreffende Nachricht berechnet.Wenn Änderungen durchgeführt werden sollen, so gibt die Funktionein neues Objekt zurück, denn wir wollen den Zustand ja unveränder-lich behandeln. Trifft eine unbekannte Nachricht ein, so ist keine Ände-rung notwendig. Wir dürfen in diesem Fall das vorherige State-Objektzurückgeben. Unser zentraler Service kann also wie folgt angepasst wer-den:

Listing 20–10Berechnung des States

auslagern


// ...

dispatch(message: string) {this.state = calculateState(this.state, message);this.state$.next(this.state);

}}

In diesem Schritt wurde unser System in zwei Teile aufgeteilt. Der Ser-vice hält weiterhin den State, die Berechnung wird von einer ausgela-gerten Funktion durchgeführt. Durch diese Trennung bleibt der Serviceschlank und übersichtlich.

Deterministische Zustandsänderungen

In JavaScript existiert die Methode Array.reduce(). Sie hat die Aufgabe,ein Array auf einen einzigen Wert zu reduzieren, indem für jeden Wertein Callback ausgeführt wird:

Listing 20–11Additionmit

Array.reduce()

const values = [1, 2, 3, 4];const reducer = (previousValue, currentValue) => previousValue +

,! currentValue;

// Erwartetes Ergebnis: 1 + 2 + 3 + 4 = 10const result = values.reduce(reducer, 0);

Die Signatur unserer zuvor ausgelagerten Funktionen entspricht bereitsden Callbacks, die auch für Array.reduce() verwendet werden. UnserenZustand können wir demnach auch wie folgt berechnen:

Listing 20–12Nachrichten auf denZustand reduzieren

const initialState = {counter: 0,anotherProperty: 'foobar'

};const messages = ['INCREMENT', 'DECREMENT', 'INCREMENT'];



// Erwartetes Ergebnis: { counter: 1 }const result = messages.reduce(calculateState, initialState);

Mit einer solchen Reducer-Funktion und einer Liste von Nachrichtenkönnen wir demnach jeden gewünschten Zustand erzeugen. Wichtig istdabei vor allem, dass die Reducer-Funktion »pure« ist. Sie liefert alsofür die gleichen Eingabewerte stets die gleiche Ausgabe. Dies ist im-mer dann gegeben, wenn die Funktion ausschließlich die übergebenenParameter verwendet und keinen eigenen Zustand verwaltet.

In den vorherigen Beispielen haben wir allerdings kein Array vonNachrichten verwendet, sondern alle eingehenden Nachrichten wurdendirekt an calculateState() weitergegeben. Wir wollen den Service nunetwas umstrukturieren: Dazu setzen wir ein Subject ein, das alle Nach-richten nacheinander in einem Datenstrom messages$ liefert. Wir wol-len erneut die Funktion calculateState() nutzen, um aus der Samm-lung aller Nachrichten den jeweils neuen Zustand zu generieren. DiesesMal greifen wir auf das große Toolset von RxJS zurück und verwen-den den Operator scan(). Das ehemalige BehaviorSubject für den Statewird von shareReplay(1) abgelöst, um das resultierende Observable mitallen Subscribern zu teilen und den jeweils letzten Wert an alle neuenSubscriber zu übermitteln. Um den Prozess einmalig anzustoßen, nut-zen wir außerdem den Operator startWith() und erzeugen ein erstesElement im Strom der Nachrichten.

Listing 20–13Nachrichten auf denZustand reduzierenmitRxJS

const initialState = {counter: 0,anotherProperty: 'foobar'

};

const state$ = messages$.pipe(startWith('INIT'),scan(calculateState, initialState),shareReplay(1)

);

Das Ergebnis ist ein Observable, das für jede eintreffende Nachricht denneuen Zustand ausgibt, der von der Funktion calculateState() berech-net wurde. Ausgehend vom Startzustand werden also alle Nachrichten»aufsummiert« – daraus ergibt sich immer der aktuelle Zustand. Mit-hilfe von scan() müssen wir das zentrale Objekt nicht mehr selbst pfle-gen; dies erledigt nun RxJS für uns.

Erneut haben wir unsere Zustandsverwaltung verbessert. Der Zu-stand ist nun aus den gesendeten Nachrichten abgeleitet. Ist die His-torie aller Nachrichten bekannt, so kann man theoretisch jeden bishe-



rigen Zustand jederzeit wieder reproduzieren, sofern unsere Reducer-Funktionen deterministisch sind.� Diese Eigenschaften sorgen für einsehr einfaches und gleichzeitig robustes System. Da die Funktionen sehrsimpel sind, sind sie auch sehr einfach zu testen.

Zusammenfassung aller Konzepte

Wir wollen die entwickelte Idee kurz zusammenfassen: Wir besitzeneinen zentralen Service, der Nachrichten empfängt. Diese Nachrichtenkönnen von überall aus der Anwendung gesendet werden: aus Kom-ponenten, anderen Services usw. Der Service kennt den Startzustandder Anwendung, der als ein zentrales Objekt abgelegt ist. Jede eintref-fende Nachricht kann Änderungen an diesem Zustand auslösen. DerService kennt dafür die passenden Anleitungen, wie die Nachricht zubehandeln ist und welche Änderungen am Zustand dadurch ausgelöstwerden. Wird ein neuer Zustand erzeugt, wird er an alle Subscriberüber ein Observable übermittelt. Jede interessierte Instanz in der An-wendung kann also die Zustandsänderungen abonnieren. Der Leseflussund der Schreibfluss wurden vollständig entkoppelt: Die Komponentenerhalten die Daten über ein Observable und senden Nachrichten in denService. Der Service ist die Single Source of Truth und hat als einzigerTeil der Anwendung die Hoheit darüber, Nachrichten und Zustands-änderungen zu verarbeiten.

Redux Wir haben schrittweise ein robustes Modell für zentrales State Ma-nagement entwickelt und dabei die Idee des Redux-Patterns kennenge-lernt.

20.2 Das Architekturmodell ReduxRedux ist ein populäres Pattern zur Zustandsverwaltung in Webanwen-dungen. Die Idee von Redux stammt ursprünglich aus der Welt desJavaScript-Frameworks React, das neben Angular eines der populärs-ten Entwicklungswerkzeuge für Single-Page-Anwendungen ist. Reduxist dabei zunächst eine Architekturidee, es gibt aber auch eine konkreteImplementierung in Form einer Bibliothek.

Der zentrale Bestandteil der Architektur ist ein Store, in dem dergesamte Anwendungszustand als eine einzige große verschachtelte Da-tenstruktur hinterlegt ist. Der Store ist die »Single Source of Truth«

�Um jeden gewünschten Zustand wieder reproduzieren zu können, müssteman die Historie aller Nachrichten speichern. Das tun wir in diesem Bei-spiel nicht, und auch in der praktischen Anwendung von Redux wird dasProtokoll der Nachrichten nicht gespeichert.


20.2 Das Architekturmodell Redux 565

für die Anwendung und enthält alle Zustände: vom Server herunterge-ladene Daten, gesetzte Einstellungen, die aktuell geladene Route oderInfos zum angemeldeten Nutzer – alles, was sich zur Laufzeit in derAnwendung verändert und den Zustand beschreibt.

State ist immutableund read-only.

Das State-Objekt im Store hat zwei elementare Eigenschaften: Esist immutable (oder wird so behandelt, als wäre es unveränderbar) undread-only. Wir können die Daten aus dem State nicht verändern, son-dern ausschließlich lesend darauf zugreifen. Möchten wir den State»verändern«, so muss das existierende Objekt durch eine Kopie aus-getauscht werden, die die Änderungen enthält. Solche Änderungen amState werden durch Nachrichten ausgelöst, die aus der Anwendung inden Store gesendet werden. Die Grundidee dieser Architektur habenwir bereits in der Einleitung zu diesem Kapitel gemeinsam entwickelt.

Bausteine von ReduxRedux verwendet vier wesentliche Bausteine: Der Store ist die zen-trale Einheit, die den Zustand der Anwendung verwaltet. Im Store be-findet sich der State als ein großes verschachteltes Objekt, das die Zu-stände der gesamten Anwendung beinhaltet. Der State kann nur ge-lesen werden. Alle fachlichen Ereignisse in der Anwendung werdenmit Nachrichten abgebildet – im Kontext von Redux nennt man dieseNachrichten Actions. Eine Action wird von der Anwendung (z. B. vonden Komponenten) in den Store gesendet (engl. dispatch) und kanneine Zustandsänderung auslösen. Im Store werden die eingehendenActions von Reducern verarbeitet. Diese Funktionen nehmen den ak-tuellen State und die neue Action als Grundlage und errechnen darausden neuen State. Der Datenfluss in der Redux-Architektur ist in Abbil-dung 20–1 grafisch dargestellt. Hier ist klar erkennbar, dass die Datenstets in eine Richtung fließen und dass Lesen und Schreiben klar von-einander getrennt sind.

Abb. 20–1Daten�uss in Redux

SelektorState

Reducer

dispatchAction

Component Store



Bringt man diese Bausteine in den Kontext des einführenden Beispiels,so entspricht der zentrale Service dem Store von Redux. Die gesendetenNachrichten entsprechen den Actions. Die Funktion calculateState(),die wir zur Veranschaulichung verwendet haben, ist genauso aufgebautwie die Reducer von Redux. Der Operator scan() ist tatsächlich auchdie technische Grundlage des Frameworks NgRx, das wir in diesemKapitel für das State Management nutzen werden.

Redux und Angular

Die originale Implementierung von Redux stammt aus der Welt vonReact. Alle enthaltenen Ideen können aber problemlos auch auf die Ar-chitektur einer Angular-Anwendung übertragen werden. Es existierenverschiedene Bibliotheken, die ein zentrales State Management für An-gular ermöglichen. Sie alle folgen der grundsätzlichen Idee von Redux.

n Reactive Extensions for Angular (NgRx)n angular-reduxn NGXSn Akita

NgRx ist das bekannteste Projekt aus dieser Kategorie. Die Bibliothekwurde von Mitgliedern des Angular-Teams aktiv mitentwickelt undgilt als De-facto-Standard für zentrales State Management mit Angular.Angular-Redux nutzt die originale Redux-Implementierung von Reactund stellt Wrapper zur Verfügung, um sich nahtlos in Angular zu in-tegrieren.� Es lohnt sich außerdem, einen Blick auf die Community-Projekte NGXS und Akita zu werfen.

Welche der Bibliotheken Sie für die Zustandsverwaltung einsetzensollten, hängt von den konkreten Anforderungen und auch von persön-lichen Präferenzen ab. Sie sollten alle Projekte vergleichen und IhrenFavoriten nach Kriterien wie Codestruktur und Features auswählen.Dazu möchten wir Ihnen einen Blogartikel empfehlen, in dem NgRx,NGXS, Akita und eine eigene Lösung mit RxJS gegenübergestellt wer-den.��

�Angular-Redux haben wir in der ersten Ausgabe des Buchs vorgestellt. Mitdieser Ausgabe setzen wir jedoch auf NgRx.

��https://ng-buch.de/a/81 – Ordina JWorks Tech Blog: NGRX vs. NGXS vs.Akita vs. RxJS: Fight!


20.3 Reduxmit NgRx 567

20.3 Reduxmit NgRxReactive Extensions for Angular (NgRx) ist eine der populärsten Im-plementierungen für State Management mit Angular. Durch die gezielteAusrichtung auf Angular fügt sich der Code gut in die Strukturen undLebenszyklen einer Angular-Anwendung ein. Die Bibliothek setzt starkauf die Möglichkeiten der reaktiven Programmierung mit RxJS, ist al-so an vielen Stellen von Observables und Datenströmen geprägt. Diegroße Community und eine Reihe von verwandten Projekten machenNgRx zum wohl bekanntesten Werkzeug für Zustandsverwaltung mitAngular.

Wir wollen in diesem Kapitel die Struktur und die Bausteine in derWelt von NgRx genau besprechen. Außerdem wollen wir den Book-Monkey mit NgRx umsetzen, um so alle Bausteine auch praktisch zuüben.

20.3.1 Projekt vorbereiten

Als Grundlage für diese Übung verwenden wir das BeispielprojektBookMonkey in der finalen Version aus Iteration 7. Möchten Sie mit-entwickeln, so können Sie Ihr bestehendes BookMonkey-Projekt ver-wenden oder neu starten und den Code über GitHub herunterladen:

https://ngbuch.de/bm3-it7-i18n

20.3.2 Store einrichten

Im Projektverzeichnis müssen wir zunächst alle Abhängigkeiten instal-lieren, die wir für die Arbeit mit NgRx benötigen. NgRx verfügt über ei-gene Schematics zur Einrichtung in einem bestehenden Projekt der An-gular CLI. Die folgenden Befehle integrieren einen vorbereiteten Store:

$ ng add @ngrx/store$ ng add @ngrx/store-devtools$ ng add @ngrx/effects

Später wollen wir einen zusätzlichen Baustein kennenlernen, der im ori-ginalen Redux nicht vorgesehen ist und der spezifisch für NgRx ist: Ef-fects auf Basis von @ngrx/effects. Deshalb haben wir das nötige Paket



in diesem Schritt gleich mit eingefügt. Die Store DevTools sind hilf-reich zum Debugging der Anwendung – wir werden im Powertipp abSeite 597 genauer darauf eingehen, um den Lesefluss in diesem Kapitelnicht zu unterbrechen.

20.3.3 Schematics nutzen

Um nach der Einrichtung weitere Bausteine von NgRx mithilfe der An-gular CLI anzulegen, können wir das Paket @ngrx/schematics nutzen. Eserweitert die Fähigkeiten der Angular CLI, sodass wir unsere Actions,Reducer und Effects bequem mithilfe von ng generate anlegen können.Auch diese Abhängigkeit wird mittels ng add installiert.

$ ng add @ngrx/schematics --defaultCollection

Default Collectionfestlegen

Mit dem Parameter --defaultCollection werden die Schematics vonNgRx als Standardkollektion für unser Projekt festgelegt. Das bedeu-tet, dass jeder Aufruf von ng generate auf die Skripte in diesem Pa-ket zurückgreift. So können wir bequem einen Befehl wie ng generateaction verwenden, ohne die Zielkollektion gesondert angeben zu müs-sen. Da die NgRx-Schematics von den normalen Schematics für einAngular-Projekt abgeleitet sind, funktionieren die bereits bekanntenBauanleitungen wie ng generate component weiterhin. Die Default Col-lection wird mit einem Eintrag in der Datei angular.json festgelegt, denSie jederzeit wieder löschen oder ändern können, falls Sie eine andereKollektion nutzen möchten.

20.3.4 Grundstruktur des Stores

Die ausgeführten Befehle haben bereits alles Nötige eingerichtet, sodasswir sofort mit der Implementierung beginnen können. Vorher wollenwir jedoch einen Blick auf die neu angelegten Dateien und Imports wer-fen.

Neu hinzugekommen ist die Datei reducers/index.ts. Hier befindetsich ein Interface mit dem Namen State, das das Kernstück unseres An-wendungszustands ist: Dieses Interface definiert, wie der gesamte Statestrukturiert ist, und beschreibt damit den Root-State der Anwendung.Direkt darunter befindet sich in der Variable reducers eine sogenannteActionReducerMap. Hier ist festgelegt, welcher Reducer für welchen Teildes States verantwortlich ist. Alle Reducer der Anwendung werden al-so hier zusammengefasst. Zur Erinnerung: Ein Reducer verwaltet denState, indem er anhand einer Action einen neuen Zustand erzeugt. Wirwerden gleich genauer darauf eingehen.


601

22 NativeScript:mobile Anwendungen entwickeln

»NativeScript brings together the convenience of web developmentwith the capabilities and performance of the native mobile world.«

Stanimira Vlaeva(Google Developer Expert und Mitglied im NativeScript Core Team)

Wir haben Angular bisher stets dafür eingesetzt, Webanwendungen zuentwickeln, die in einem Webbrowser laufen. Der Browser ist allerdingsnur eine von vielen Plattformen, in denen Angular arbeiten kann.

Native Mobile-AppsmitAngular

NativeScript ist eine Toolsammlung, mit der wir native Apps fürAndroid und iOS entwickeln können. Das HTML-Markup wird aller-dings nicht von einem Webbrowser gerendert, sondern in native View-Elemente umgesetzt.

In diesem Kapitel stellen wir die Konzepte von NativeScript vor.Wir werden dabei am Beispiel erfahren, wie sich Angular auch in an-dere Umgebungen als in den Webbrowser nahtlos integriert. Außerdemwollen wir den BookMonkey auf NativeScript portieren.

22.1 Mobile Apps entwickelnDie Anforderungen an moderne Apps sind unter anderem eine anspre-chende Ästhetik, ein plattformspezifisches Nutzererlebnis und natür-lich bestmögliche Performance. Eigenständige Apps für

jede PlattformNormalerweise werden hierzu eigen-

ständige Apps für die beiden großen mobilen Betriebssysteme erstellt.Doch parallele Entwicklungen erzeugen gleichzeitig erhöhte Kosten.

Hybride Appsmit HTMLEine Antwort darauf sind hybride Apps auf Basis von HTML undJavaScript. Ein bekannter Vertreter dieser Kategorie ist das Frame-work Ionic.� Auch Ionic können wir direkt mit Angular nutzen. DieEntwicklung einer hybriden App bringt jedoch ein paar technische Be-schränkungen mit sich. Durch NativeScript ist es möglich, direkt mitJavaScript native Apps zu entwickeln. Native Apps ohne HTMLDiese Apps sind nicht mehr von

�https://ng-buch.de/a/88 – Ionic: Cross-Platform Mobile App Development


602 22 NativeScript: mobile Anwendungen entwickeln

Lösungen unterscheidbar, die klassisch auf Basis von Objective-C bzw.Swift oder Java entwickelt worden sind. NativeScript bietet eine ver-gleichbare Performance wie eine native App und verwendet die norma-len Bedienelemente des jeweiligen mobilen Betriebssystems.

Abb. 22–1Zwei

NativeScript-Screensunter iOS

22.2 Was ist NativeScript?Framework fürmobile Apps

NativeScript� , auch häufig als {N} abgekürzt, ist ein Open-Source-Framework zur Entwicklung von mobilen Apps. Neben dem reinenJavaScript wird auch TypeScript direkt unterstützt, was eine guteGrundlage für die Arbeit mit Angular ist. Aktuell stehen als Zielplatt-form sowohl Android als auch iOS zur Verfügung.

Auf den ersten flüchtigen Blick scheint das Framework eine weite-re Variante des hybriden Ansatzes auf Grundlage von HTML zu sein.Doch dem ist nicht so: NativeScript reiht sich in eine völlig neue Dis-ziplin ein.Native Appsmit

JavaScriptHier geht es darum, JavaScript als vollwertige Programmier-

sprache für Apps zu etablieren. Weitere Frameworks, die native Appsauf Grundlage von JavaScript ermöglichen, sind React Native von Face-book und Appcelerator Titanium. Bei allen drei Lösungen fällt der Um-weg über HTML und den DOM weg. Die Frameworks ermöglichen

�https://ng-buch.de/a/89 – NativeScript


22.3 WarumNativeScript? 603

die direkte Verwendung von nativen UI-Elementen aus der JavaScript-Umgebung heraus. Bei NativeScript für Android ist diese UmgebungGoogles V8 Engine.� Unter iOS kommt JavaScriptCore� zum Einsatz.

22.3 WarumNativeScript?Die technische Grundlage mag zwar spannend sein, doch im Projektall-tag zählen praktische Gründe. Eine Reihe von Gegebenheiten sprichtfür den Einsatz von NativeScript.

Wiederverwendung von bestehenden Skills

Das Erlernen einer neuen Programmiersprache zum Zwecke der App-Entwicklung ist anstrengend und aufwendig. Der Erwerb von Grundla-gen einer Programmiersprache ist dabei noch das kleinere Problem. Dereigentliche Aufwand liegt im Detail. Erlernen neuer

Technologien kostetZeit.

Es ist ein mühsamer und intensiverProzess, bis ein Neueinsteiger tatsächlich alle Aspekte einer Program-mierwelt kennt und sicher beherrschen kann. Während dieser Einarbei-tung stehen die Entwickler natürlich nicht mehr mit dem gewohntenPotenzial und der üblichen Kapazität zur Verfügung.

Durch die Kenntnisse um Angular steht uns bereits ein großer Teildes notwendigen Wissens zur Verfügung. Wir können ganz einfach wei-ter in TypeScript entwickeln und das bekannte Tooling (wie etwa Vi-sual Studio Code) weiter verwenden.

Wiederverwendung von bestehendem Code

Durch den Einsatz der Programmiersprache TypeScript bietet es sichan, bestehende Geschäftslogik oder Bibliotheken aus dem Internet wei-terzuverwenden. Mit dem Repository NPM steht ein großer Fundusvon JavaScript-Bibliotheken zur Auswahl.

NPM-PaketeWenn wir zum Beispiel ein Datum formatieren wollen, dann kön-nen wir dafür die bekannte Bibliothek moment nutzen. Nach einer In-stallation mit npm install moment steht uns die Funktionalität auch inNativeScript wie üblich zur Verfügung:

Listing 22–1Verwendung einesNPM-Pakets

import moment from 'moment';const formattedTime = new moment().format('HH:mm:ss');

Hier ist allerdings etwas Vorsicht geboten, denn NativeScript bietet kei-nen DOM und kennt auch die Schnittstellen von Node.js nicht. Es funk-tionieren also nicht alle NPM-Pakete uneingeschränkt in NativeScript.

�https://ng-buch.de/a/17 – Google V8�https://ng-buch.de/a/90 – JavaScriptCore


604 22 NativeScript: mobile Anwendungen entwickeln

Neben JavaScript-Bibliotheken ist es übrigens auch möglich, beste-hende native Fremdbibliotheken für Android und iOS anzusprechen.

Native Bibliotheken Das bedeutet, dass wir nicht in der JavaScript- bzw. NativeScript-Welt gefangen sind. Wenn es notwendig ist, können wir auch sehrplattformspezifischen Code aufrufen. Von diesem Prinzip macht auchdie Komponentensammlung »NativeScript UI«� Gebrauch. Die beste-henden Komponentensammlungen sind hier vom Hersteller mit einemJavaScript-Wrapper vereinheitlicht worden.

Direkter Zugri� auf native APIs

Manchmal werden wir einfach nicht drum herumkommen und müssentief in das darunterliegende Betriebssystem einsteigen. Für diese Fällebietet NativeScript den direkten Zugriff auf native APIs aus JavaScriptheraus an. Das ist ein großer Vorteil gegenüber React Native und App-celerator, wo dies nicht so einfach möglich ist. Diesen Aspekt werdenwir gleich noch einmal näher beleuchten.

Open Source

Die Gretchenfrage in Sachen Software lässt sich bei NativeScript ohneBauchschmerzen beantworten. Ja, das Framework ist Open Source! Essteht unter derApache License 2.0 Apache License, Version 2.0 (ASLv2), welche die Kom-bination mit proprietärem Code erlaubt. Es ist problemlos möglich,einen kompletten NativeScript-Workflow mittels der offenen Native-Script CLI� aufzubauen. Zusätzlich existieren kommerzielle Angebotefür komplexe Widgets und Enterprise Support.

Nahtlose Integration in Angular und die Angular CLI

NativeScript lässt sich sehr einfach mit dem Workflow der Angular CLIverknüpfen. Dazu bietet das Projekt sogenannte Schematics an – jeneSkripte, die hinter Befehlen wie ng generate stecken. Wir können dasProjekt von Anfang an für mehrere Plattformen ausrichten – Web, An-droid und iOS – und behalten stets eine einheitliche Projektstruktur.Auch wenn wir uns erst später dazu entscheiden, NativeScript in unse-rem Projekt zu nutzen, helfen uns die Schematics, NativeScript in unse-re bestehende Struktur zu integrieren. Somit müssen wir lediglich neueTemplates anlegen, können aber die gesamte Geschäftslogik unsererAnwendung übernehmen.

�https://ng-buch.de/a/91 – NativeScript UI: Professional UI Components�https://ng-buch.de/a/92 – NPM: NativeScript CLI


641

24 Wissenswertes

»The Angular community has fundamentally changed my life, andthat is not an exaggeration. I came to the community with very little

frontend experience and was welcomed with open arms.This community is very special in that we see the value of pouring into

the next generation and new people.«

Zackary Chapple(Google Developer Expert und Gründer von ngAtlanta)

Dieses Buch ist vorwiegend für Einsteiger gedacht, und ganz bewussthaben wir bei der Entwicklung unserer Beispielanwendung auf be-stimmte Themen verzichtet. Auf manche Dinge wollen wir dennoch ein-gehen, auch wenn sie in den bisherigen Kapiteln keinen Platz gefundenhaben. Wir haben deshalb in diesem Abschnitt einige weiterführendeThemen gesammelt, die wir Ihnen kurz vorstellen möchten.

24.1 Container und PresentationalComponents

Mit zunehmender Größe der Anwendung erhalten unsere Kompo-nenten immer mehr Abhängigkeiten. Egal, ob Sie ein zentrales StateManagement verwenden oder mehrere einzelne Services nutzen: VieleKomponenten in der Anwendung fordern Abhängigkeiten über ihrenKonstruktor an. Das erschwert inbesondere das Testing: Müssen wirAbhängigkeiten ausmocken, wird der Test komplizierter und fehler-anfälliger. Auch die Austauschbarkeit ist gefährdet: Möchten wir eineKomponente ersetzen, so müssen wir darauf achten, dass auch alle Ab-hängigkeiten berücksichtigt werden. Nicht zuletzt erleichtert eine klareStruktur allen Entwicklern die Übersicht im Projekt. Eine solche Struk-tur lässt sich mit dem Konzept der Container und Presentational Com-ponents umsetzen.

Separation of ConcernsDie Grundidee besteht darin, die Zuständigkeiten der Komponen-ten klar aufzuteilen: Presentational Components sind ausschließlich fürdie Darstellung verantwortlich und kommunizieren nicht mit Services.


642 24 Wissenswertes

Container Components hingegen erledigen die Kommunikation in dieAnwendung und orchestrieren die Presentational Components – besit-zen aber kein eigenes umfangreiches Markup. Dadurch verringert sichdie Zahl der Komponenten, die Abhängigkeiten besitzen. Gleichzeitigentstehen mehr »dumme« Komponenten, die einfach testbar, wartbarund austauschbar sind.

Smart and DumbComponents

Das Pattern ist auch unter dem Namen Smart and Dumb Com-ponents bekannt. Um jedoch den »unfairen« Begriff dumb zu vermei-den (schließlich ist es ziemlich schlau, eine klare Architektur zu entwi-ckeln), wollen wir die neutralere Bezeichnung Container und Presenta-tional Components verwenden.

Abb. 24–1Container undPresentationalComponents

@Output()

@Input()

@Output()

@Input()

Abhängigkeiten

Container

HTTP

Redux Store

Router

Component

Component

weitere

Services

Component

Component

Component

Presentational Components

Darstellung durcheigenes Markup

Presentational Components sind für die Darstellung verantwortlich. Siebesitzen immer eigenes Markup im Template und definieren damit dieTeile der Anwendung, in denen sich tatsächlich sichtbare Segmenteder UI befinden. Die Kommunikation mit der Anwendung findet aus-schließlich über Bindings statt; eine Presentational Component darf inder Regel keine Services über ihren Konstruktor injizieren. Es gibt je-doch auch Ausnahmen wie z. B. einen injizierten Service zur asynchro-nen Validierung von Formularen.Keine Services, sondern

KommunikationmitBindings

Das bedeutet, dass eine solche Kom-ponente alle Daten über Input-Propertys erhält. Alle ausgehenden Da-ten werden über Events mithilfe von Output-Propertys kommuniziert.Dazu gehören insbesondere Nutzeraktionen, die in der Komponente er-fasst werden, z. B. Button-Klicks oder Absenden eines Formulars. Untereiner solchen Komponente können im Baum auch weitere Presentatio-nal Components angeordnet werden.

Durch diese klar definierten Kommunikationswege wird die Zu-ständigkeit der Komponenten begrenzt: Presentational Components er-halten Daten zur Anzeige und geben erfasste Daten aus. Sie wissen aller-dings nicht, woher die eingehenden Daten stammen oder wie die ausge-


24.1 Container und Presentational Components 643

henden Daten verarbeitet werden. Dadurch sind solche Komponenteneinfach wiederverwendbar und austauschbar. Stellen Sie sich am bes-ten vor, sie entwickeln Komponenten für eine Drittanbieter-Bibliothek.Niemand möchte eine externe Komponente einsetzen, die sehr anwen-dungsspezifische Logik enthält.

PresentationalComponents imBookMonkey

Wir haben im BookMonkey bereits intuitiv Presentational Com-ponents entwickelt: Die BookListItemComponent aus Iteration I erhält le-diglich ein einzelnes Buch zur Anzeige und besitzt keine weiteren Ab-hängigkeiten. Auch die BookFormComponent aus Iteration IV ist prak-tisch eine Presentational Component: Sie nutzt zwar den BookExists-ValidatorService zur Validierung der Formularwerte, allerdings ist die-se Ausnahme legitim. Hier ist eine hohe Wiederverwendbarkeit zuerkennen: Die Komponente wird zum Anlegen und Bearbeiten einesBuchs eingesetzt, sie hat aber keine Kenntnis darüber, in welchem Kon-text sie verwendet wird oder wie die Daten verarbeitet werden.

Presentational Components können übrigens in den meisten Fällendie Change-Detection-Strategie OnPush verwenden, denn sie kommuni-zieren nur über Bindings mit dem Rest der Anwendung. Die ChangeDetection besprechen wir ab Seite 661 im Detail und betrachten dortauch die OnPush-Strategie.

Container Components

Datenhaltung undServicekommunikation

Die Aufgaben der Container Components sind die Datenhaltung undKommunikation mit der gesamten Anwendung. Sie verfügen über Ab-hängigkeiten zu allen benötigten Services, etwa dem Redux Store oderdem Router. Außerdem besitzen Container kein eigenes umfangreichesMarkup: Ihre einzige Aufgabe ist es, Presentational Components zu or-chestrieren. OrchestrierungDeshalb finden sich im Template keine anderen Elementeals die Host-Elemente der Kindkomponenten und ggf. einzelne <div>-Container zur Strukturierung.

Container müssen alle Daten für die eingebundenen PresentationalComponents bereitstellen und mithilfe von Property Bindings im Kom-ponentenbaum nach unten durchreichen. Events von den Kindkompo-nenten müssen erfasst und verarbeitet werden.

Container sind meist sehr spezifisch für eine Seite oder einen funk-tionalen Teilbereich einer Seite. An oberster Stelle in der Hierarchie derKomponenten steht also immer ein Container, der die Datenhaltungorganisiert und mit den Kindkomponenten kommuniziert. Beim Rou-ting sollten Sie ausschließlich Container Components verwenden, denndurch eine geroutete Komponente wird eine Seite und damit auch diehöchste Ebene der Hierarchie definiert. Dies ist immer eine sehr spezi-fische Angelegenheit.


644 24 Wissenswertes

Intermediäre Container In manchen Veröffentlichungen wird vorgeschlagen, dass in einer Hier-archie von Presentational Components auch weitere Container einge-fügt werden können. Das ist dann sinnvoll, wenn die Struktur zu kom-plex ist, um alle Daten durch den gesamten Baum zu kommunizieren.Durch solche »Zwischencontainer« lassen sich die Daten für einen Astdes Baums separat verwalten, sodass der übergeordnete Container nichtmit dieser Aufgabe betraut wird.

Observables und dieAsyncPipe

Die Aufgabe von Containern ist es auch, Observables mithilfe derAsyncPipe aufzulösen und die Daten synchron an die Kindkomponen-ten weiterzugeben. Wir sollten im Idealfall keine Observables direkt anProperty Bindings übergeben. So hat die Kindkomponente keine Kennt-nis über die technische Umsetzung des Datenstroms und ist dadurchbesonders gut wiederverwendbar.

Listing 24–1Observable au�ösen im

Container

<my-presentational [data]="data$ | async"></my-presentational>

Gegenüberstellung

In Tabelle 24–1 sind die wichtigsten Charakteristiken der beiden Kom-ponentenarten gegenübergestellt. Elementar ist es, dass Presentatio-nal Components keine Abhängigkeiten zu Services besitzen. Außerdemdürfen Container Components nur die Orchestrierung durchführen undkeine View mit gestalterischen Inhalten besitzen.

Ordnerstruktur Es ist gute Praxis, die beiden Komponentenarten auch in der Ord-nerstruktur voneinander zu trennen. Dazu eignen sich zwei Ordner mitder Bezeichnung containers und components.

Wir haben das Konzept der Container und Presentational Com-ponents im BookMonkey nicht konsequent umgesetzt, um die Komple-xität der Baumstruktur nicht zu erhöhen. Sie sollten in der Praxis fall-weise entscheiden, ob Sie die Trennung durchführen oder nicht. Hilf-reich sind dazu Konventionen im Team, sodass alle Entwickler eineneinheitlichen Stil verfolgen.

Tab. 24–1Gegenüberstellung

Container undPresentationalComponents

Container Presentational

Wiederverwendbarkeit ? ???

Austauschbarkeit ? ???

Abhängigkeit zu Services ??? keine

Komplexität ?? ?

Markup ? ???


707

Index

AActivatedRoute siehe Router,

ActivatedRouteActivatedRouteSnapshot siehe Router,

ActivatedRouteSnapshotAhead-of-Time-Kompilierung (AOT) 435,

522, 523Android 603, 606, 637Angular CLI 4, 16, 21, 53, 65, 105, 114,

123, 138, 144, 362, 378, 408,428, 513, 524, 648, 685

angular.json 56Befehlsübersicht 685con�gurations 57, 63, 440, 514

development 515production 515

Schematics 57, 604, 616, 648, 687Angular Copilot 652Angular Material 654AngularDoc 651AngularJS ix, xi, 677

ngMigration Assistent 681ngMigration Forum 682

AppModule 7, 62, 75, 145, 183, 263, 357,367, 387, 406, 481, 621

Arrow-Funktion 39Asynchrone Validatoren 325, 331AsyncPipe 583, 644Attributdirektiven siehe Direktiven,

AttributdirektivenAttribute Bindings siehe Bindings,

Attribute BindingsAugury 14, 257

Component Tree 258Injector Graph 257Router Tree 258

BBehavior Driven Development 461Bindings 73, 369

Attribute Bindings 101, 369

Class Bindings 101, 369Event Bindings 78, 108, 113Host Bindings 369Property Bindings 77, 97, 98, 104,

369Style Bindings 102, 369Two-Way Bindings 79, 264

Bootstrap CSS 655Bootstrapping 6, 62, 388, 522, 620, 674,

679BrowserModule sieheModule,

BrowserModuleBuild-Service 530Bundles 406, 520

CCamelCase 60, 91, 363Change Detection 80, 258, 355, 375, 519,

643, 657, 661detectChanges() 479ExpressionChangedAfterItHasBe-

enCheckedError664

Lifecycle Hooks 668markForCheck() 670NgZone 666

runOutsideAngular() 667OnPush 671Strategien 669Unidirectional Data Flow 665Zonen 666

Child Components siehe Komponenten,Kindkomponenten

Chrome Developer Tools 169ChromeDriver 468Chunks 409, 520Class Bindings siehe Bindings, Class

BindingsCodeanalyse 650Codelyzer 123


708 Index

CommonModule sieheModule,CommonModule

Compodoc 650Component (Decorator)

selector 70, 366styles 74styleUrls 74template 70templateUrl 72

Component Development Kit 655Component Tree siehe

Komponentenbaumcon�gurations siehe Angular CLI,

con�gurationscon�rm() (Dialog) 194, 423Constructor Injection 127constructor() siehe Klassen, KonstruktorContainer Components siehe

Komponenten, ContainerComponents

Content Projection 660Multi Content Projection 660

CRUD 181CSS 7, 65, 73, 101, 102, 156, 166, 170,

608, 689Cypress siehe Testing, Cypress

Ddashed-case 60, 91DateValueAccessorModule 275Decorators 7, 46, 70

Component 9, 70Directive 366, 379HostBinding 369HostListener 371Inject 134, 517Injectable 128, 138Input 104, 106, 368NgModule 7, 75, 144, 403Output 112, 117Pipe 353ViewChild 268, 278, 659

Default Export 341Dependency Injection 125Deployment 513Deployment-Pipeline 530Destructuring 44Directive (Decorator) 366, 379

selector 379

Direktiven 365Attributdirektiven 82, 366, 368,

378Strukturdirektiven 80, 366, 373,

376, 381disabled 100Docker 531Dokumentation 650DOM-Propertys 100, 103Drittkomponenten 654Duck Typing 485Dumb Components siehe

Komponenten,Presentational Components

EE2E siehe Testing, End-To-End Tests (E2E)ECMAScript 28EditorCon�g 13ElementRef 370

nativeElement 370Elementreferenzen 79Emulator 637enableProdMode() 63, 519End-To-End Tests (E2E) siehe Testing,

End-To-End Tests (E2E)environment 63ESLint 60Event Bindings siehe Bindings, Event

BindingsEvents

blur 111change 111click 111, 117contextmenu 111copy 111dblclick 111focus 111keydown 111keyup 111, 236mouseout 111mouseover 111paste 111select 111submit 111

FFeature-Module sieheModule,

Feature-ModuleFilter siehe PipesFormsModule sieheModule,

FormsModule


Index 709

Formulare 261Control-Zustände

dirty 265pristine 265touched 265untouched 265valid 265

Reactive Forms 262, 288formArrayName 293FormBuilder 298formControlName 292, 305formGroupName 292ngSubmit 296patchValue() 297reset() 296setValue() 297statusChanges 299valueChanges 299

Template-Driven Forms 262zurücksetzen 296

forwardRef 136

GGenymotion 637Getter 35, 369GitHub 18, 49, 189, 529God object 560Google Chrome 14, 257, 597

Developer Tools 169, 257, 598Guards 416

CanActivate 417, 418, 422, 425CanActivateChild 417CanDeactivate 417, 420CanLoad 417

HHeadless Browser 530History API 142, 149, 526Host Bindings siehe Bindings, Host

BindingsHost Listener 371Host-Element 71, 371, 660HostBinding (Decorator) 369HTTP 181HttpClient 490

delete() 183get() 183head() 183Interceptor siehe Interceptorenpatch() 183post() 183

put() 183HttpClientModule sieheModule,

HttpClientModuleHttpClientTestingModule siehe Testing,

HttpClientTestingModuleHttpParams 187HttpTestingController 490

Ii18n 340, 433

i18n-Attribut 437, 443i18n-placeholder 438i18n-title 438i18nFile 440, 447i18nFormat 440, 447i18nLocale 440, 447I18nPluralPipe siehe Pipes,

I18nPluralPipeI18nSelectPipe siehe Pipes,

I18nSelectPipeIvy siehe Renderer, IvyLOCALE_ID 340, 434ngx-translate 442registerLocaleData() 340XLIFF 438XMB 438XTB 438

Immutability 32, 186, 558, 565, 578, 673Inject (Decorator) 134Injectable (Decorator) 128, 418InjectionToken 135Injector 387Inline Styles 74Inline Templates 72Input (Decorator) 104, 106, 376Integrationstests siehe Testing,

IntegrationstestsInterceptoren 245, 250

intercept() 246Interfaces 38Internationalisierung siehe i18nInversion of Control 126iOS 603, 606Isolierte Unit-Tests siehe Testing, Isolierte

Unit-TestsIvy siehe Renderer, Ivy

JJasmine 461, 464, 467

afterEach 463and.callFake() 488


710 Index

and.callThrough() 488and.returnValues() 488and.throwError() 488async() 498beforeEach() 463, 470describe() 463, 470done() 498expect() 463fakeAsync() 499it() 463, 470spyOn() 487

JavaScript-Module 8, 388Jest siehe Testing, JestJust-in-Time-Kompilierung (JIT) 478, 522

KKarma 466

toHaveBeenCalled() 488toHaveBeenCalledBefore() 488toHaveBeenCalledTimes() 488toHaveBeenCalledWith() 488

kebab-case siehe dashed-caseKendoUI 656Klassen 34

Konstruktor 36super 37

Komponenten 8, 69, 366Container Components 641Dumb Components siehe

Komponenten,Presentational Components

Elternkomponente 118, 665Hauptkomponente 70, 94, 112Kindkomponente 97, 659, 665Presentational Components 106,

642Smart Components siehe

Komponenten, ContainerComponents

Komponentenbaum 97, 108, 114, 158,258, 680

Konstruktor siehe Klassen, Konstruktor

Ll10n siehe i18nLambda-Ausdruck 39Lazy Loading 405, 539, 545, 572Lifecycle-Hooks 656

ngAfterContentChecked 659ngAfterContentInit 659ngAfterViewChecked 659

ngAfterViewInit 659ngDoCheck 659ngOnChanges 312, 659ngOnDestroy 218, 659ngOnInit 94, 162, 659

loadChildren siehe Routende�nitionen,loadChildren

LOCALE_ID 357, siehe i18n, LOCALE_IDLocation 498Lokalisierung siehe i18n

MMarble Testing siehe Testing, Marble

TestingMatcher 463, 695Memoization 582Migration von AngularJS siehe Upgrade

von AngularJSMini�zierung 521Mocks 460, 482, 487Models 397Module 387

BrowserModule 391CommonModule 392Feature-Module 391FormsModule 263, 270HttpClientModule 183, 189NgModule (Decorator) 7

declarations 75, 145, 389exports 394imports 390providers 128, 129, 389, 399

@NgModule() 388ReactiveFormsModule 300Root-Modul 387, 391, 621Shared Module 394

Module Loader 680multi 248Multiprovider 248

NNamenskonventionen 91NativeScript 601, 637

Playground 618Preview 618Schematics 604, 616

NativeScript CLI 611ng-bootstrap 655ng-container 437ng-xi18n 438, siehe i18n, ng-xi18nNgContent 660


Index 711

NgFor 91even 81�rst 81Hilfsvariablen 81index 81last 81odd 81trackBy 646

NgForm 268NgIf 196, 374, 376

else 645ngModel 264NgModule sieheModule, NgModulengRev 652NgStyle 102NgSwitch 82NgSwitchCase 82NgSwitchDefault 82ngWorld 653ngx-bootstrap 655Node.js 14NPM 14

package-lock.json 58package.json 58, 448run 58, 448start 23

OOber�ächentests 467, siehe Testing,

Ober�ächentestsObservables 151, 182, 184, 202, 350,

358, 417, 423, 427, 429, 498,644, 659

OpenAPI 227Output (Decorator) 112, 116

Ppackage.json siehe NPM, package.jsonPage Objects 505pathMatch 160Pipe (Decorator) 353

name 353pure 353, 355

Pipes 83, 339AsyncPipe 220, 342, 350, 358CurrencyPipe 342, 346DatePipe 342, 343, 357DecimalPipe (number) 342, 345eigene 353I18nPluralPipe 342, 352I18nSelectPipe 342, 351

JsonPipe 342, 349KeyValuePipe 342, 348LowerCasePipe 342PercentPipe 342, 345PipeTransform 353SlicePipe 342, 347TitleCasePipe 342, 343UpperCasePipe 342

platformBrowserDynamic 522Plattform 673POEditor 438, 445, 451Poly�lls 5Prä�x 57, 95, 687Preloading 410, 414

PreloadAllModules 410PreloadingStrategy 410, 415

Presentational Components sieheKomponenten,Presentational Components

PrimeNG 656Promises 351, 417, 423, 427, 498, 504Property Bindings siehe Bindings,

Property BindingsPropertys 100Protractor 467

clear() 504click() 504getAttribute() 504getText() 504sendKeys() 504submit() 504takeScreenshot() 504

providers sieheModule, NgModule(Decorator), providers

Pure Function 355, 577, 582, 584

QQuery-Parameter 186

RReactive Extensions (ReactiveX) siehe

RxJSReactive Forms siehe Formulare,

Reactive FormsReactiveFormsModule sieheModule,

ReactiveFormsModuleReaktive Programmierung siehe RxJSRedux 553

Action 565Action Creator 574Actions 573


712 Index

Bibliotheken 566DevTools 597dispatch 565, 576E�ects 584Entity Management 590Meta-Reducer 569NgRx 567

Schematics 567Pure Function siehe Pure FunctionReducer 565, 577Routing 590Seitene�ekte siehe Redux, E�ectsSelektoren 581State 565Store 565, 576Testing siehe Testing, Redux

registerLocaleData() siehe i18n,registerLocaleData()

Rekursion siehe RekursionRenderer 372, 673

Ivy 408, 437, 442, 449, 674Resolver

resolve() 427Rest-Syntax 43, 45, 354Reverse Engineering 650Root Component siehe Komponenten,

HauptkomponenteRoot-Modul sieheModule, Root-ModulRoot-Route 146Routende�nitionen 143

component 143loadChildren 407, 412, 417path 143, 412pathMatch 147redirectTo 155relativeTo 157resolve 429

Routensnapshot 151, 162Router 142

ActivatedRoute 150, 157, 429ActivatedRouteSnapshot 418, 420,

428Guards siehe Guardsnavigate() 156, 194navigateByUrl() 157UrlTree 417, 418, 423

RouterLink 147, 156, 163RouterLinkActive 156, 166RouterModule 145, 392, 415

forChild() 393forRoot() 145, 392, 410

RouterOutlet 146Mehrere RouterOutlets 431

RouterTestingModule siehe Testing,RouterTestingModule

Routing 141RxJS 198, 299, 677, 691

BehaviorSubject 216, 556, 580catchError() 588concatMap() 222debounceTime() 237distinctUntilChanged() 238, 580exhaustMap() 222�lter() 210, 587interval() 217map() 209, 228, 580, 588mergeMap() 221Observables siehe Observablesof() 231Operatoren 691pipe() 212reduce() 211ReplaySubject 216retry() 230retryWhen() 231scan() 211, 563, 566, 580share() 214, 351shareReplay() 430, 563startWith() 563Subject 215, 235subscribe() 192switchMap() 222, 239takeUntil() 219tap() 240, 247throwError() 232withLatestFrom() 223

SSafe-Navigation-Operator 77Schematics 22, 23, 567, 676, siehe

Angular CLI, SchematicsSchnellstart xvi, 3Selektor 71, 91, 95, 379, 660, 687Selenium 467Semantic UI 65, 75, 195, 378Separation of Concerns 137, 508, 641Service 125, 138, 350, 418, 424, 690Setter 35, 376Shallow Copy 43, 578Shallow Unit-Tests siehe Testing, Shallow

Unit-Tests


Index 713

Shared Module sieheModule, SharedModule

Shim siehe Poly�llSingle Source of Truth 564Singleton 408, 424Smart Components siehe Komponenten,

Container ComponentsSoftwaretests xvii, 457, siehe TestingSourcemaps 520Spread-Operator 41, 227, 354, 395Spread-Syntax siehe Spread-OperatorStrukturdirektiven siehe Direktiven,

StrukturdirektivenStubs 460, 482Style Bindings siehe Bindings, Style

BindingsStyle einer Komponente 73Style-URL 74Styleguide 123, 678

Folders-by-Feature 679Rule of One 75, 679

Swagger siehe OpenAPISystem Under Test 482

TTemplate-Driven Forms siehe Formulare,

Template-Driven FormsTemplate-String 39, 191Template-Syntax 76Template-URL 72TemplateRef 376TestBed 480, siehe Testing, Angular,

TestBedTesting

async() 470, 479automatisierte Tests 457compileComponents() 479ComponentFixture 479Cypress 469End-To-End Tests (E2E) 459fakeAsync() 470HttpClientTestingModule 470inject() 470, 485Integrationstests 459, 460, 480Isolierte Unit-Tests 471, 473, 474Jest 468Marble Testing 595NO_ERRORS_SCHEMA 479Ober�ächentests 459, 500, 530Redux 593RouterTestingModule 470, 494

Shallow Unit-Tests 477TestBed 470TestBed.con�gureTestingModule()

477, 484TestBed.get() 486TestBed.schemas 479tick() 499Unit-Tests 96, 459, 460, 530

Tree Shaking 130, 521, 674tscon�g.json siehe TypeScript,

tscon�g.jsonTSLint 13, 59, 123, 175, 530

tslint.json 59Two-Way Bindings siehe Bindings,

Two-Way BindingsType Assertion 304TypeScript 25, 681

any 33const 31implements 38let 31tscon�g.json 58, 59var 30void 35

UUmgebungen 513Union Types 44Unit-Tests 470, siehe Testing, Unit-TestsUnveränderlichkeit siehe ImmutabilityUpdate von Angular 675Upgrade von AngularJS 677

Upgrade Module 678UrlTree siehe Router, UrlTreeuseFactory 132useValue 132, 484useValueAsDate 275

VValidatoren

Custom Validators sieheValidatoren, eigene

eigene 320Reactive Forms

email 295max 295maxLength 295min 295minLength 295pattern 295required 295


714 Index

requiredTrue 295Template-Driven Forms

email 266maxlength 266, 275minlength 266, 275pattern 266required 266requiredTrue 266

ValidationErrors 329Validierung xvi, 261, 266, 320Vererbung 37View 70, 477, 659View Encapsulation 74ViewChild 268ViewContainerRef 376

createEmbeddedView() 376Visual Studio Code 11, 123

WWebDriver 468Webpack 22, 64, 513, 681Webserver 149, 466, 519, 526, 687

angular-cli-ghpages 529Apache 527Express.js 528, 543, 544GitHub Pages 529IIS 527lighttpd 528nginx 527, 531

XXML 609XMLHttpRequest 172

ZZirkuläre Abhängigkeiten 136Zone.js 499, 666, 677Zonen siehe Change Detection, ZonenZwei-Wege-Bindungen siehe Two-Way

Bindings


lernen sie die grundlagen von angular mit angu ferdinand ... (bu… · ferdinand malcher ·...

Documents