Archiv der Kategorie: Angular 2

Webpack 2 Parameterübergabe and den Buildprozess auf der Konsole


Die meisten Beispiele für Webpack enthalten fertige Konfigurationen die als npm scripte hinterlegt sind. Wenn man aber einen automatisierten Build Prozess verwendet z.B. über den TFS, dann möchte man evtl. einige Variablen von außen an den Buildprozess übergeben. Dazu könnte z.B. die “baseUrl” gehören, wenn die Anwendung nicht im Root des Webserver gehostet wird.

Wenn man z.B. angular-starter installiert und man an den Befehle für “build:prod” noch den Namen der Anwendung übergeben möchte, damit dieser als “baseUrl” gesetzt wird, dann sind dafür die folgenden Schritte notwendig.

Anpassen der package.json, hier müssen zwei “- -“ (doppeldashes) entfernt werden, da sonst die Übergabeparameter nicht gesetzt/erkannt werden.

Vorher:

„build:prod“: „npm run clean:dist && npm run webpack — –config config/webpack.prod.js –progress –profile –bail“,

Nachher:

„build:prod“: „npm run clean:dist && npm run webpack –config config/webpack.prod.js –progress –profile –bail“,

Dann passen wir die “webpack.prod.js” an und prüfen ob der “appname” übergeben wurde und erweitern bei Bedarf die “environment” Variable um den Appnamen

Dann wird noch die “webpack.common.js” angepasst und wenn der “appname” gesetzt ist, ersetzen wir die “baseUrl”

jetzt können wir die passende Kommandozeile aufrufen und den passenden “appnamen” übergeben

npm run build:prod — –env.appname „meineAnwendung“

hier können wir jetzt beliebig viele Parameter übergeben z.B.

npm run build:prod — –env.appname „meineAnwendung“ –env.test “../testFolder”

Wenn wir den Befehl ausführen, dann kann man in der Konsole auch unser “console.log” sehen und man sieht das webpack hier ein JSON Objekt erstellt auf das wir entsprechend in der “webpack.prod.js” über die “env” Variable zugreifen können.  Damit lassen sich beliebige Informationen von außen über eine Buildumgebung noch an webpack übergeben.

Http “Interception” in Angular 2


Wenn man in Angular 1 Requests und Responses verändern will, ist dies sehr einfach mit der Hilfe von Interceptoren lösbar. Ich habe hier einige benutzerdefinierte Interceptoren erstellt die einem das Leben schon sehr einfach machen konnten. Wenn es darum ging den IE vom Caching der Ajax Requests abzuhalten oder um zu zählen wie viele offene Requests aktuell noch vorhanden sind um einen kleinen Spinner anzuzeigen, das gerade noch etwas geladen wird, …

Leider ist dies in Angular 2 nicht mehr so einfach möglich, oder sagen wir mal so es ist etwas umständlicher möglich, denn leider bietet Angular 2 aktuell keinen so komfortablen weg, wie ihn Angular 1 geboten hat.

In Angular 2 müssen wir dafür die Http Klasse “erweitern”. Damit wir die Benutzerdefinierte Implementierung unserer Http Klasse auch in anderen Projekten verwenden können ohne diese jedes mal selbst anzupassen, verwende ich noch rxjs Subjects, damit kann man die spezielle Implementierung unserer Lösungen an anderer Stelle aufrufen (Subscriben). Die Implementierung kann hier z.B. folgendermaßen aussehen:

In der CustomHttp Klasse findet keine direkte Implementierung statt, sondern es wird ein Service Injected der selbst rxjs Subjects für “jedes” Problem bereitstellt, was ich in meinen Webseiten kenne und für das ich teilweise andere Lösungen bereitstelle, wie z.B. was mache ich wenn ein Serverfehler auftritt. Ich habe hier aktuell nur die “No-Cache” Header fest eingebunden, da ich diese immer benötige. Sonst ruft man hier nur die passenden Service Funktionen auf und diese triggern dann das rxjs Subject, welches an anderer Stelle abonniert werden kann.

Der “httpSubjectService” kann dann z.B. in der “app.component” (Root Komponente) eingebunden werden und man subscribed das jeweils passende Subject und kann die passende Implementierungen dann entsprechend aufrufen.

