Mit AngularJS Projekte schnell an die Wand fahren

Transkript

1 Mit AngularJS Projekte schnell an die Wand fahren Häufige Fehler und wie sie sich vermeiden lassen Rouven Röhrig

2 2 Agenda 1. Herausforderungen in Enterprise-JavaScript-Projekten 2. Was ist AngularJS und was bietet es 3. Wie man Projekte an die Wand fährt und wie man es verhindert 4. Zusammenfassung und Ausblick

4 4 Herausforderungen in Enterprise-JavaScript-Projekten Kein Compiler Keine natürliche Strukturierung Loser Zusammenhang der Dateien Dynamische Typisierung Kein Klassen -Konzept Asynchronität Client-seitige Ausführung

6 6 Was ist AngularJS? JavaScript-Framework für Single-Page-Applikationen Client-seitiges JS für interaktives HTML Kümmert sich um die Abhängigkeiten der Dateien Hilft beim Strukturieren (u.a.) durch das MVVM-Pattern Entworfen für eine hohe Testbarkeit (UI- und Unit-Testing) Ermöglicht expressive HTML

7 7 Was ist eine Single-Page-Applikation? Klassische Webseite Single-Page-Applikation Webseite aufrufen HTTP requests Webseite aufrufen HTTP requests Antwort(en) mit Dateien (HTML, CSS, JS etc.) Antwort(en) mit Dateien (HTML, CSS, JS etc.) Webseite aufbauen Webseite aufbauen Link anklicken Link anklicken (HTTP requests) Send updates

8 8 Was ist expressive HTML? <div> <div> <div> <span>9</span> <span>1</span >... </div> <div> <span> </ span >... </div>... </div> </div> <sudoku> <grid> <row id="row1"> <cell id="r1c1">9</cell> <cell id="r1c2">1</cell>... </row> <row id="row2"> <cell id="r2c1"> </cell>... </row>... </grid> </sudoku>

9 9 MVW-Pattern: Model-View-Whatever-Pattern Angular ermöglicht die Trennung von View und Logik Manche sagen Angular basiert auf dem MVC-Pattern Andere (darunter der Referent) sagen es entspricht eher dem MVVM-Pattern Angular sagt es ist ein Model-View-Whatever-Pattern 1 : Stellen Sie es sich so vor, wie es für Sie am meisten Sinn ergibt! Angular sagt aber auch [ ] it's now closer to MVVM. 1 AngularJS: MVC vs MVVM vs MVP, 19 Juli 2012

10 10 Angulars wichtigste Konzepte Dependency Injection Two-Way-Databinding Expressive HTML

11 11 Angulars wichtigste Bausteine Expressions Direktiven Controller Services Module

12 12 Controller im MVVM Model nicht festgelegt in Angular? ViewModel Controller stellt Daten und Methoden zur Verfügung Databinding View DOM

