Decorators
Wir werden Decorator überall in Angular finden, egal ob bei Services, Directives, Pipes oder Services. Das Konzept des Decorators ist jedoch kein Angular spezifisches Konzept. Es ist ein übliches Design Pattern in der objektorientierten Programmierung.
In Angular verarbeitet unsere Klasse die Logik, jedoch ist das nicht alles, was Angular braucht, um zu wissen, wie es die Komponente erstellen muss. Die ganzen weiteren Informationen geben wir Angular eben genau über diesen Decorator.
@Component({
selector: 'my-component',
template: `<p>Hello</p>`,
styles: [
`
.some-class {
display: none;
}
`
]
})
export class MyComponent {}Directives
Der @Directive-Decorater erlaubt es uns unsere eigenen Direktiven zu erstellen. Mit einer Direktive können wir ein gewisses Verhalten zu einer gewissen Komponente bzw. einem Element hinzufügen.
@Directive({
selector: '[my-selector]'
})So können wir zum Beispiel eine Direktive erstellen, welche die Hintergrundfarbe zu einer zufälligen Farbe wechselt.
Der @HostBinding-Decorator bindet sich an den Host, also das Element oder die Komponente, an welche die Direktive angehängt wird. Dieses Host Binding können wir dann nutzen, um ein Property des Hosts zu ändern.
Nun nutzen wir die Direktive wie folgt.
Pipes
Der @Pipe-Decorater erlaubt es uns eigene Pipes zu erstellen, um Daten zu filtern, die dem Nutzer angezeigt werden.
Die folgende Pipe kehrt ein Wort um.
Die Idee dahinter ist, dass wir einen bestimmten Wert bekommen und diesen in irgendeiner Weise transformieren und ihn zurückgeben.
Nun nutzen wir unsere Pipe, um den String reverse me umzukehren.
Es gibt noch viele weitere Pipes, die uns Angular bereits zur Verfügung stellt.
Services
Um einen Service zu erstellen nutzen wir den @Injectable-Decorator. Injectables stehen in engem Zusammenhang mit dem Konzept der Dependency Injection in Angular. Es steht auch in Zusammenhang mit einigen Aspekten der Architektur, wie dem Prinzip der Single Responsibility.
Oftmals müssen wir in unseren Komponenten Daten anzeigen, welche von einer API kommen. Unsere Komponente müsste einen HTTP-Request machen, um die Daten abzurufen. Das ist jedoch nicht ideal aus folgenden Gründen:
Es fügt der Komponente zusätzliche Verantwortlichkeiten zu. Unsere Komponente soll nur diese Liste anzeigen und sich nicht um die Business-Logik kümmern.
Was, wenn eine andere Komponente ebenfalls Zugriff auf diese Daten braucht? Wenn wir das in unserer Komponente machen, können andere Komponenten nicht auf die Daten zugreifen und es muss erneut eine Request gemacht werden.
Ein injizierbarer Service erlaubt es uns Business-Logik zu definieren und Daten in einem Singleton-Objekt zu cachen (das bedeutet in der Regel, dass unsere gesamte Anwendung dieselbe Instanz einer einzigen Klasse gemeinsam nutzt). Wir können diesen Service dann in alle Komponenten einbinden, die seine Methoden oder Daten nutzen müssen.
Beachte, dass wir ein providedIn-Property bereitstellen. Durch die Bereitstellung dieses Services in der root wird eine einzige Instanz davon für die gesamte Anwendung gemeinsam genutzt. Das bedeutet, wenn eine Komponente eine Änderung an someData auslöst, können alle anderen Komponenten auf dieselben aktualisierten Daten zugreifen. Auch dies hängt mit der Dependency Injection zusammen, auf die wir später noch näher eingehen werden.
Um nun den Service zu nutzen, müssen wir ihn wie folgt injizieren.
Last updated