Damit aber die CustomHttp Erweiterung überhaupt geladen werden kann muss die benutzerdefinierte Implementierung registriert werden im Dependency Injector (sehr gute Hilfe die erklärt wie die Dependency Injection in Angular 2 funktioniert) von Angular 2 und man überschreibt damit die Standardimplementierung von Http mit der CustomHttp Implementierung.

Natürlich darf man nicht vergessen das “CustomHttpCoreModule” im “app.module” zu registrieren.

Ein komplettes Beispiel auf meinem Github Account.

File Nesting Addon für Visual Studio und Angular


Wenn man sich an den offiziellen Guide oder die Angular CLI hält, dann wird es sehr schnell sehr unübersichtlich in den einzelnen Verzeichnissen für eine Angular Anwendung. Denn zu den meisten TypeScript Dateien gibt es noch die passende HTML, Style oder Testdatei. Schon bei einfachen Verzeichnissen kann das ganze im Explorer bereits folgendermaßen aussehen.

image

Oft muss man aber nur die TypeScript Datei anpassen und benötigt die Styles oder Templates gar nicht. Damit man nicht so schnell den Überblick verliert und man besser erkennt welche Dateien zusammengehören, hilft einem das File Nesting Addon für Visual Studio. Denn die oben gezeigten Dateien sehen dann in VS folgendermaßen aus

image

und wenn das ganze dann aufgeklappt ist, sieht man auch die zugehörigen Template Dateien und Styles falls vorhanden.

image

image

Leider ging Autonesting bei mir in VS 2015 Update 3 nicht und ich muss die jeweiligen Dateien selbst auswählen. Dafür wählt man z.B. einfach seine HTML und less Datei aus und mit einem Rechtsklick steht einem im Menü dann “File Nesting” => “Nest Item…”  zur Verfügung.

image

Dann geht ein kleines Modal auf in dem man das Root Element auswählen kann, in meinem Fall ist es immer die zugehörige TypeScript Datei gewesen, das wiederholt man für alle Dateien die man nesten möchte und schon hat man wieder Ordnung in seinen Ordnern.

image

Angular 2 mit webpack 2 mit ts, less, sass Loader für Anfänger in Visual Studio 2015 (Webpack Version – Beta 27)


Wäre die Welt nicht schön, wenn man sich nur mit Angular 2 beschäftigen könnte und nicht noch über das Deployment für den Live Betrieb nachdenken muss. Denn dann wäre die Standardinstallation von Angular 2 mit SystemJs völlig ausreichend. Wenn man allerdings seine erste kleine Angular 2 Anwendung erstellt hat, dann merkt man schnell das man sich noch mit dem Live Deployment beschäftigen muss. Denn wenn man die Anwendung startet dann dauert es bis zu 300++ Requests bevor die Seite komplett geladen ist und das ist nicht für Live geeignet.

Da ich bisher nur Angular 1 Seiten mit ASP.NET MVC umgesetzt habe, hatte ich bisher auch nicht viel Kontakt mit “import” Statements, gulp, grunt, webpack oder SystemJs – denn das hat bei Angular 1 alles Visual Studio für mich übernommen.

Jetzt stellte sich mir die Frage warum und weshalb brauche ich diesen neumodischen Kram eigentlich?

Bei Angular 2 kann ich hier leider nicht mehr auf Visual Studio zurückgreifen. Denn bei einer Umsetzung z.B. mit webpack muss klar unterscheiden zwischen dem Ordner “App” in dem wir die Anwendung schreiben (unsere TypeScript Dateien und HTML Templates liegen) und einem Ordner “wwwroot” in dem die “kompilierte” Anwendung (JavaScript Dateien) abgelegt wird, wenn diese fertig kompiliert wurde. Der Webserver ruft dann die “index.html” aus dem “wwwroot” Ordner auf.

Aber wie kompiliert man aus TypeScript Dateien, Less, Sass und HTML Templates eine richtige JavaScript Anwendung?

Mit SystemJs

Im Standardbeispiel von Angular 2 ist dies einfach gelöst, es gibt zum einen das direkte Übersetzen der TypeScript Dateien in JavaScript beim Speichern und SystemJs kümmert sich dann mit Hilfe der “systemjs.config.js” das alle passenden Dateien zur Laufzeit ausliefert werden und die Styles sind im besten Fall direkt auf der Seite eingebunden (300+ Requests).

