We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Erste Schritte mit Angular 2 - Components; Directives, Templates

00:00

Formal Metadata

Title
Erste Schritte mit Angular 2 - Components; Directives, Templates
Title of Series
Number of Parts
16
Author
License
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
AngularJS ist eines der bekanntesten JavaScript-Frameworks. Die neue Version, Angular 2, befindet sich zurzeit in der Beta-Phase. Sie baut auf den Erfahrungen und positiven Eigenschaften von Angular 1 auf und soll schneller und moderner sein. Doch man braucht kein Vorwissen in Angular, um Angular 2 schon heute zu verwenden. Das Framework wurde komplett neu geschrieben, ist konzeptionell einfacher und verwendet eine neue Syntax. Dieser Talk ist eine Einführung in das Framework: wir lernen Components kennen, werfen einen Blick auf die Template-Syntax, Pipes und Directives und sehen uns Dependency Injection an.
Bindung <Stochastik>InternetdienstJavaScriptComputing platformDesktopServer (computing)Web browserComponent-based software engineeringRoute of administrationArrow of timeORIGIN <Programm>StatisticsInternetCodeWEBMobile appTemplate (C++)Computing platformFRAMEWORK <Programm>American Physical SocietyComponent-based software engineeringSocial classEuropean Physical SocietyArmModule (mathematics)Mobile WebPhysical quantity9 (number)Web browserEPSSoftware testingMusical ensembleStatistikerService (economics)WORKS SuiteJavaScriptTouchscreenVotingPixelModel View ControllerCache (computing)Software testabilityWeightPHP
Patch (Unix)Component-based software engineeringScripting languageTypInterpolationBindung <Stochastik>File viewerMetadataTemplate (C++)Component-based software engineeringMobile appNumber theorySocial classMoment (mathematics)String (computer science)Data modelControl flowBookmark (World Wide Web)STYLE <Programmierumgebung>InterpolationHTMLAttribute grammarSelektorRoute of administrationComputer fileoutputRAIDPatch (Unix)Module (mathematics)Hand fanNoten <Programm>MetreCodeTouchscreenEuropean Physical SocietyInterior (topology)
InterpolationBindung <Stochastik>Component-based software engineeringDisplayTemplate (C++)Service (economics)InternetdienstSocial classCodeInternetSimilarity (geometry)File viewerSTYLE <Programmierumgebung>Function (mathematics)outputComponent-based software engineeringData modelRoundingService (economics)Regulärer Ausdruck <Textverarbeitung>LeadDirection (geometry)Variable (mathematics)Local ringHash functionSwitch <Kommunikationstechnik>FRAMEWORK <Programm>Instanz <Informatik>TEXEvent horizonElement (mathematics)IndexWEBMechanism designSoftware frameworkSoftware design patternTemplate (C++)Asterisk <Software>ForestData storage deviceDisplayString (computer science)Mobile appHOL
Service (economics)HTTPInternetdienstJavaScriptInstanz <Informatik>ProviderMetreOutline of industrial organizationDebuggerString (computer science)PAL <Programmiersprache>Constructor (object-oriented programming)Component-based software engineeringSocial classNumberCasting (performing arts)Web browserService (economics)Object (grammar)Strich <Typographie>ArmToken ringPlane (geometry)Point (geometry)Module (mathematics)RippingTemplate (C++)CASTPython <Programmiersprache>Palm <Marke>Number theoryoutputParticle detectorSlash <Programm>File viewerTime zoneJavaScriptMobile appCodeChaining
outputTemplate (C++)Data modelComponent-based software engineeringModule (mathematics)HTTPComponent-based software engineeringWEBServer (computing)File viewerSTYLE <Programmierumgebung>SelektorDefault (computer science)Template (C++)Particle detectorUnit testingSlide ruleValidationCodeWeb browserForm (programming)Social classComputing platformPOWER <Computerarchitektur>Module (mathematics)NewsletterModule (mathematics)Software testingScientific modellingMusical ensembleError messageXML
Transcript: German(auto-generated)
Hört ihr mich? Hallo, tut mir leid, dass es ein bisschen später losgegangen ist. Irgendwie lag das an den Farben. Wie geht es euch? Gut.
Konferenz bisher gut. Ich bin Michaela. Bin ich zu laut? Ich höre mich so heilend. Perfekt. Okay, ich bin Michaela. Ich bin UX-Designerin und Frontend-Entwicklerin aus Berlin. Hab da das Glück, das meistens und auch jetzt seit fünf Jahren mit meiner eigenen Firma zu machen.
Wir heißen Geil Danke. Wir sind zu zweit meistens. In fünf Jahren, ihr könnt euch vermutlich vorstellen, da haben wir echt viele Projekte bisher gearbeitet. Manche ziemlich groß, mit vielen Developern, vielen Designern, noch mehr Projektmanagern.
Manche eher klein, wo man sich dann wirklich um alles kümmern muss. Was die Projekte aber so gemeinsam haben, ist, dass wir oft an Web-Apps oder noch öfter an Hybrid-Apps arbeiten.
Und da sehr, sehr häufig AngularJS eingesetzt haben. Und ich hoffe, dass wir das jetzt auch in Zukunft mit Angular 2 so weitermachen. Und deswegen bin ich eigentlich heute hier, um euch einen groben Überblick über Angular 2 zu geben. Denn später gibt es ja noch drei Talks, noch mal zu speziellen Themen in Angular 2, sodass ihr da gut vorbereitet seid darauf.
Hier mal die Agenda. Das sind so die Themen, die ich ansprechen will. Ich hoffe, ihr kommt zu allem. Ich will kurz euch zeigen, was Components sind, wie das Data Binding in Angular 2 funktioniert. Euch die Template Syntax zeigen.
Und noch etwas über Services, die Dependency Injection und wenn möglich auch noch über Pipes erzählen. Ich beginne aber jetzt mal nicht mit den Components, sondern vielleicht mit einer größeren Überblicksfrage. Was ist Angular 2 eigentlich? Und hier habe ich einen schönen Tweet gefunden.
Angular 2 wurde von Grund auf neu geschrieben. Das heißt jetzt nicht, dass Leute, die mit AngularJS irgendwie entwickelt haben, wirklich alles vergessen müssen, was sie jemals gelernt haben.
Aber das bedeutet auf jeden Fall, dass auch wer bisher noch nicht AngularJS geschrieben hat, eigentlich einen sehr, sehr guten Einstieg in Angular 2 finden kann. Eine weitere Frage, die sich vielleicht stellt, weshalb wurde das von Grund auf neu geschrieben?
Also wie kommt man dazu? Ein Framework, was eigentlich total erfolgreich ist und oft eingesetzt wird, jetzt noch mal komplett neu zu entwickeln. Und als Geisteswissenschaftler gehe ich an die Frage Hermann Neutisch ran und überlege, was war denn so zu der Zeit, als AngularJS entwickelt wurde im Jahr 2009? Und ich habe da mal Statistiken rausgesucht, nämlich hier aus dem Juni 2009 die Top 10 Screen Resolutions.
Da ist keine einzige dabei, die kleiner als 800 Pixel ist. Also da waren noch wirklich noch nicht viele Leute mit mobilen Devices im Internet. Andere Probleme, die Web-Entwickler damals hatten, war vielleicht hier diese Statistik noch.
Ja, drei Internet Explorer, sechs, sieben und acht unter den Top 10 Browsern im Juni 2009. An sowas wie den Vortrag, den wir eben gehört haben, oder auch nur ES 2015, JavaScript Modules, Web Components, hier vor allem Shadow DOM und Templates.
Da hat noch niemand dran gedacht damals. Und deswegen dürfte auch klar sein, dass wenn man sagt, wir verwerfen jetzt erstmal alles, und wir verwerfen vor allem auch die Unterstützung für Internet Explorer 6 zum Beispiel, da kann man doch ein sehr viel moderneres Framework jetzt noch mal bauen, wenn wir da von Grund auf neu beginnen.
In der Doku oder ich glaube in der offiziellen Readme bezeichnet Angular das Team selbst, Angular 2, als Plattform. Sie schreiben, Angular ist a development platform for building mobile and desktop web applications. Und ich glaube da können wir uns vorstellen, dass es einfach ein bisschen mehr sein will als nur ein Framework.
Angular 2 ist zum Beispiel Plattform unabhängig, das heißt wir können Code für den Browser schreiben. Wir können aber auch Angular 2 Applications in Web-Workern laufen lassen, ohne DOM. Wir können native Apps schreiben mit NativeScript oder React Native.
Und wir können serverseitig die Seiten renden, Node.js einsetzen, PHP und .NET dafür. Wir sind außerdem so eine Art sprachunabhängig, das heißt die Applications können wir nicht nur mit JavaScript schreiben, sondern auch mit TypeScript und Dart.
Ich drehe mal kurz fest, sonst meine Stimme so rauf. Am meisten wird zurzeit TypeScript eingesetzt. Es wurde eben auch schon mal erwähnt in dem Vortrag, TypeScript ist eigentlich nichts anderes als eine sehr strikt typisierte Obermenge von JavaScript.
Das heißt wir können unsere ES5-Features benutzen, aber auch ES2015-Features einsetzen, Arrow Functions, Modules, Classes und wir können eben TypeScript-Features einsetzen. Zum Beispiel eben die Typisierung oder auch Decorators, da gehe ich später nochmal drauf ein.
Als letztes zum groben Überblick über Angular, die haben außerdem sehr hohen Wert darauf gelegt, dass wir unabhängig von Paradigmen programmieren können und dass unsere Apps testbar und performant sind. Für die Performance habe ich ja eben schon mal genannt, wir haben serverseitiges Rendering,
wir haben Views Caching und wir können die Webworker benutzen. Testbar werden die Apps, weil für Unit Tests zum Beispiel Karma und Jasmine gut integriert sind und End-to-End Tests mit Broad Rector möglich sind. Und dass wir von Paradigmen oder Programmierparadigmen unabhängig sind,
bedeutet eigentlich, dass wir jetzt nicht gezwungen sind irgendwie nach MVC oder Reactive zu schreiben. Das heißt, wir sind da eigentlich frei, wenn wir Angular 2 Apps entwickeln. Es bedeutet nicht, dass wir völlig konzeptlos davor gehen müssen. Angular Apps sind modular. Ich benutze jetzt Angular als Synonym mal für Angular 2 und AngularJS für Angular 1,
falls ich das überhaupt nochmal erwähne. Angular Apps sind modular, das heißt bestenfalls bestehen unsere Applikationen aus verschiedenen Modulen, Komponenten, die auch bestenfalls lose gekoppelt sind und alle vielleicht so wenige bis eine Aufgabe übernehmen sollten.
Meistens exportieren die dann einfach eine Klasse. Im Code könnte das so aussehen. Vielleicht auch nochmal ein kleiner Disclaimer, ich werde nicht so cool live coden wie der Vortragende davor, was echt beeindruckend war, aber ich müsste mich hier nur viel zu schlimm an die Syntax erinnern,
während ihr mir dabei zuschaut, das wäre ganz schlecht. Deswegen hier alles drin in den Folien. So könnte das aussehen. Wir haben zwei Komponenten oder zwei Module, eine Komponent und another Komponent. Die obere exportiert die Klasse mit dem export statement
und unten in der another Komponent wird über das import statement die Klasse wieder importiert. Hinter dem from steht der Modulname, dieser Punkt slash bedeutet eigentlich einfach nur, dass es im selben Folder liegt.
Das sind jetzt auch schon die Module, die so vielleicht am häufigsten vorkommen oder sehr wichtig sind, nämlich die Komponenten. Und da steigen wir jetzt gleich mal ein. In der Doku steht a Komponent controls a patch of screen real estate that we could call a view.
Wir haben also eine View, ein Template mit Markup. Und wir haben dazu die Komponent, eine Klasse sozusagen, ein View Controller, der eben steuert, was in der View angezeigt wird. Und das Ganze wird verknüpft durch Metadaten.
Hier mal ein Beispielcode dazu. Oben importieren wir einen Angular-Modul. Sodass man überhaupt Komponenten erstellen kann. Darunter folgt dann der Decorator, den ich vorhin schon erwählt habe. Der fügt in dem Moment zwei Metadaten der Komponenten hinzu.
Nämlich einmal der Selektor, in dem diese Komponente laufen soll. Und das Template. In dem Fall ist das eine statische Headline. Einfach mit einem String drin. Und ganz unten kann die Komponent-Logik dann eingefügt werden. Das ist dann die Klasse der Komponente, die wir hier exportieren.
Noch mal hier ganz kurz zum Decorator. Das ist, glaube ich, ein Proposal für ES7 auch. In Angular setzen wir das ein, um die Metadaten der Komponente zuzuordnen. Und somit zu sagen, dass Angular weiß, wie die Komponente erstellt werden soll.
In dem Fall, wie ich schon gesagt habe, ist unser Metadatum der Selektor und das Template. Die Decorators erkennen wir an dem App-Zeichen. Und sie können Klassen oder einzelne Properties mit den Metadaten anreichern,
indem das davor steht, der Decorator. Die Syntax sieht jetzt vielleicht ein bisschen fancy aus. Wir können, wie gesagt, Angular auch mit ES5 schreiben. Und hier rechts können wir dann auch sehen, eigentlich ist das sozusagen nur eine vereinfachte Syntax.
Dieser Decorator. Diese Decorator-Syntax. Also Syntactic Sugar, indem wir eben diese Komponente, die beiden Metadaten, hier geben. Letzter Punkt zu den Komponent-Decoratoren. Wir müssen das Template auf keinen Fall inline da reinschreiben.
Auch wenn wir Styles übergeben, müssen wir die nicht inline in den Komponent-Decorator schreiben, wenn wir das nicht wollen. Sondern wir können da auf Files verweisen. Und haben dann so sozusagen unsere JavaScript-Komponent-Datei oder TypeScript-Datei und eben vielleicht ein HTML-Datei mit dem Template und CSS-Dateien mit den Styles für die jeweiligen Komponenten.
Komponenten können auch ineinander verschachtet sein. Das ist vermutlich häufig der Fall. Ich habe hier so ein einfaches Beispiel. Eine Chrome-Extension, die ich mal geschrieben habe. Da haben wir einerseits die App, die ist dafür zuständig,
die Chrome-Extension ist dafür zuständig, Links zu speichern in Bookmarks. Wir haben also unsere App, die gesamte Liste an Bookmarks. Und wir haben aber innerhalb der Apps sozusagen Child-Komponenten. Jeweils ein Bookmark wäre jetzt eine Komponente.
Grafisch dargestellt könnte das auch so aussehen. Ich zeige euch das mal in einem Code-Beispiel. Nicht unbedingt von dem Bookmark-Code, sondern nehmen wir an, wir wollen eine App schreiben, die alle Talks der Enter.js auflistet. Da haben wir einmal die App für die Enter.js
und da drinnen einzelne Talks, werden dann Child-Komponenten. Schauen wir uns gerade an. Wichtig ist hier vielleicht nur der Selektor, der dann natürlich später in der Parent-Komponente verwendet werden soll. Die Parent-Komponente könnte so aussehen,
wir würden die Talk-Komponente der einzelnen Talks importieren und dann im Template eben den Selektor der Child-Komponente verwenden. In dem Fall würde sie einfach nur einen Talk anzeigen und nicht alle, aber ihr seht im Template wird eben der Selektor Talk-Komponent der Child-Komponente verwendet.
Wichtig ist, dass wir die Talk-Komponent auch noch danach als Direktive, als Metadatum in den Decorator schreiben. Ich trinke noch mal einen kurzen Schluck.
Wie läuft es jetzt ab mit den Daten? Was ist, wenn wir Daten aus der Komponente in der View verwenden wollen oder umgekehrt? Dafür ist das Data Binding zuständig. In der Doku steht, Data Binding ist ein Mechanismus, für das Koordinieren, was die User sehen, mit Applikationen und Datenwerte. Der Fall wäre also dieser,
wir haben Daten in der Komponente im Model und wollen die in der View anzeigen. Dafür gibt es erstmal in der ersten Zeile die Interpolation mit den zwei geschleiften Klemmen und darunter Property Bindings. Was wir verwenden ist eigentlich egal,
denn intern werden die Interpolations eben genau in Property Bindings umgewandelt. Wer sich jetzt wundert über die komische Suntags mit den eckigen Klammern, laut Speck ist das auf jeden Fall auch noch valides HTML. Das heißt, Attribute dürfen mit eckigen Klammern beginnen.
Und Angular wandelt das dann in Dom-Node-Properties um intern. Das heißt, wir können hier sozusagen mit dem Property Binding Text-Content direkt auf das HTML-Node-Property-Text-Content zugreifen und dadurch eben den Inhalt verändern, dynamisch.
Es gibt noch spezielle Property Bindings, um auch Dinge zu verändern, die nicht Node-Properties sind, nämlich für Attribute, Klassen und Styles. Die Suntags würde dann so aussehen.
Genau, und jetzt sehen wir hier schon, um von der Komponente zur View Data Binding zu erlauben, gibt es eben diese beiden Interpolation- und Property Bindings. Wie ist das jetzt umgekehrt der Fall, um Daten aus der View in der Komponente zu verwenden,
gibt es die Event Bindings. Das macht Sinn, weil wir meistens Daten im Model verändern wollen, wenn was auf der View kommt, nachdem irgendwas in der View passiert ist, also ein Klick auf den Button, um damit was zu löschen, oder ein Input-Element, da wurde was reingeschrieben.
Dafür gibt es dann Event Bindings. Die Suntags ist recht einfach. In runden Klammern steht der Event-Name. Das kann ein natives Event sein, wie hier das Klick-Event, oder auch ein Event, das wir selbst geschrieben haben.
In dem Fall würde die Talk-Komponente, sobald das Talk-Deleted-Event gefeuert wird, eben die Delete-Talk-Function aufrufen. In beide Richtungen, One Way Data Binding, also vorgestellt, es gibt auch noch das Data Binding über NG-Model,
das in beide Richtungen fließen kann, nämlich das Two Way Data Binding. Ein einfaches Beispiel sehen wir hier. Das geht über die NG-Model-Syntax mit den runden und den eckigen Klammern. Was würde hier passieren?
Das heißt, sobald ein User etwas in das Input-Element eingibt, würde das Model verändert und dadurch auch unten im Paragraph-Tag der angezeigte String geändert werden. Viele geben da als Eselsbrücke für die Suntags
irgendwie Banana-in-a-Box an, so zwei Runde in eckigen. Ich glaube, man kann sich das auch so merken, vor allem, wenn man weiß, woher es kommt. Denn einmal binden wir das Model über ein Property-Binding an die View und umgekehrt sagen wir, höre bitte auf Änderungen.
Sobald sich etwas ändert, ändere auch das Model. Und auf diese Art entsteht das Two Way Data Binding. Bleiben wir mal kurz noch bei Templates. Und der Template-Syntax. Templates display data and consume user events with the help of data binding. Das steht in der Doku. Das haben wir eben gesehen.
Ein paar weitere wichtige Punkte von der Templates Syntax wären die eingebauten Direktiven. Da gibt es ng-style, ng-class, ng-for, ng-if und ng-switch. Ich beginne mal mit ng-style. Wir hatten ja vorhin schon gesehen, dass wir mit Property-Bindings auch Styles verändern können.
Es gibt aber alternativ dazu noch eine Direktive ng-style. Die hat den Vorteil, dass wir mehrere Styles auf einmal verändern können oder auch zum Beispiel Funktionen aufrufen können, die sich dann um die neuen Styles kümmern. Dasselbe ist bei der ng-class-Direktive.
Wir könnten eine Klasse auch über ein Property-Binding ändern. Wir können aber auch die Direktive benutzen und so direkt mehrere Klassen ändern. Vielleicht auch über eine Funktion. Ich würde sagen, da hält man sich dann an seine Code-Conventions,
die man einmal festgelegt hat. Die letzten drei Direktiven, ng-for, ng-if und ng-switch, sind Structural Directives. Die beginnen alle mit einem Sternchen, asterisk. ng-for ist als erste Structural Directive.
Nach dem Ist-Gleichzeichen kommt eine Art Micro-Syntax. In dem Falle let talk of talks. Das bedeutet hier, schau dir einmal das Array talks an.
Speiche für jedes Item in dem Array das Item in einer lokalen Variable talk und verwende das dann in dem Paragraph-Tag. Das heißt also, für jeden Talk innerhalb des Talks Arrays würde hier ein Paragraph erstellt werden.
Wir können innerhalb des Paragraph-Tags auf die Values von dem Talk-Element zugreifen. Das funktioniert natürlich auch mit Custom-Elements, die wir benutzen können. Und wir können auf den Index zugreifen, was natürlich praktisch ist.
Als nächstes ng-if. Das Element wird dann gerendert, wenn die Expression hinter dem Ist-Gleichzeichen wahr ist. Das heißt, wenn die nicht wahr ist, wird das Element auch komplett aus dem DOM-Tree entfernt. Es ist also ein Unterschied, ob ich mit ng-style irgendwie was ausblende oder einblende.
Das Element ist immer noch im DOM. Oder wenn ich mit ng-if das Element einen ausblende, dann wird es tatsächlich aus dem DOM-Tree entfernt. Als letztes ng-switch. Ich glaube, wir können uns alle was darunter vorstellen,
die JavaScript schreiben. Hier wird genau das Element gerendert, mit dem die Expression wahr wird. Falls es keins gibt, wird in dem Fall das letzte Element gerendert, das ng-switch-default-element.
Und ganz zum Schluss ein letzter Teil nach den Direktiven. Wir können außerdem in Templates auch noch auf lokale Variablen erstellen und dann darauf zugreifen, das gestiet mit dem Hash. Hier legen wir für das Input-Element
die Talk-Variable an und können darunter auf diese Talk-Variable und damit auch auf den Value vom Input-Element zugreifen. Ich habe jetzt eigentlich das meiste schon zu Components und der Template Syntax gesagt. Unsere Apps bestehen natürlich nicht nur
aus Components oder View-Controllern und Views. Bestenfalls, wer die alle wissen, lagert man vielleicht Rechenoperationen, die in vielen View-Controllern vorkommen, in Services aus. Angular schreibt in der Doku
a Service is typically a class with a narrow, well-defined purpose. Das sagt damit auch schon alles, denn es gibt eigentlich keine Services in Angular. Es gibt Klassen, aber es gibt jetzt keine Service-Superklasse, von der alle Services erben. Wir haben also einfach nur Klassen.
Ein beliebtes Beispiel ist vielleicht eine Klasse, ein Service, der sich um das Holen von Daten und das Verwalten von Daten kümmert. Das heißt, unsere Talk-Komponenten würden sich nicht selber darum kümmern, die Daten zu holen, sondern sie würden sich an einen Service wenden,
der ihnen die Daten gibt, und in dem Service wird vielleicht entschieden, ach, hole ich die Daten jetzt gerade über HTTP übers Web, oder hole ich sie vielleicht aus dem Local Storage und übergebe sie so weiter. Diese Talk-Service muss natürlich dann von Komponenten verwendet werden.
Das heißt, wir brauchen irgendwie einen Mechanismus, um die Klassen in Komponenten zu verwenden. Bestenfalls dieselbe Instanz, und dafür gibt es die Dependency Injection.
Dependency Injection ist eigentlich ein Design-Pattern, gar nicht ein Feature eines speziellen Frameworks. Und das Design-Pattern, nach dem wir entwickeln, das besagt eigentlich nur, Module kümmert euch nicht selbst an eure Dependencies, sondern lasst das Framework das machen.
Das heißt also, das Framework guckt, welche Komponenten, welche Module haben welche Abhängigkeiten, und kümmert sich dann selbst darum, dass diesen Komponenten die Instanz der Dependencies gegeben wird. In dem Fall macht das Angular auch so.
Wir haben unsere Enter.js-App-Komponent und die möchte jetzt auf den Talk Service zugreifen. Bevor die Komponent von Angular erstellt wird, schaut der Injector sich die Komponent an
und sieht dann, aha, sie möchte gerne den Talk Service verwenden. Ich habe hier schon eine Instanz des Talk Service und diese wird dann übergeben. Wenn es noch keine im Injector gäbe, würde der eine erstellen und dann die Instanz des Talk Service zur Verfügung stellen und vielleicht anderen Komponenten,
die auch später den Talk Service nutzen wollen. Im Code könnte das so aussehen. Wir importieren oben erst einmal das Modul, den Talk Service, und müssen dann noch ein Metadatum festlegen, dass dieser Talk Service auch eine Instanz des Talk Service
auch hier uns gegeben werden soll über die Provider-Eigenschaft und danach können wir im Konstruktor auf diese Klasse, diesen Service hier verweisen und danach darauf zugreifen. Das Ganze funktioniert
auch hierarchisch, das heißt, wir haben das eben in unsere Parent-Komponent injected den Service, der Service würde danach auch unseren Child-Komponenten zur Verfügung stellen und würden wir vielleicht beim Bootstrappen einen Service ganz oben in die Root-Komponenten injecten, würde diese Instanz, diese Service-Instanz der ganzen App zur Verfügung
stehen. Nicht nur Komponenten können natürlich Dependencies haben, sondern auch Services selbst, also einfache Klassen. Das geht eigentlich genauso, wie wir hier sehen, außer, dass unsere Klassen, da sie ja keine Komponenten sind, auch keinen Decorator,
keinen Component-Decorator haben und wir dadurch nicht die Provider- Eigenschaft festlegen können. Deswegen gibt es hier den Decorator-Injectable und der sagt sozusagen, Angela, nur Achtung, diese Klasse hat selbst noch Dependencies. Mehr ist da nicht der
Fall. So, ich glaube, ich bin sogar relativ schnell. Spreche ich euch zu schnell? Müsst ihr vielleicht mal so machen. Wir sind hier nämlich schon nach Komponenten Data Binding, Template Syntax, Services und Dependency Injection bleiben uns erstmal die Pipes.
Jetzt kann ich ja kurz eine Umfrage machen. Wer kennt die Filter noch in AngularJS? Genau, das sind die Pipes. Pipes transform displayed values within the template. Ein paar wenige, glaube ich, gibt es nicht mehr. Ein paar neue sind hinzugekommen.
Vieles wird euch dann jetzt bekannt vorkommen. Ich beginne mal mit zwei sehr, sehr einfachen Pipes, der uppercase und der lowercase-Pipe. Da kann sich jeder denken, was da passiert. Unten steht immer, wie das gerendert dann aussehen würde in dem Comment,
nämlich einmal eben ein String in uppercases und einmal in lowercases umgewandelt. Wir haben eine DatePipe. Die funktioniert, indem wir ein Muster angeben oder auch ein Keyword, wie wir hier sehen. Das können wir für Teile aus einem Datenobjekt
machen wie das Datum, aber natürlich auch für andere Teile aus einem Datumsobjekt wie der Zeit. Hier werden also einfache Datumsobjekte einfach in einen String umgewandelt, der formatiert ist. Wie ihr vielleicht seht, es kommt hier wenig drauf an,
wie das Muster angeordnet ist, also Punkte oder Striche oder auch die Reihenfolge spielt eigentlich gar keine Rolle, sondern was gerendert rauskommt, kommt auf den Local des Users an. Das heißt, wenn ich hier oben diese drei Varianten
würde alle in Deutschland zu Punkten zwischen den Tagen und Monaten führen und in US-amerikanischen Browsern, also zu den Slashes und der korrekten Darstellung. Wir haben außerdem eine Currency und eine PercentPipe, mit der wir Geldbeträge und
Prozentwerte formatieren können. Es gibt eine NumberPipe, mit der Zahlen formatiert werden können, also zum Beispiel Dezimalstellen angehängt, oder auch eine SlicePipe, mit der wir Erase oder Jason, Entschuldigung, mit der wir Erase oder Strings slicesen können.
Und ganz unten sehen wir schon den Fall im letzten Beispiel, wir können diese Pipes auch hintereinander ketten, Chaining. Die JasonPipe ist neu, die gab es bisher nicht. Für die Produktion brauchen wir die wahrscheinlich nicht so oft, aber vielleicht zum Debugging, wir können nämlich Jason
als String ausgeben. Hier in dem Fall unten, vielleicht macht das manchmal Sinn, wir slicesen ein Jason-Objekt und geben uns den ersten Teil irgendwie aus und sehen eben nicht mehr nur Object Object zum Debuggen. Und eine letzte neue Pipe haben wir hier, die AsyncPipe,
die ist dafür ausgebildet, um Werte anzuzeigen im Template, die asynchron nachgeladen werden. Das funktioniert im Hintergrund so, dass wir die Pipes einem Promise oder einem Observable subscribt, das können wir uns aussuchen,
und solange wie das Observable oder das Promise nicht aufgelöst werden, gibt es hier einen leeren String zurück und wenn es dann aufgelöst wird, wird der Wert eben zurückgegeben, der da kommt und eine Change Detection ausgelöst. Das heißt, in der View werden die Daten neu angezeigt.
Auf die Change Detection gehe ich ganz gleich nochmal ganz kurz ein. Als letztes nur um die Pipes zu vervollständigen. Wir können Custom Pipes schreiben. Ich habe letztens nach der Syntax gegoogelt und seitdem mag ich den Namen Custom Pipes, weil ich habe hier diese Custom Pipe gefunden. Es gab ganz tolle Custom Pipes.
Hier ist die Unicorn Custom Pipe. Naja, das musste irgendwie rein. Genau, Custom Pipes machen wir mit dem Pipe Decorator. Da können wir den Namen der Pipe festlegen und eben in der Transform Method dann sagen, wie wir den Input formatieren
und ausgeben möchten. In dem Fall wird eben abgeschnitten der String, der da hinterlegt wird, und dann mit drei Punkten danach angezeigt. Also wir können Text kürzen mit drei Punkten. Das ist hier das Pipe Beispiel. Jetzt nochmal ganz kurz zur Change Detection.
Da gibt es auch später noch einen Talk dazu. Deswegen will ich da eigentlich gar nichts wirklich dazu sagen, mir selbst den Talk anhören. Angular looks for changes to data bound values through a Change Detection process that runs after every Javascript event. Nur kurz als Info, der Change Detection Prozess,
der wurde auch komplett geändert und beruht jetzt, keine Ahnung wieso das immer passiert. Wo ist Keynote? Der Change Detection Prozess wurde nochmal neu geändert, beruht jetzt auf Zones. Später erfahrt ihr auf jeden Fall dazu mehr, wenn ihr euch den Vortrag
anschaut. Ich glaube heute Abend auf jeden Fall ist die neue Change Detection wohl einer der Hauptgründe dafür, dass Angular 2 sehr, sehr viel schneller nochmal ist im Rendering als Angular 1. Was wir alle eigentlich gehofft hatten. Noch ein paar Kleinigkeiten, auch ohne
Code Beispiele, nur damit der Überblick vollständig ist. Angular war ja schon immer gut mit Forms. Angular Form coordinates a set of data and user controls validates inputs and presents errors. Für Forms stehen uns mit Angular 2 mehrere Varianten zur Verfügung, wie wir sie erstellen
können. Nämlich einerseits wie früher, wo sehr, sehr viel im Template geschieht, im Markup geschieht, die Validierung hauptsächlich im Markup geschieht und wir können andererseits model driven Forms schreiben. Das heißt, die Validierung geschieht eher im Model, wird vom Template
losgelöst und ist dadurch vielleicht auch ein bisschen besser testbar. Man kann diese zwei Konzepte auch mischen. Das muss man sich vielleicht einfach dann anschauen, wie es für das jenige Projekt am besten ist. Und als letzten Punkt nochmal hier auf die Styles
eingegangen. Angular has the ability to bundle component styles with components enabling a more modular design than regular style sheets. Ich habe ja vorhin schon mal über Web Components gesprochen kurz. Wer weiß, was Web Components sind? Doch, recht viele.
Die anderen müssen es vielleicht googeln, weil ganz ausführlich kann ich es nicht erzählen. Wir haben allerdings in Angular die Möglichkeit, den Output verschieden zu gestalten. Wir können einerseits, das nennt sich View Encapsulation, wir können die nativ wählen und was
rauskommt sind native Web Components. Das heißt, unser Code, der danach entsteht, unsere einzelnen Komponenten, sind wirklich Web Components. Ist vielleicht nicht allzu geschickt, das heute zu verwenden, weil die werden eben noch nicht überall unterstützt in jedem Browser. Der Default ist deswegen emulated.
Das heißt, Web Components werden eben emuliert. Es wird so getan, als wäre es eine Web Component und das wirkt sich eben auf die Styles aus, in beiden Fällen. Denn in beiden Fällen werden die Styles so gescoped, dass sie eben nur in dieser Komponente wirklich zum Einsatz kommen. Wir können also
eine Imageklasse verwenden und die stylen und eben, weiß nicht, was es ist. Ich war bei der Imageklasse voll laut. Wir können eine Imageklasse einfach so vergeben, ohne die jetzt wirklich so elend
lang zu machen und die in dieselbe Imageklasse, denselben Selektor in einer anderen Komponente auch einsetzen und es würde nicht überschrieben werden. Der letzte View Encapsulation Modus Non. Da passiert es eben nicht. Da geschieht einfach gar nicht. Das CSS wird so ausgespuckt, wie
wir es in der Komponente hinterlegt haben. Ich habe noch eine Folie, da will ich gar nicht so viel mehr dazu sagen. Um diesen Plattformgedanken komplett zu machen.
Es wird immer lauter. Wir haben, wie früher, auch innerhalb des Angular Frameworks nützliche Module, zum Beispiel das HTTP-Modul, das Router-Modul, auf die wir zugreifen können. Wie ich vorhin auch schon gesagt habe, Unit-Tests mit Jasmine und
Karma und End-to-End-Tests mit Protector. Das war eigentlich mein grober Überblick. Wenn ihr Fragen habt, sprecht mich an. Ich bin, glaube ich, bis morgen auf jeden Fall im Laufe des Vormittags noch da und heute auch den ganzen Tag. Oder schreibt mir, falls ihr die Slides
haben wollt. Ich habe, glaube ich, eine Kleinigkeit noch mal aktualisiert zu denen, die auf dem Server liegen. Das können wir aber auch gleich austauschen. Ich habe einen Newsletter, der einmal in der Woche rauskommt, den ich vielleicht heute auch noch machen muss, über Angular 2. Wenn ihr wollt, könnt ihr da abonnieren.
Ich schicke so interessante Artikel der letzten Woche oder Videos und so raus. Genau. Das war's.