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.

Package Installer Extension für Visual Studio


Inzwischen sollte man auch als .NET Webentwickler mitbekommen haben, das es neben NuGet auch noch npm und weitere Paketmanager gibt. Hier gibt es wie auch bei NuGet eine Konsole, aber meist keine direkte Visual Studio Integration. In den meisten Fällen möchte man aber nur schnell ein Paket installieren und nicht erst in die Doku schauen welche Konsolenbefehle man dafür genau benötigt. Genau hier kommt jetzt die Package Installer Extension zum Einsatz.

image

Mit dem Package Installer kann man Bower, npm, TSD, Typings oder NuGet Pakete sehr einfach und schnell installieren.

Wenn die Visual Studio Extension einmal installiert ist, steht mit einem Rechtsklick auf das Projekt der Menüpunkt “Quick Install Package…” zur Verfügung.

image

Hier öffnet sich dann ein kleines Popup in dem man die Quelle auswählen kann und danach gibt man nur noch den Paketnamen an.

image

Und der Package Installer lädt das passende Paket herunter und legt auch die passende Konfigurationsdatei an wie z.B. “typings.json” oder “package.json”.

React “Hello World” mit Visual Studio 2015 ASP.NET MVC 4 (jsx und tsx)


Als heißer Verfechter von AngularJs, habe ich mir gedacht schaust du auch mal über den Tellerrand und liest dich mal ein wenig in React ein. Denn bei React handelt es sich nicht um ein “komplettes” Framework wie AngularJs sondern eher um die Möglichkeit Performantere DOM Manipulation auszuführen, bei z.B. großen Listen, wo AngularJs so seine Probleme hat und evtl. kann ich beides später effektiv in einem Projekt verwenden.

Da ich aktuell auf ASP.NET MVC 4 Projekte und Visual Studio 2015 angewiesen bin, war dies meine erste Anlaufstelle um ein React Projekt zu erstellen. Dafür habe ich eine einfache MVC Seite erstellt.

React Bibliotheken installieren

Leichter gedacht als getan, denn die NuGet Pakete die ich so gefunden habe, waren alle nicht aktuell. Daher habe ich npm für die Installation der passenden React Pakete verwendet. Dafür muss im Root Verzeichnis des Projekts eine “package.json” Datei angelegt werden.

image

mit dem folgenden Inhalt

 

und dann einfach über die Rechte Maustaste auf der “package.json” => “Restore Packages” ausführen.

image

Danach gibt es einen versteckten Ordner “node_modules” im Rootverzeichnis unseres Projekts, in dem sich auch die zwei Verzeichnisse “react” und “react-dom” befinden.

image

Im jeweiligen “dist” Verzeichnis befindet sich die passende JavaScript Datei für “react.js” und “react-dom.js”. Diese müssen nur noch in der BundleConfig oder direkt in der Seite entsprechend eingebunden werden.

 

Da es sich hier um ein Beispiel handelt, verwende ich die Dateien direkt aus dem “node_modules” Verzeichnis. Wenn es sich um die Produktivumgebung handelt, richte ich vorher noch einen Gulp Task im Visual Studio ein, der die Dateien ins “Scripts” Verzeichnis meiner Anwendung kopiert und verlinke diese dann aus dem Scripts Verzeichnis heraus.

Damit hätten wir schon einmal die React Bibliotheken die wir für unsere Anwendung benötigen.

JSX und TSX Dateien

React selbst verwendet direkt im JavaScript HTML Syntax um seine Komponenten zu erstellen und verwendet dafür JSX (JavaScript Syntax Extension) was es wesentlich einfacher macht komplexe Komponenten direkt in JavaScript zu erstellen. Auch Visual Studio 2015 unterstützt das JSX Format. Für JavaScript muss man Dateien mit der Endung *.jsx anlegen und in TypeScript muss man Dateien mit der Endung *.tsx anlegen.

JavaScript JSX Dateien “kompilieren”

Damit die JavaScript JSX Dateien in normale JavaScript Dateien übersetzt werden können (damit sie auch der Browser versteht), verwendet man in den meisten Beispielen die JavaScript Bibliothek Babel, da ich aber Visual Studio verwende und die Erweiterung “Web Compiler” installiert habe, benötige ich keine extra JavaScript Bibliothek dafür.