Daher muss man sich um ein passendes “Bundling” der Dateien kümmern und dafür gibt es mehrere Möglichkeiten. Zum einen kann man gulp und grunt verwenden und die passenden Deployscripte schreiben oder man verwendet npm Scripts mit webpack 2 und schreibt dafür die Deployscripte. Ich habe mich für die zweite Variante entschieden, da es sich dabei aktuell wohl um die bevorzugte Variante zum Bereitstellen von Angular 2 handelt und da es auf der Angular 2 Seite zumindest ein Beispiel für die Umsetzung mit webpack 1 gibt. Ich beziehe mich aber im meinem Blogpost auf die aktuelle Variante webpack Beta 27.

Hinweis zu “npm Scripts”: In der “package.json” in der alle abhängigen npm Pakete für das Projekt angegeben sind, gibt es auch noch die Möglichkeit Kommandozeilen Befehle für npm abzulegen die mit “npm run <scriptname>” ausgeführt werden können, im folgenden Beispiel z.B. “npm run start” wird das “start” Script ausgeführt.

Mit webpack

Also was macht webpack eigentlich und wie funktioniert das ganze dann?

Wenn man webpack verwendet, gibt es wie schon beschrieben ein Verzeichnis in dem man seinen Quellcode hat z.B. “App” hier liegen alle TypeScript Dateien und HTML Templates. Auch unsere “index.html” in dieser sind weder styles noch script Tags enthalten, all das fügt webpack später beim Buildprozess automatisch in die “index.html” ein.

image

Und dann gibt es noch ein Verzeichnis für die Kompilierten Dateien  z.B. “wwwroot” hier liegen dann alle übersetzten und zusammengefassten JavaScript Dateien und Styles – der Ordner wird NICHT mit in die Quellcodeverwaltung eingecheckt.

image

Webpack kümmert sich dann um “alles” d.h. aufgrund der “import” Anweisungen in unseren Dateien weiß webpack genau welche Dateien wir alle benötigen und welche in einer Datei zusammengefasst werden sollen.

Webpack im “Detail”

Für die Implementierung von Angular 2 mit webpack 2 gibt es ein sehr gutes Github repository an dem ich mich orientiert habe. Im Folgenden gehe ich daher nicht auf alle Details ein, sondern beschreibe eher die Probleme auf die ich gestoßen bin. Diese könnt Ihr z.B. oft in den Kommentaren der Quellcode Dateien nachlesen.

Für Visual Studio gibt es eine sehr gute Task Runner Extension für webpack, mit dieser kann man die webpack Tasks direkt in Visual Studio starten vom einfachen Build bis hin zum Webpackserver (dazu weiter unten mehr) und man muss nicht immer eine npm Konsole öffnen.

Allgemeine “App” Einstellungen

Damit nicht der komplette JavaScript Code in einer Datei landet, splittet man diese am besten auf:

  • polyfills.ts – damit die Anwendung auch in älteren Browsern funktioniert muss auch als erstes im Browser geladen werden
  • vendors.ts – Angular Framework und abhängige Komponenten
  • boot.ts – der Root unserer Anwendung

Ich verwende z.B. noch Twitter Bootstrap als globalen Style mit Less und evtl. noch andere Styles z.B. in Sass oder css direkt. Auch die Styles sollen von webpack übersetzt, minifiziert und in der “index.html” automatisch eingebunden werden.

Denn webpack bindet “NUR” die Dateien in den Build Prozess ein, die auch über ein “import” Statement in einer der Dateien polyfills, venders oder boot eingebunden sind oder von diesen mit “import” eingebunden werden.

Damit meine Bootstrap Styles global verfügbar sind habe ich mich für das Einbinden von bootstrap in die vendors entschieden.

Denn wenn man die Styles direkt in einer Komponente als “styleUrls” einbindet, sind diese durch Angular 2, in den Standardeinstellungen nur in der eingebundenen Komponente gültig – ViewEncapsulation.

Ausnahmen für das Einbinden nicht direkt über “import” bilden die “templateUrl” und die “styleUrls”, diese werden von den webpack Loadern erkannt und dann entsprechend geladen.

Webpack Bereitstellungsmöglichkeiten

