<bm-book-list></bm-book-list>
Listing 6–17 Template der Hauptkomponente AppComponent (app.component.html)
Ein Präfix verwenden
Die Selektoren von Komponenten und Direktiven sollten in Angular immer mit einem Präfix versehen werden. Das Präfix soll vor allem dafür sorgen, dass Elemente der Anwendung gut von nativen HTML-Elementen unterschieden werden können. Wir beugen damit Konflikten mit anderen Elementen vor, die eventuell dieselbe Bezeichnung verdient hätten.
Beim Anlegen des Projekts mit der Angular CLI haben wir die Option --prefix=bm verwendet. Diese Angabe finden wir auch tief in der Datei angular.json wieder. Wenn wir Komponenten oder Direktiven mit der Angular CLI anlegen, wird das Präfix automatisch im Selektor verwendet. Diese Einstellung können wir in der angular.json auch ändern, sie gilt dann allerdings nur für neu angelegte Komponenten.
Bootstrapping
Damit die Anwendung funktioniert, muss die Hauptkomponente AppComponent von Angular gestartet werden. Die notwendige Anpassung hat die Angular CLI bereits für uns vorgenommen. Im AppModule in der Datei src/app/app.module.ts ist die AppComponent in der Eigenschaft bootstrap in den Metadaten des Moduls eingetragen.
Anwendung starten
Wir können die Anwendung nun mit dem Befehl ng serve starten. Rufen wir die URL im Browser auf, wird die Liste der Bücher angezeigt.
Abb. 6–2 Die Buchliste funktioniert.
Was haben wir gelernt?
Angular bricht die Template-Syntax in mehrere Konzepte auf. Mit den verschiedenen Bindings wird der Datenfluss zwischen Komponente und Template klar definiert. Hilfsmittel wie Pipes und Direktiven erleichtern uns dabei die Arbeit mit den Elementen im Template. Mit einem Blick auf ein Template ist bereits schnell erkennbar, wie sich eine Komponente verhält.
Komponenten sind die wichtigsten Bausteine einer Anwendung.
Eine Komponente besteht immer aus einer TypeScript-Klasse mit Metadaten und einem Template.
Komponenten werden an Elemente des DOM-Baums gebunden. Das ausgewählte Element wird das Host-Element der Komponente.
Für die Auswahl der DOM-Elemente wird in der Komponente ein CSS-Selektor festgelegt.
Angular verfügt über eine eigene Template-Syntax und eingebaute Direktiven, z. B. ngFor und ngIf.
Alle Bausteine der Anwendung werden mittels @NgModule() in Angular-Module organisiert. Wir nutzen Imports und Exports, um die Bausteine zu verknüpfen.
Eine Komponente muss immer in den declarations eines Moduls registriert werden.
Demo und Quelltext: https://ng-buch.de/bm4-it1-comp
Defekte Unit-Tests
Die Angular CLI legt für jede Komponente und für viele weitere Bausteine eine Unit-Test-Datei an. Die enthaltenen Tests sind trivial und dienen lediglich als Einstiegsbeispiel. Wenn wir allerdings die im Buch beschriebenen Änderungen am Sourcecode vornehmen, so werden die automatisch angelegten Tests fehlschlagen. Ein Test prüft zum Beispiel, ob der Text »book-monkey app is running!« erscheint. Da wir die Überschrift entfernt haben, ist die Prüfung ebenso obsolet geworden und kann entfernt werden.
In anderen Fällen reicht es aus, die Konstruktoren mit sogenannten Stubs zu versorgen bzw. mittels NO_ERRORS_SCHEMA unbekannte Eigenschaften an Elementen zu erlauben. Da es sich bei Softwaretests um ein anspruchsvolles Thema handelt, widmen wir uns in einem dedizierten Abschnitt den Unit-Tests (ab Seite 483). Dort stellen wir die verschiedenen Testing-Strategien ausgiebig vor. Zusätzlich können Sie die mit dem QR-Code markierten Demos des Book-Monkeys studieren. In den Repositorys werden Sie zusätzliche Unit-Tests, Integrations- und Oberflächentests finden, auf die wir im Buch nicht eingegangen sind.
6.2Property Bindings: mit Komponenten kommunizieren
Im vorhergehenden Abschnitt haben wir eine erste Komponente eingeführt, mit der wir eine Listenansicht für unsere Buchbibliothek erstellt haben. Ihre wahre Stärke zeigen Komponenten allerdings dann, wenn sie verschachtelt werden. Wir wollen eine weitere Komponente einführen, die ein Element der Buchliste repräsentiert. Dabei werden wir das Prinzip der Property Bindings in der Praxis anwenden und lernen, wie Daten in eine Komponente hineinfließen können.
6.2.1Komponenten verschachteln
Im ersten Teil dieser Iteration haben wir bereits gelernt, dass wir Komponenten über ihren Selektor an HTML-Elemente im Template binden können. Verwenden wir das Element <my-component>, so wird an dieser Stelle die Komponente mit ihrer Logik und ihrem Template eingesetzt.
Komponentenbaum aus verschachtelten Komponenten
Auf diese Weise können wir Komponenten beliebig tief verschachteln. Im Template der Komponente MyComponent können weitere Komponenten an DOM-Elemente gebunden werden usw. Die Komponenten unserer Anwendung referenzieren sich damit untereinander und bilden eine Baumstruktur (engl. Component Tree), wie sie beispielhaft in Abbildung 6–3 dargestellt ist.
Abb. 6–3 Schema eines Komponentenbaums
Die allererste Komponente der Anwendung ist die Hauptkomponente (engl. Root Component). Sie wird beim Bootstrapping der Anwendung geladen. Alle darunterliegenden, eingebundenen Komponenten werden Kindkomponenten (engl. Child Components) genannt.
Durch die Verschachtelung können wir unsere Anwendung modular gestalten. Wir können einzelne Teile der Anwendung in Komponenten auslagern, die einzeln wartbar, wiederverwendbar und testbar sind.
6.2.2Eingehender Datenfluss mit Property Bindings
Wenn wir eine Anwendung aus verschachtelten Komponenten aufbauen, müssen die Komponenten miteinander kommunizieren können. Die Übertragung von Daten in eine Komponente hinein funktioniert über Property Bindings. Damit können wir Daten im Komponentenbaum nach unten übertragen. Der grundsätzliche Weg ist dieser: Über HTML-Attribute des Host-Elements setzen wir Eigenschaften der angebundenen Komponente. Innerhalb der Komponente können wir diese Eigenschaften auslesen.
Das Beispiel zeigt, wie Daten an Eigenschaften gebunden werden.
<my-component [property]="expression"></my-component>
Die Propertys werden