13 13 Two-way-Databinding Hello World! Hallo!.controller('MyController', function() { this.helloworld = 'Hello World!'; this.input; // 'Hallo!' });

14 14 Zusammenspiel Direktive HTML partial template Direktive Service Service Service Cont roller Cont roller Direktive Cont roller HTML partial HTML partial Service Service Direktive Cont roller HTML partial

16 16 Problem: Unzureichende Automatisierung Wir fangen erst einmal an und automatisieren später Problematik: Manuelle Pflege der Abhängigkeiten Tests geben kein schnelles Feedback Es gibt keinen automatisierten Build-Prozess Build-Server ohne Build- und Test-Ergebnis => Tests werden vernachlässigt => Produktivitätsverlust => Nachgelagerte Automatisierung ist oft teuer!

17 17 Besser: Erst Automatisieren, dann Entwickeln Wir machen Automatisierung zur Voraussetzung! JavaScript-basierte Anwendungen lassen sich sehr gut automatisieren Automatisierung muss mitwachsen Umso später automatisiert wird, umso aufwendiger -> Geeignete Werkzeuge sind notwendig!

18 18 Besser: Erst Automatisieren, dann Entwickeln (2) Build-Prozess: NodeJS und npm NodeJS und npm für Entwicklungsabhängigkeiten npm als Command-line-tool npm als einziger Einstiegspunkt für Abhängigkeitsmanagement und Installation Build-Prozess Testausführung (Unit und GUI) Grunt oder Gulp? JA, Faustregel: npm wenn möglich, Grunt/Gulp wenn nötig

19 19 Besser: Erst Automatisieren, dann Entwickeln (3) Build-Prozess: npm als einziger Einstiegspunkt package.json install postinstall: test: e2e-test: taskxy: Entwicklungsabhängigkeiten Frontend-Abhängigkeiten Unit-Tests UI-Tests gulp complicated-job gulpfile.js gulp.task('complicated-job', );

20 20 Besser: Erst Automatisieren, dann Entwickeln (4) Standardisierte autarke Projekte durch npm Beliebiges JavaScript-Projekt, beliebiger Rechner: Voraussetzung: NodeJS und git 1. git clone 2. npm install (Installiert ALLE Abhängigkeiten lokal) 3. npm test (führt Tests aus) 4. npm start (optional: startet Webserver) -> Komplexität massiv reduziert

21 21 Besser: Erst Automatisieren, dann Entwickeln (5) Bower für Frontend-Abhängigkeiten npm für Entwicklungsabhängigkeiten bower für Frontend-Abhängigkeiten Vorteile: Trennung von Frontend und Backend-Abhängigkeiten. Flacher Abhängigkeitsgraph

22 22 Problem: Keine oder kaum GUI-Tests Problematik: Fehler treten trotz Unit-Tests auf Aufwand des manuellen Testens steigt Fehler bleiben lange unentdeckt => Äußere Qualität ist schlecht => Späte Automatisierung offenbart schlecht testbares HTML

23 23 GUI-Tests ab der ersten Seite Das Gesamtsystem testen GUI-Tests sind aufwendig und veralten schnell Auf wichtige Use Cases konzentrieren -> Smoke-Tests Testbare HTML-Komponenten benötigen IDs Klassen sind fehleranfälliger <row id="row1"> <cell id="r1c1"> </cell> <cell id="r1c2"> </cell> </row> <row id="row2"> <cell id="r2c1"> </cell> </row>

24 24 GUI-Tests: Page Object Pattern Egal ob Protractor oder Selenium, Java oder JavaScript: Page Objects! Ein Page Object repräsentiert eine Webseite weiß wie man darauf zugreift kennt Page Objects verlinkter Seiten Tests verwenden Page Objects statt eigene Locator Vorteil: Ändert sich eine Webseite, ändert sich nur ein Page Object

25 GUI-Tests: Page Object Pattern (2) Eine von vielen Möglichkeiten, die auf die Folie gepasst hat! 25 describe('login Page', function() { it('a user can login', function() { var loginpage = new LoginPage(); loginpage.get(); Für Page Objects bieten sich auch Singletons an! loginpage.setusernameandpassword('user1', 'abc'); var overviewpage = loginpage.clickloginexpectsuccess(); expect(overviewpage.isdisplayed()).tobe(true); }); });

26 GUI-Tests: Page Object Pattern (3) Eine von vielen Möglichkeiten, die auf die Folie gepasst hat! 26 function LoginPage() { this.get = function () { return browser.get('/#/login'); }; this.setusernameandpassword = function(username, password) { element(by.id('login-username')).sendkeys(username); element(by.id('login-password')).sendkeys(password); }; this.clickloginexpectsuccess = function() { element(by.id('login-button')).click(); return new OverviewPage(); }; }

27 27 Problem: Keine oder wenig Unit-Tests Das Frontend lässt sich nicht Unit-Testen Problematik: Viele Fehler Fehler werden spät entdeckt Entwicklung per Trial and Error Schlecht wartbarer und nicht testbarer Code => Schlechte innere und äußere Qualität => langsame riskante Entwicklung

28 28 Besser: Von Anfang an Unit-Tests Noch besser: TDD oder Test-first Testbarkeit ist wichtige Metrik für Qualität In Angular: Nur ein testbarer Controller kann ein guter Controller sein Frontend-Code lässt sich auch testen (Direktiven und Controller) Strikte Trennung von View und Logik Controller darf nicht vom DOM abhängen (nur Zustand und Methoden) Direktiven: Operationen möglich mit Tools Fokus auf Controller

29 29 Besser: Von Anfang an Unit-Tests (2) Geeignete Werkzeuge Test-Framework: Jasmine oder Mocha Test-Runner: Karma Testausführung in verschiedenen Browsern Viele Erweiterungen: Code-Coverage Ergebnis für Build-Server (z.b. Jenkins) Automatisierung: npm führt Karma aus, Karma führt Jasmine-Tests aus

30 30 Besser: Von Anfang an Unit-Tests (3) Automatisierung Automatisierung Viele Projekte haben einen größeren Build-Prozess z.b. Minification, Uglification, Sass-Build etc. Häufig muss der Code gebaut werden, bevor er getestet wird Okay und gut für Build-Server Schlecht für TDD und schnelles Feedback Empfehlung: Unit-Tests müssen auch ohne Build laufen Oder watch-task für Entwickler der wirklich schnell ist

31 31 Problem: Keine einheitlichen Codekonventionen Problematik: Flüchtigkeitsfehler schleichen sich ein Einfache Programmierfehler treten auf Schlechte Lesbarkeit und Wartbarkeit => Verringerte Softwarequalität => Verringerte Produktivität

32 32 Codekonventionen durchsetzen Linter findet einfache Fehler und stellt Konventionen sicher Statische Codeanalyse überprüft Codekonventionen und findet typische Fehler Bekannte Linter: JSLint: Fester Standard JSHint: Konfigurierbar ESLint: Konfigurierbar und erweiterbarer Zusätzlich: HTML validieren => Gute IDEs integrieren Linter-Errors

33 33 Problem: IDE unterstützt JavaScript unzureichend Wir entwickeln schon immer mit <BLANK>. Problematik: Schlechter oder kein JavaScript-Support Kein Syntax-Highlighting Keine Funktionen Keine automatisierten Refactorings Keine Linter-Integration => Langsame Entwicklungsgeschwindigkeit => Viele überflüssige Fehler

34 34 Eine IDE mit guter JavaScript-Integration Folgende IDEs bieten eine Integration WebStorm (kommerziell) Brackets, Atom, Sublime et al. (nicht-kommerziell) Visual Studio (kommerziell) => Aufwand und Kosten amortisieren sich schnell!

35 35 Problem: Code-Duplikationen Problematik: Änderungen müssen an vielen Stellen erfolgen Gefixte Fehler tauchen wieder auf Features sind nicht an allen Stellen implementiert => Änderungen und Erweiterungen sind teuer => Zunehmend unwartbarer Code => Schlechte Codequalität

36 36 Keine Code-Duplikationen Aber wie? HTML-Duplikationen Controller-unabhängig: Template-Direktive Controller-abhängig: Direktive (mit eigenem Controller) Duplikationen im Controller: Wiederverwendbarer Service JavaScript-Objekt

37 37 Keine Code-Duplikationen (2) JavaScript-Objekte explizit modellieren Objekte können on-the-fly erzeugt werden -> Führt zu Code-Duplikationen function Message(title, content) { var message = { title: 'a title', content: 'a message' }; Besser Eine von vielen Möglichkeiten, die auf die Folie gepasst hat! } this.title = title; this.content = content;.factory('message', function() { return Message; });

38 38 Keine Code-Duplikationen (3) Kleine Controller, Direktiven und Services Methodik: Große Controller lassen sich schlecht testen, daher: TDD! -> Kann ich einen Controller schwer Unit-Testen, ist er häufig zu groß. Werkzeuge: Services: (Wiederverwendbare) Logik auslagern Template-Direktiven: (Wiederverwendbare) HTML-Templates Direktiven: (Wiederverwendbare) UI-Aspekte kapseln

39 39 Problem: ng-controller statt Direktiven Problematik: ng-controller wird verwendet HTML-Code-Duplikationen Ähnliche oder duplizierte Controller => Komplizierte Scope-Abhängigkeiten => Schwer verständlicher Code => Duplizierter Code

40 40 Besser: Domänenspezifische Sprache mit Direktiven Direktiven sind das Feature von AngularJS Eine Direktive ist in sich abgeschlossen, bestehend aus: HTML-Template Controller Styling Unit-Test ;-) Eine Direktive manipuliert nur ihren eigenen DOM

41 41 Besser: Domänenspezifische Sprache mit Direktiven (2).directive('infobox', function() { return { templateurl: 'infobox.html', controller: function() {...}, controlleras: 'infobox', scope: { 'text': '@', }, bindtocontroller: true }; }); <div class="alert alert-info"> {{infobox.text}} <div> infobox{ /* styling */ } <infobox text="hello World!"/> Hello World!

42 42 Besser: Domänenspezifische Sprache mit Direktiven (3).directive('anotherDirective', function() { return { /* */ }; }); anotherdirective{ /* styling */ } <infobox ng-if="{{anotherdirective.somecondition}}" text="{{anotherdirective.status}}"/> <input /> <button.../>

43 43 Problem: Callback-based APIs Problematik: Führt meist in die Callback Hell [1] Abhängigkeiten schlecht parallelisierbar Aufwendige Fehlerbehandlung Keine Trennung von Fehler- und Erfolgsfall [1]

44 44 Besser: Promise-based APIs Angular bietet eigene API für Promises Promises ermöglichen Einheitliches API-Design Trennung von Fehler- und Erfolgsfall Promise chaining Sauberer Code loaddata(42).then( preprocessdata ).then( displayresult ).catch( alertuser ).finally( clearloadingflag ); => Achtung Design und Testing eigener APIs ist dennoch anspruchsvoll

46 46 Empfehlungen Automatisierung von Anfang an GUI-Tests ab der ersten Seite Unit-Tests -> TDD oder Test-first Hohe Testabeckung -> Testabdeckung messen! Code-Konventionen -> Linter und gute IDE Keine Code-Duplikationen -> Angulars Möglichkeiten nutzen Promise-based APIs

47 47 Rahmenbedingungen von Enterprise-JavaScript-Projekten Kein Compiler Testautomatisierung Keine natürliche Strukturierung Disziplin und Angular-Module Loser Zusammenhang der Dateien Angular-Module Dynamische Typisierung Testautomatisierung Kein Klassen -Konzept Explizit modellierte Objekte Asynchronität ~ Promise-based APIs Client-seitige Ausführung => Einige Probleme werden von EcmaScript2015 adressiert

48 48 Noch besserer Code durch TypeScript Vorteile von Angular mit TypeScript Typisierung (Typdeklaration, Klassen, Interfaces) Compile-Errors Typsichere Rest-Schnittstelle Serverseitiges DTO (z.b. in Java geschrieben) kann als TypeScript-DTO generiert werden -> TypeScript-Compile-Errors Kommt mit vielen zukünftigen EcmaScript-Features (Debugging mit Source in TypeScript-Dateien möglich)

49 49 Noch besserer Code durch TypeScript (2) Einschränkungen beim Einsatz von TypeScript mit Angular Konversion nicht immer ohne Cast möglich Compiler-Schritt kostet etwas Zeit Typdefinitionen für externen JavaScript-Code => Angular 2 wird mit TypeScript entwickelt

50 50 Vielen Dank für Ihre Aufmerksamkeit