Die Task Runner Extension für die webpack Bereitstellung in Visual Studio, kann mit einem Rechtklick auf die “webpack.config.js” mit “Taskausführungs-Explorer” geöffnet werden.

image

Es gibt verschiedene Möglichkeiten, wie man die Dateien für den “wwwroot” Ordner von webpack erstellen lassen kann.

  • Manuell, sobald man eine Änderung durchgeführt hat und diese ausprobieren möchte, kann man einfach unter “Run” sein Projekt für die passende Umgebung neu bauen lassen

image

und die Ausgabe könnte dann folgendermaßen aussehen

image

  • Oder man kann einen Watcher ausführen lassen, der das Webverzeichnis der aktuellen Anwendung überwacht und sobald Änderungen an Dateien vorgenommen wurde, wird das Paket automatisch neu gebaut, hier muss dann nur noch mit F5 der Browser aktualisiert werden um die neuen Änderungen auch zu sehen
  • Dann gibt es noch einen einfachen node.js express Webserver der die aktualisierten Dateien bereitstellen kann. Hier gibt es zwei unterschiedliche Modus um die Seite zu aktualisieren.
  • COLD – die Seite wird automatisch komplett neu geladen (wie in meinem Beispiel)
    • HOT – es werden nur die Teile ersetzt die sich geändert haben (HOT wird auch HMR genannt und steht für “Hot Module Replacement”)

Die “webpack.config.js”

Wenn man webpack einsetzt, dann muss SystemJs komplett aus dem Projekt entfernt werden, denn webpack übernimmt dann das Bereitstellen von Development Paketen und den Live (Production) Paketen.

Damit die Visual Studio Extension für webpack auch funktioniert, muss die Datei “webpack.config.js” im Root Verzeichnis der Webseite abgelegt werden.

Da es unterschiedliche Konfigurationen gibt, für Allgemeine Einstellungen, Produktionseinstellungen, Liveeinstellungen und Testeinstellungen wird die Konfiguration in mehrere Dateien aufgeteilt und in meinem Beispiel im Verzeichnis “Config” abgelegt. In der “web.config.js” wird nur ausgewertet welcher Wert als NODE_ENV übergeben wurde über den Aufruf des Kommandozeilenbefehls z.B. für development über den Webpack Taskplaner

cmd /c SET NODE_ENV=development&& webpack -d –color

und es wird dann die passende “webpack.dev.js” Datei aufgerufen.

Die jeweilige webpack Konfiguration, setzt sich dabei aus zwei Dateien zusammen, einer Datei die speziell für die jeweils aufgerufene Umgebung z.B. development (dev) => “webpack.dev.js” die Werte enthält und einer allgemeinen Konfiguration “webpack.common.js”, die für alle Bereitstellungsszenarien immer die gleichen Werte beinhaltet. Diese beiden Konfigurationsdateien werden dann mit Hilfe einer JavaScript Bibliothek von Webpack “webpackMerge” zusammengeführt.

Die “webpack.common.js”

In der Konfiguration wird angegeben welche Startdateien es gibt, in unserem Falle drei “polyfills”, “vendors” und “boot”. Dann gibt es die “module” Sektion in denen die Loader verwendet werden, die wir auch in der package.json entsprechend in den dev-dependencies angeben müssen. Da sich webpack 2 aktuell noch in einer Beta befindet, hatte ich auch entsprechende Probleme die Loader für Less und Sass zum Laufen zu bekommen (siehe Kommentar über dem jeweiligen Loader).

ACTHUNG: Bei den Style Loadern gibt es jeweils einen Loader für die „StyleUrls“ in den Componenten und dann gibt es noch einen Loader für die globalen Styles die direkt per „import“ eingebunden werden, denn beide brauchen unterschiedliche Loader. Bei den jeweiligen Loadern sind die Verzeichnise für die diese zuständig sind per „include“ und „exclude“ festgelegt.

Um die HTML Dateien kümmert sich der “angular2-template-loader” wichtig ist das diese in der “templateUrl” in der Component mit einem relativen Pfad angegeben werden und mit einem “./” starten wie z.B. “./app.component.html”. Was bedeutet die HTML Datei befindet sich im gleichen Verzeichnis wie die Komponente. Gleiches gilt für die “styleUrls”.

