uns ab Seite 380 an.
Das Template einer Komponente
Eine Komponente ist immer mit einem Template verknüpft. Das Template ist der Teil der Komponente, den der Nutzer sieht und mit dem er interagieren kann. Für die Beschreibung wird meist HTML verwendet1, denn wir wollen unsere Anwendung ja im Browser ausführen. Innerhalb der Templates wird allerdings eine Angular-spezifische Syntax eingesetzt, denn Komponenten können weit mehr, als nur statisches HTML darzustellen. Diese Syntax schauen wir uns im Verlauf dieses Kapitels noch genauer an.
Um eine Komponente mit einem Template zu verknüpfen, gibt es zwei Wege:
Template-URL: Das Template liegt in einer eigenständigen HTML-Datei, die in der Komponente referenziert wird (templateUrl).
Inline Template: Das Template wird als (mehrzeiliger) String im Quelltext der Komponente angegeben (template).
Eine Komponente besitzt genau ein Template.
In beiden Fällen verwenden wir die Metadaten des @Component()-Decorators, um die Infos anzugeben. Im Listing 6–3 sind beide Varianten zur Veranschaulichung aufgeführt. Es kann allerdings immer nur einer der beiden Wege verwendet werden, denn eine Komponente besitzt nur ein einziges Template. Die Angular CLI legt stets eine separate Datei für das Template an, sofern wir es nicht anders einstellen. Das ist auch die Variante, die wir Ihnen empfehlen möchten, um die Struktur übersichtlich zu halten.
@Component({
// Als Referenz zu einem HTML-Template
templateUrl: './my-component.html',
// ODER: als HTML-String direkt im TypeScript
template: `<h1>
Hallo Angular!
</h1>`,
// [...]
})
export class MyComponent { }
Listing 6–3 Template einer Komponente definieren
Bindings für die Kommunikation zwischen Komponente und Template
Template und Komponente sind eng miteinander verknüpft und können über klar definierte Wege miteinander kommunizieren. Der Informationsaustausch findet über sogenannte Bindings statt. Damit »fließen« die Daten von der Komponente ins Template und können dort dem Nutzer präsentiert werden. Umgekehrt können Ereignisse im Template abgefangen werden, um von der Komponente verarbeitet zu werden. Diese Kommunikation ist schematisch in Abbildung 6–1 dargestellt.
Abb. 6–1 Komponente, Template und Bindings im Zusammenspiel
Um diese Bindings zu steuern, nutzen wir die Template-Syntax von Angular, die wir gleich noch genauer betrachten. In den beiden folgenden Storys dieser Iteration gehen wir außerdem gezielt auf die verschiedenen Arten von Bindings ein.
Der Style einer Komponente
Um das Aussehen einer Komponente zu beeinflussen, werden Stylesheets eingesetzt, wie wir sie allgemein aus der Webentwicklung kennen. Neben den reinen Cascading Style Sheets (CSS) können wir auch verschiedene Präprozessoren einsetzen: Sass, Less und Stylus werden direkt unterstützt. Welches Style-Format wir standardmäßig verwenden wollen, können wir auswählen, wenn wir die Anwendung mit ng new erstellen.
Normalerweise verwendet man eine große, globale Style-Datei, die alle gestalterischen Aspekte der Anwendung definiert. Das ist nicht immer schön, denn hier kann man leicht den Überblick verlieren, welche Selektoren wo genau aktiv sind oder womöglich gar nicht mehr benötigt werden. Außerdem widerspricht eine globale Style-Definition dem modularen Prinzip der Komponenten.
Stylesheets von Komponenten sind isoliert.
Angular zeigt hier einen neuen Weg auf und ordnet die Styles direkt den Komponenten zu. Diese direkte Verknüpfung von Styles und Komponenten sorgt dafür, dass die Styles einen begrenzten Gültigkeitsbereich haben und nur in ihrer jeweiligen Komponente gültig sind. Styles von zwei voneinander unabhängigen Komponenten können sich damit nicht gegenseitig beeinflussen, sind bedeutend übersichtlicher und liegen immer direkt am »Ort des Geschehens« vor.
Ein Blick ins Innere: View Encapsulation
Styles werden einer Komponente zugeordnet und wirken damit auch nur auf die Inhalte dieser Komponente. Die Technik dahinter nennt sich View Encapsulation und isoliert den Gültigkeitsbereich eines Anzeigebereichs von anderen. Jedes DOM-Element in einer Komponente erhält automatisch ein zusätzliches Attribut mit einem eindeutigen Bezeichner, siehe Screenshot. Die vom Entwickler festgelegten Styles werden abgeändert, sodass sie nur für dieses Attribut wirken. So funktioniert der Style nur in der Komponente, in der er deklariert wurde. Es gibt noch andere Strategien der View Encapsulation, auf die wir aber hier nicht eingehen wollen.
Angular generiert automatisch Attribute für die View Encapsulation.
Die Styles werden ebenfalls in den Metadaten einer Komponente angegeben. Dafür sind zwei Wege möglich, die wir auch schon von den Templates kennen:
Style-URL: Es wird eine CSS-Datei mit Style-Definitionen eingebunden (styleUrls).
Inline Styles: Die Styles werden direkt in der Komponente definiert (styles).
Im Listing 6–4 werden beide Wege gezeigt. Wichtig ist, dass die Dateien und Styles jeweils als Arrays angelegt werden. Grundsätzlich empfehlen wir Ihnen auch hier, für die Styles eine eigene Datei anzulegen und in der Komponente zu referenzieren. Die Angular CLI unterstützt beide Varianten.
Der herkömmliche Weg zum Einbinden von Styles ist natürlich trotzdem weiter möglich: Wir können globale CSS-Dateien definieren, die in der gesamten Anwendung gelten und nicht nur auf Ebene der Komponenten. Diesen Weg haben wir gewählt, um das Style-Framework Semantic UI einzubinden, siehe Seite 70.
@Component({
styleUrls: ['./my.component.css'],
// ODER
styles: [
'h2