image

Denn wenn man mit der rechten Maustaste auf eine JSX Datei geht, dann gibt es hier einen Punkt “Web Compiler” => “Compile file” und die Datei wird übersetzt in JavaScript und die passende JavaScript Datei wird automatisch angelegt und auch noch eine neue Konfigurationsdatei im Rootverzeichnis wird angelegt “compilerconfig.json”, in dieser Datei sind alle Dateinamen enthalten die automatisch bei Änderungen wieder kompiliert werden sollen.

image

image

Damit ist es jetzt möglich React Code zu erstellen, der automatisch beim Speichern übersetzt wird.

 

Jetzt müssen wir nur noch die Kompilierte JavaScript  Datei in der BundleConfig oder direkt im HTML verlinken und ein Element mit der ID “helloWorld” anlegen und schon funktioniert unsere “Hello World” Anwendung für JavaScript (*.JSX) Dateien.

 

TypeScript TSX Dateien und TypeDefinitions

Auch TypeScript in Visual Studio unterstützt das JSX Format, nur wird hier eine Datei mit der Endung *.tsx erstellt. Damit das ganze dann mit React zusammen funktioniert, muss noch in den Projekteinstellungen bei “TypeScript-Build” bei “JSX-Kompilierung in TSX-Dateien” auf “React” gestellt werden.

image

Das Übersetzen von TypeScript in JavaScript übernimmt hier der TypeScript Compiler nach jedem Speichern und der Web Compiler wie bei JavaScript wird hier nicht benötigt.

Damit TypeScript aber auch funktioniert, muss es React kennen und dafür werden TypeDefinition Dateien für React benötigt. Damit sich diese leichter installieren lassen und wir nicht erst eine NPM Konsole benötigen, gibt es das Addon “Package Installer”

image

Nach dem wir den Package Installer installiert haben, gibt es im Submenü in unserem Projekt den Punkt “Quick Install Package…”

image

Im Fenster was dann aufgeht, wählen wir “TSD” aus und geben “react” ein und wiederholen das ganze noch für “react-global”.

image

Jetzt gibt es einen neuen versteckten Ordner “typings” in unserem Projekt und eine “tsd.json” im Rootverzeichnis des Projekt. Ich habe beides dem Projekt hinzugefügt, damit ich diese nicht immer neu abrufen muss auf einem anderen Rechner, soweit ich es aber beurteilen kann ist dies nicht notwendig.

image

Jetzt können wir beginnen und unsere TypeScript Datei anlegen und den passenden React Code zu erstellen. Dafür müssen wir jetzt eine “*.tsx” Datei anlegen z.B. mit folgendem Inhalt

 

Von Vorteil ist wenn man hier eine Referenz auf die “tsd.d.ts” einfügt, denn dann kann man auf Nummer sicher gehen, das Visual Studio die passenden Typings auch findet.

Damit das Beispiel auch funktioniert, muss die Datei wieder in der BundleConfig eingefügt werden und unserer HTML Datei muss noch ein Element mit der ID “example” hinzugefügt werden.

So mit diesem Wissen sollte es jetzt problemlos möglich sein ein Projekt entsprechend für React vorzubereiten. Das Komplette Projekt findet Ihr auch auf meiner GitHub Seite.

Quellen:

https://templecoding.com/blog/2015/12/11/using-react-typescript-webpack-and-visual-studio/

http://staxmanade.com/2015/08/playing-with-typescript-and-jsx/

AngularJs TypeScript Interceptor Template


AngularJs bietet ein interessantes Konzept um AJAX Requests bzw. Response zu manipulieren oder zu prüfen ob ein Response bestimmte Daten enthält. Das ganze nennt sich HTTP Interceptor. Ich verwende es z.B. für die folgenden Aufgaben in meinen Projekten

  • Prüfen ob im Response eine Meldung enthalten ist die angezeigt werden soll, wenn diese vorhanden ist, existiert im Response JSON immer ein Property mit dem Namen “Message” und dieses wird dann entsprechend ausgewertet und angezeigt ohne das ich an der eigentlichen Funktion wo der Request gestartet wurde in irgendeiner Art eingreifen muss.
  • Prüfen ob der Response fehlerhaft ist und wenn ja auf eine Fehlerseite umleiten und den Fehler entsprechend anzeigen.
  • Bei einem Request den Header manipulieren und noch ein Antiforgery Token hinzufügen
  • Bei einem Request prüfen ob es sich um den IE handelt und hier das Caching für AJAX Requests über die Standard Header deaktivieren