ACHTUNG: KEINE ES6 Anführungszeichen verwenden bei den URL Angaben, hier wird dann einfach nur der String ausgeben “./app.component.html” und NICHT das HTML Template.

Wenn ich das ganze richtig verstanden habe, dann kümmert sich der “raw-loader” um die HTML Dateien die der “angular2-template-loader” entsprechend “bereitgestellt” hat.

HINWEIS: Die HTML Dateien die in der Component angegeben werden, werden mit in die bereitgestellten JavaScript Dateien von webpack eingebettet und es gibt keine Extra Dateien dafür im Ausgabeordner. Die Styles werden dank des „ExtractTextPlugin“ in einer Extra Datei abgelegt.

Dann gibt es noch die Plugins, welche teilweise direkt von webpack bereitgestellt werden oder extra in den dev-dependencies mit angegeben werden.

Die Plugins kümmern sich z.B. darum das in der “index.html” auch die richtigen Scripte, Styles und base Url eingebunden werden (HtmlWebpackPlugin und ExtractTextPlugin). Denn im Produktionsmodus wird noch ein Hash mit an den Dateinamen der jeweiligen JavaScript oder Style Datei angefügt, damit nicht ausversehen alte Daten geladen werden. Aus diesem Grund können wir auch nicht direkt die Styles und Scripte in unserer “index.html” verlinken, sondern müssen diese von webpack einfügen lassen.

HINWEIS: Ich habe mich aktuell dazu entschieden bei den DevDependencies immer nur noch die Direkte Version zu verwenden ohne „^“ oder „~“ vor der Versionsnummer, denn wenn Ihr pech habt wie ich, dann wird z.B. TypeScript von Version 2.0.10 auf 2.1.14 angehoben und plötzlich funktioniert das Deployment nicht mehr da es Probleme mit dem „awesome-typescript-loader“ gibt. Vor allem sucht man den Fehler erst einmal bei sich selbst, bevor man daran denkt das node evtl. eine neuere Version gezogen haben könnte die nicht vollständig kompatibel zu allen anderen Paketen ist.

Die “webpack.dev.js”

Die speziellen dev Einstellungen für unsere Anwendung.

Wichtig ist hier z.B. der Wert für “output.publicPath”, denn der hier angegebene Wert wird als Basispfad vor alle Script und Style Tags in der “index.html” eingefügt. (siehe Kommentare in der beigefügten dev Konfiguration)

Daraus ergibt sich dann z.B. die folgende “wwwroot\index.html” wenn das ganze erfolgreich kompiliert wurde.

Hier kann man gut erkennen, das wir aktuell die Daten vom webpack Server holen, der auf Port 3000 lauscht, auch das können wir entsprechend in der “webpack.dev.js” einstellen.

Webpack Zusammenspiel mit Visual Studio

Ich habe zwar aktuell keine Backend Funktionen in .NET implementiert, aber Visual Studio dient aktuell nur noch als Backend um z.B. Daten aus der .NET Welt im Browser anzuzeigen. Im Development Modus laufen am Ende zwei Webserver. Einer im IIS der unsere Anwendung hostet und die “index.html” aus dem wwwroot aufruft und der webpack webserver der die aktuellen Scripte und Styles bereitstellt.

Im Zusammenspiel mit der folgenden RouteConfig

und dem einfachen HomeController für den Index Aufruf.

Wird kein “Views” Ordner mehr benötigt.

Beispiel “installieren”

  1. Webpack Taskrunner Extension für VS 2015 installieren und VS neustarten
  2. Das Projekt von GitHub laden und in VS 2015 öffnen (Achtung hier sind noch mehr Projekte enthalten, bitte darauf achten, das diese nicht mit gebaut werden sondern nur “Angular2MitWebpack2”.
  3. das Verzeichnis mit einer NPM Konsole öffnen und mit Hilfe von “npm install” alle Pakete installieren lassen
  4. Den Taskrunner öffnen und einmal das “Run – Development” ausführen lassen und danach dann “serve – Cold” starten
  5. Die Webseite starten, diese sollte jetzt funktionieren.

Quellen:

https://webpack.js.org/

https://github.com/AngularClass/angular2-webpack-starter

https://offering.solutions/articles/asp-net/how-to-set-up-angular-2-and-webpack-in-visual-studio-with-asp-net-core/

Kommerzielle Ui Framworks für Angular 1 / 2 (Telerik, DevExpress, …)


Es gibt zwar eine Menge kostenlose Ui Frameworks für AngularJs, diese beinhalten aber meist nur die Standardkomponenten und z.B. kein richtiges Data Grid. Da ich aber ein richtiges Data Grid benötigte, musste ich mich also nach kommerziellen Lösungen umsehen. Bei den kommerziellen Lösungen habe ich leider keines finden können welches Nativ in AngularJs 1.x geschrieben ist. Außer Ionic, aber dabei handelt es sich um ein pures Mobile Framework. Für die Standardwebanwendungen gibt nur Lösungen die im Kern auf jQuery setzen und dann nach außen hin einen Angular “Wrapper” / Schnittstelle anbieten, so dass man denkt man verwendet native Angular Komponenten. Dafür gibt es inzwischen bei allen Anbietern TypeScript Support, mit Hilfe von passenden Typings für das jeweilige Framework, ist IntelliSense dann auch kein Problem mehr.

Am Ende habe ich nur vier Anbieter finden können, die mir zugesagt haben, die zumindest laut Webseite eine Angular 1 Integration bieten. Dabei handelte es sich um

1. DevExpress mit DevExtreme

Wie schon anfangs erwähnt handelt es sich bei der Angular 1.x Umsetzung um einen Wrapper mit dem alle DevExtreme Controls auch für Angular bereitstehen. Bei DevExtreme handelt es sich um die günstigste Lösung, wenn man nur auf JavaScript Webkomponenten angewiesen ist. Die Dokumentation ist spitze und enthält live Beispiele die man direkt anpassen und ausprobieren kann. Außerdem gibt es einen Themebuilder in dem ich meine Bootstrap 3 Variablen einlesen kann und DevExtreme dann entsprechend meine gewohnten Styles verwendet für Bootstrap 3. Außerdem scheint es ein recht aktives Forum zu geben in dem DevExpress Mitarbeiter zu vielen Fragen die passenden Antworten liefern.

Da die Grundvoraussetzungen sehr gut waren, habe ich hier auch die Trial Version ausprobiert und meine erste simple Angular 1.x Anwendung mit einer DevExtreme Textbox die an das ngModel gebunden wurde, hat auch nicht länger wie 20 Minuten gedauert (sehr gute Dokumentation). Leider musste ich bereits hier feststellen, das die Implementierung nicht Angular Like umgesetzt wurde. Denn die Eingabe in das Textfeld wurde erst dann in meine lokale Angular Variable zurückgeschrieben wenn ich das Textfeld verlassen habe (also kein “natives” TwoWayModel Binding out of the box). Außerdem konnte ich für die Validierung nicht wie gewohnt über AngularJs gehen und die Form Variablen wie $valid … verwenden, sondern hier muss ein eigener Validator von DevExtreme verwendet werden, was das Zusammenspiel von eigenen Angular Komponenten und DevExtreme quasi “unmöglich” macht. Wenn man also ein Formular mit Validierung bauen möchte, verwendet man am Besten nur DevExtreme Komponenten.

Dann habe ich noch die Autocomplete Textbox ausprobiert und versucht eine Serverseitige Abfrage für die Autocomplete Elemente zu implementieren, was mir nach 4 Stunden nur zum Teil gelungen ist und ich mit der Implementierung nicht wirklich zufrieden war.

Für DevExtreme gibt es aktuell eine Angular 2 Implementierung im CTP Status – zum ausprobieren. Dabei handelt es sich aber ebenfalls um einen Wrapper der wieder auf jQuery zurückgreift. Hier hat man dann aber anscheinend wieder alle gewohnten DevExtreme Funktionen auch in Angular 2 Anwendungen zur Verfügung.

2. Infragistics mit Ignite UI

Hier wird zwar auf der Webseite mit AngularJs geworben, aber es wird nur auf ein GitHub Repository verwiesen, was nur einen Bruchteil der Controls enthält die für das normale Ignite UI mit jQuery zur Verfügung stehen. Außerdem ist die Dokumentation mehr als nur fragwürdig, zumindest für die Angular Implementierung. Auch die angebotene Angular 2 Implementierung hat zumindest Abhängigkeiten auf jQuery und dies hört sich im ersten Moment nicht nach einer nativen Implementierung an.

Aufgrund der “schlechten” Grundvoraussetzungen habe ich hier auch keine Trial Version ausprobiert. Denn das Produkt kam schon aufgrund der schlechten Dokumentation und wenigen Controls für Angular nicht mehr in die nähere Auswahl.

3. Syncfunctions

Auch hier handelt es sich um eine recht große Anzahl an Controls die einem zur Verfügung stehen und für die es einen Angular 1.x und Angular 2 Wrapper gibt. Leider war auch hier die Dokumentation für die AngularJs Integration bzw. jQuery so schlecht, das es keine Live Beispiele gab, sondern nur Code Snippets mit passenden Screenshots dazu. Aufgrund der schlechten Dokumentation habe ich auch hier keine Testversion ausprobiert.

4. Telerik mit Kendo UI

Auch Telerik bietet für die Angular 1 Integration nur einen Wrapper an, dieser ist aber meiner Meinung nach wesentlich besser wie der von DevExtreme. Denn hier bin ich nicht komplett auf die Controls von Kendo UI angewiesen, sondern kann auch problemlos meine eigenen Controls verwenden wenn ich z.B. ein Formular mit Validierung erstellen möchte. Denn die Controls von Kendo UI integrieren sich “fast” nahtlos in die Angular Welt. Wichtig ist hier die passenden Dokumentationsschritte für AngularJS zu lesen, dann versteht man auch die normale Dokumentation etwas besser, wenn man hier teilweise nicht direkt etwas von AngularJs liest. Außerdem ist die Dokumentation sehr gut, es gibt Live Beispiele die man auch direkt bearbeiten kann und sieht was sich ändert. Auch Kendo UI stellt einen Themebuilder zur Verfügung, der zumindest einen rudimentären Support für Bootstrap bereitstellt. Leider wird bei den Icons noch auf das Sprite Image mit Icons von Bootstrap 2 gesetzt. Damit ist der Themebuilder leider nicht so gut wie der von DevExtreme, wenn es um die Bootstrap Integration geht.

Da aber auch hier die Grundvoraussetzungen gepasst haben, habe ich die Testversion ausprobiert und hatte bereits nach 20 Minuten meine erste AngularJs Anwendung mit einem DatePicker erstellt. Außerdem war es mir möglich innerhalb von 3 Stunden eine Autocomplete Textbox mit Serverseitiger Abfrage zu erstellen ohne größere Probleme, was mir in DevExtreme nicht gelungen ist.

Auch Kendo UI stellt eine Angular 2 Implementierung seiner Controls zur Verfügung, diese werden aber gerade komplett neu nativ in Angular 2 erstellt und daher gibt es auch erst eine Beta mit nur ein paar Controls. Es gibt aber eine gut einsehbare Timeline und Kommunikation in der gesagt wird wie der aktuelle Releaseplan aussieht.

5. Fazit

Prinzipiell blieben nur zwei Frameworks übrig zwischen denen ich mich entscheiden musste, denn nur bei DevExtreme und Kendo UI waren wirklich sehr gute Dokumentationen vorhanden. Denn die Dokumentation muss bei der puren Anzahl an Einstellungsmöglichkeiten, die für die einzelnen Controls zur Verfügung stehen einfach sehr gut ausfallen, sonst ist man nur auf den Support des Anbieters angewiesen. Da ich aber auch weiterhin eigene AngularJs Controls verwenden wollte, war mir eine möglichst native AngularJs Integration auch sehr wichtig und daher verwende ich aktuell Kendo UI.

Mit der aktuellen Kendo UI Version, habe ich bisher das Grid und das Gantt Chart verwendet und hier merkt man teilweise schon sehr das hier eine jQuery Implementierung vorliegt und keine native AngularJs Implementierung. Trotzdem bin ich mit dem was das Grid bzw. das Gantt Chart kann sehr zufrieden und es gliedert sich soweit auch ganz gut in meine AngularJs Anwendung ein. Außerdem ist der Support bisher auch ganz gut, dieser antwortete in der Regel innerhalb von 2 Tagen, bisher auf jedes Problem was ich hatte und keinen passenden Forumseintrag finden konnte. Bei der Verwendung von “einfachen” Controls wie der Datepicker, denkt man schon “fast” das man eine reine AngularJs Implementierung vorliegen hat. Außerdem bin ich auf die nativen Angular 2 Implementierungen vom Kendo UI gespannt.

HINWEIS: Wer sich für ein kommerzielles UI Framework für AngularJs interessiert, dem würde ich meiner Meinung nach auf jeden fall empfehlen das er DevExtreme und Kendo UI einmal selbst ausprobiert und prüft womit man selbst am besten klar kommt.

Außerdem möchte ich darauf hinweisen, das ich beide Frameworks vorher noch nicht verwendet habe und mir durchaus auch ein Fehler bei der Verwendung von DevExtreme unterlaufen sein kann, warum ich z.B. die Autocomplete Textbox nicht mit meinen Ansprüchen zum Laufen bekommen habe oder das TwoWay Databinding nicht so funktionierte wie von mir erwartet.

Angular 2 Services automatisch aus .NET Controller erstellen mit T4 Template


Ich habe den bereit schon einmal vorgestellten ProxyGenerator erweitert, so das jetzt auch die Generierung von Angular 2 Services aus .NET Controllern möglich ist.

Der .NET Controller wird wie gehabt über jeder Funktion mit dem passenden Attribut versehen “CreateAngular2TsProxy” und als ReturnType wird der jeweilige .NET Rückgabewert der JSON Funktion eingetragen.

Mit Hilfe des T4 Templates “ProxyGeneratorScript.tt” wird dann der folgende Strongly Typed Angular 2 Service erstellt

Das ganze kann im Detail auf der zugehörigen GitHub Seite nachgelesen werden und das Paket selbst kann man per NuGet installieren. Wichtig ist das dafür zusätzlich noch TypeLite zum Erstellen der Passenden TypeScript Interfaces für unsere .NET Typen verwendet wird und damit ist es auch erst möglich das der Service komplett typisiert erstellt werden kann.

Angular 2.0 Released


Nach einer gefühlten Ewigkeit der Entwicklung, wurde nun endlich die erste Version von Angular 2.0 veröffentlicht. Auf der einen Seite freue ich mich über die neuen Möglichkeiten die einem geboten werden. Auf der anderen Seite stehen aber auch eine menge breaking changes die mit Angular 2.0 daher kommen, vor allem wenn man bisher alles mit Angular 1.x gebaut hat, ist eine Migration nicht so einfach möglich. Hier hoffe ich darauf das ngUpgrade auch das bietet was man bisher darüber lesen konnte.

Mit Angular 2 habe ich mich bisher zwar nur in den Grundzügen auseinander gesetzt und musste leider mit Erschrecken feststellen, das es auch in der RC Phase noch eine Menge Änderungen gab, das selbst einfachste Beispielprojekte nach einem Update nicht mehr funktionierten und man erst einmal schauen musste welches Modul es nicht mehr gibt oder umbenannt wurde, …. Solche Probleme gibt es bei einem Update von Angular 1.x zum Glück nicht. Daher hält sich meine Freude aktuell auch noch in Grenzen und ich werde für den produktiven Einsatz erst einmal noch etwas abwarten bis sich die API “gefestigt” hat und man sich “sicher” ist, dass sich diese nicht dauerhaft wie in der RC Phase ändert.

Außerdem fehlt mir persönlich noch eine einfache Lösungen für z.B. HttpInterceptoren in Angular 2, denn diese gibt es hier aktuell “noch” nicht. Dann müssen viele externe Bibliotheken auch entsprechend neu für Angular 2 erstellt oder umgeschrieben werden, wie z.B. “ui-router” oder “ng-bootstrap” die sich aktuell noch in der alpha für Angular 2 befinden.

Außerdem stellt sich die Frage nach dem Mehrwert, um ein Projekt auf Angular 2 umzustellen, denn ich verwende bereits heute TypeScript in meinen Angular 1.x Projekten und habe daher volles IntelliSense. Den einzigen Mehrwert den ich aktuell sehe, ist die Performance in größeren Views, wenn Angular 1.x mit seinen Watchern an seine Grenzen stößt, sollte es mit Angular 2 hier keine Probleme geben.

Wer jetzt immer noch Lust hat sich Angular 2 anzuschauen, für den habe ich einen älteren Blogeintrag auf den neuesten Stand gebracht, wie man Angular 2 in Visual Studio mit ASP.NET 4 einrichtet.