Dies sind nur einige wenige Funktionen wo es sich lohnt auf AngularJS HTTP Interceptoren zu setzen.

Ein passenden Template für einen HTTP Interceptor in TypeScript sieht z.B. folgendermaßen aus.

 

Ein Beispiel wie das ganze in einem Projekt eingebunden werden kann findet Ihr in meinem GitHub Projekt.

T4 Template als Service/Proxybuilder für AngularJs TypeScript Services


Wenn man einen AngularJs HTTP Service erstellt der die Verbindung zum .NET Controller herstellen soll um Daten abzufragen oder zu speichern, handelt es sich immer um den “gleichen” boilerplate Code der geschrieben werden muss. Genau hier setzt mein T4 Template der Proxybuilder an und generiert die passenden AngularJs Services in JavaScript oder auch in TypeScript und in Verbindung mit TypeLite werden komplett typisierte Services erstellt.

Damit das ganze funktioniert muss man nur noch seine Controller Methoden mit einem passenden Attribut versehen z.B. “CreateAngularTsProxyAttribute”. Dann das Projekt kompilieren und das T4 Template “Scripts\ProxyGeneratorScript.tt” ausführen und schon werden die passenden AngularJs Service Funktionen erstellt. Aus dem folgenden .NET Controller

wird dann der volltypisierte AngularJs TypeScript Controller der vom T4 Template generiert wurde.

Das komplette Projekt findet Ihr auf GitHub inklusive einer ausführlichen Beschreibung und ein Beispielprojekt. Das fertige Paket gibt es auch bei NuGet.

Der Proxybuilder kann die folgenden Proxies erstellen, dafür wird jeweils nur das passende Proxybuilder Attribut benötigt:

  • AngularJs pure JavaScript Services
  • AngularJs TypeScript Services voll Typisiert und nur in Verbindung mit TypeLite zu verwenden. TypeLite erstellt Interfaces von unseren .NET Klassen in TypeScript, die der Proxybuilder dann verwendet für Übergabe- und Rückgabewerte.
  • jQuery pure JavaScript Services
  • jQuery TypeScript Services voll Typisiert und nur in Verbindung mit TypeLite.

Wenn Ihr Fragen oder Erweiterungswünsche habt, dann bitte auf GitHub als Issue eintragen.

Angular 1.5 Component Template in TypeScript


Seit Angular 1.5 gibt es noch eine neue Möglichkeit um Direktiven zu erstellen. Der neue Typ nennt sich “component” und bietet einige Vorteile gegenüber der klassischen Direktive. Dazu gehören z.B. die einfachere Konfiguration, da viele Werte bereits vorkonfiguriert sind mit den am häufigsten verwendeten Werten. Dann ist bereits die ControllerAs Syntax eingebaut, in dem man im Template standardmäßig direkt auf die Bindings (früher scope) über “$ctrl.varname” zugreifen kann. Außerdem gibt es so genannt LifeCycle Hooks wie man sie inzwischen aus Angular 2 kennt und welche erst zu einem bestimmten Zeitpunkt aufgerufen werden. Wie z.B. “$onInit()”, welche erst aufgerufen wird, wenn alle Controller und Ihre Bindungen erstellt wurden. Sie kann z.B. zur Initialisierung von eigenen Werten genutzt werden (Quelle, Angular Doku).

Im Folgenden ein einfaches TypeScript Template für die Erstellung einer Component für Angular 1.5. Wie ihr das ganze einbinden und verwenden könnt, findet Ihr auch in meinem GitHub Projekt.

Resharper Code Templates über Resharper Extension bereitstellen


Ich hoffe zumindest, dass jeder der mit Resharper arbeitet sich auch schon einmal die Resharper Code Templates angeschaut hat. Denn diese sind sehr einfach zu erstellen und können einem viel Arbeit abnehmen. Außerdem kann man die Templates auch exportieren und die wichtigsten Templates für das Team auf einem Share oder Webserver als NuGet Paket für die Resharper Extensions bereitstellen.

1. Exportieren der Resharper Code Templates

Zum Exportieren der aktuellen Code Templates, im Visual Studio unter Resharper, auf “Manage Options” klicken.

image

Und in diesem Dialog unter “Import und Export” auf “Export to File” gehen.

image

Hier kann man jetzt auswählen, welche Settings man exportieren möchte und dazu gehören z.B. auch Code Styles und Live Templates. Da ich im Moment nur die Live Templates teilen möchte, exportiere ich nur diese.

image

Diese werden dann z.B. als “AlleLiveTemplates.DotSettings” im Dateisystem abgelegt.

2 Erstellen der NuGet Datei “meineLiveTemplates.nupkg”

Dafür muss eine nuspec Datei erstellt werden, welche benötigt wird um in Verbindung mit der NuGet.exe eine nupkg Datei zu erstellen in der unsere *.DotSettings eingebettet ist.

Dafür benötigt man die Nuget.exe diese kann man direkt auf der NuGet Webseite herunterladen. Der Inhalt der nuspec Datei sieht z.B. folgendermaßen aus.

Wichtig zu wissen ist, das die depenency “Wave” mit Version 5 für Resharper 10.1+ (auch 2016.1.x) ist, damit die NuGet Datei später von Resharper auch als Resharper Extension erkannt wird. Außerdem muss beim Target darauf geachtet werden, dass wie in meinem Beispiel  “AngularJsResharper.Settings” an der passenden Stelle im Target steht und mit der “id” aus “metadata” im nuspec übereinstimmen. In meinem Beispiel liegt die “AlleLiveTemplates.DotSettings” im gleichen Verzeichnis.

Das ganze sieht dann z.B. folgendermaßen aus.

image

Wenn man eine neue Version seiner nuspec erstellt, sollte man auch nicht vergessen die Versionsnummer hochzuzählen, denn dann zeigt Resharper ab Visual Studio 2015 in der Statusleiste auch an das es ein Update gibt.

Und damit ich nicht jedes mal die Konsole öffnen muss, habe ich eine bat Datei erstellt in der nur eine Zeile steht:

nuget.exe pack AngularJsResharperSettings.nuspec

Wenn man jetzt die bat Datei ausführt, sieht das Verzeichnis in meinem Fall danach so aus

image

3 Bereitstellen der nuget für die Resharper Extensions

Dafür kann man in den Resharper Optionen unter dem Punkt “Extension Manager”

image

Noch weitere Quellen angeben, z.B. ein lokales Verzeichnis oder einen Netzwerkpfad, wenn man die Einstellungen auch mit anderen Entwicklern teilen möchte und hier einfach unsere nupkg Datei einfügen und schon findet man diese auch im Resharper Extension Manager.

image

image

image

Jetzt muss man die Settings nur noch installieren und Visual Studio neustarten und schon kann man auch die bereitgestellten Templates verwenden.

Hinweis: Da ich mit den Settings etwas exzessiv auf meinem Rechner herumgespielt habe und auch meine eigenen Templates mehrmals lokal importiert und exportiert habe, scheint Resharper hier noch ein paar Bugs zu haben, denn manchmal wurden bei mir nicht alle Templates angezeigt, nachdem ich die Settings installiert hatte. Wenn Ihr daher nicht sicher seid ob alle Templates auch geladen werden, sucht euch einen Rechner von einem Arbeitskollegen der am besten bisher noch nichts mit Resharper Templates gemacht hat und schaut dort ob alles da ist.

Das ganze geht natürlich auch für ältere Resharper Versionen, hier sind die nuspec Einstellungen nur etwas anders. In der Quelle findet Ihr auch noch die Einstellungen für die älteren Resharper Versionen.

Quelle: http://asizikov.github.io/2015/07/05/sharing-resharper-settings/