Client-Architektur. in Angular. Philipp Burgmer

Transkript

1 Client-Architektur in Angular Philipp Burgmer

2 Über mich Philipp Burgmer <> Entwickler, Trainer, Speaker Web-Technologien TypeScript, Angular </> 1

3 Über uns W11K GmbH - The Web Engineers <> Gegründet 2000 Auftrags-Entwicklung / Consulting Web / Java Esslingen / Siegburg </> thecodecampus <> Technologie Schulungen seit 2007 Projekt-Kickoffs & Unterstützung im Projekt </> 2

4 Überblick <> Architektur <> Services & DI <> Komponenten <> Module & Routing <> Datenfluss <> Modularizierung <> Testen 3

5 Architektur

6 Was ist Architektur? <> Welche Komponenten gibt es <> Wie spielen diese Zusammen (Relationship) <> Wie grenzen sie sich von einander ab (Separation of Concern) 5

7 Wie lässt sich Architektur bewerten? <> Nicht-Funktionale-Anforderungen - Wartbarkeit / Testbarkeit - Erweiterbarkeit / Flexibilität - Wiederverwendbarkeit - Performance / Skalierbarkeit - Verständlichkeit / Nachvollziehbarkeit <> Widersprechen sich teilweise 6

8 Architektur in Angular

9 Style Guide <> Style Guide mit Best Practises <> Empfehlungen, keine Verpflichtung <> Beschreibt Architektur-Bausteine 8

10 Services & DI

11 Service <> Kapselt irgendwelche Funktionalität - Sollte UI nicht direkt verändern - Kombination Service und Komponente / Direktive - Ausnahme: Title Service <> Richtige Größe wichtig - Schwierig zu Schneiden - Single-Responsibility-Prinzip - Indiz: Testbarkeit 10

12 Dependency Injection <> Ermöglicht lose Kopplung <> Abhängigkeiten sichtbar machen (Konstruktor-Parameter) <> Nicht an konkrete Implementierung binden Flexibilität <> Nicht an Umgebung binden Wiederverwendbarkeit <> Abhängkeiten mockbar Testbarkeit 11

13 Komponenten

14 Komponenten <> Klein halten - Single Responsibility - Wiederverwendbarkeit, Testbarkeit <> Kapselung einhalten - - Verändern nur eigenen DOM Component Service Component <> Sind für UI zuständig - Single-Responsibility - Datenbeschaftung und Haltung in Services 13

15 Demo

16 Context & Presentation <> a.k.a Smart & Dumb / Smart & Presentation <> Presentation - Kennt Umgebung nicht - Soll Daten darstellen - Bekommt Daten per Input übergeben - Aggregiert und abstrahiert Events per Output <> Context - Kennt Umgebung - Besorgt Daten - Bindet Presentation-Components ein - Interpretiert Events 15

17 Demo

18 Module & Routing

19 EcmaScript Module <> Steuern welcher Code eingebunden wird - Kein toter Code <> Kapselung - Keine globalen Variablen - Anhängigkeiten erkennbar 18

20 Angular Module <> Ebene über EcmaScript-Modulen - Steuern was das Framework kennt und auflösen kann <> Feature-Module - Anhaltspunkt: Top-Level-Menü-Einträge - Beinhalten Komponenten und Services <> Core - Beinhaltet allgemeine, häufig verwendete Sachen - Auch Abhängigkeiten zwischen Features erlaubt (z.b. Dashboard) <> Oft feinere Aufteilung - Für Build-Optimierung 19

21 Routing <> Heimliches Herzstück von Angular Anwendungen <> Gibt mit Modulen zusammen Anwendung eine Struktur - Routen in Feature-Modulen definieren, in App aggregieren - Kontext-Komponenten im Routing verwenden 20

22 Demo

23 Zustand & Datenfluss

24 Datenfluss <> Wer ändert wann welche Daten <> Wer wird wie über Änderungen informiert <> Großes Problem in AngularJS Anwendungen <> Angular ebenfalls keine Vorgaben 23

25 Demo

26 Der Feind: Mutability <> Shared Mutable State <> Zwei-Wege-Data-Binding <> Daten werden einfach geändert <> Wer Binding hat wird aktualisiert <> Führt zu viel Polling 25

27 Die Lösung: Functional Reactive Programming <> Immutable Data Structures - z.b. über Object.freeze und Bibliothek wie Immer - Nur bestimmter Code darf Daten verändern <> Observables - In Angular über RxJS schon integriert - Subscriber bekunden Interesse - Aktualisierungen können explizit bekannt gemacht werden 26

28 Flux Action Dispatcher Store View <> Grundgedanke: Unidirectional Data Flow <> Flux ist ein Pattern - Verschiedene Implementierungen 27

29 Redux 3 Action Store View current state Reducer <> Redux implementiert Flux - Etwas andere Namen - Gleicher Grundgedanke 1 new state 28

30 Tydux Store 2 1 View State 3 Mutators <> Inspiriert von Flux & Redux <> Versucht die Probleme von Redux zu lösen - Alles komplett typisiert (TypeScript) - Keine Zuordnung über Strings - Erzwingt Unveränderbarkeit der Daten außerhalb von Mutators 29

31 Demo

32 Angular Module & Kapselung

33 Angular Module & Komponenten 32

34 Angular Module & Komponenten 33

35 Angular Module & Komponenten 34

36 Angular Module & Komponenten <> Positiv - Vermeidung Namenskolisionen <> Negativ - Schwierig zu lernen - Schlecht nachvollziehbar - Im Code nicht gleich ersichtlich 35

37 Angular Module & Provider 36

38 Angular Module & Provider 37

39 Angular Module & Provider 38

40 Angular Module & Provider <> Negativ - Abhängigkeit von Feature zu Core nicht ersichtlich - Fehler erst zur Laufzeit <> Positiv - Ist in anderen DI Umgebungen auch so - Eigentlich auch richtig <> Problem: Unterschiedliches Verhalten für Provider und Komponenten - Für Zugriff auf Komponenten muss Core in Feature importiert werden 39

41 Angular Module & Provider 40

42 Modularizierung über Packages

43 Packages <> Angular Anwendung Monolith zur Laufzeit <> Wiederverwendbare / allgemeine Teile auslagern (Bibliothek) - Eigene NPM Packages - Private Repos möglich (Nexus, Artifactory, NPM Inc) <> Kombination aller Paket- & Modulsysteme - NPM Paket installieren - EcmaScript Module per absolutem import Statement - NgModule zu imports hinzufügen <> Re-Exports um interne Strukturen zu verbergen 42

44 Demo

45 Packages <> Problem 1: Kein Schutz vor tiefem Zugriff <> Problem 2: Angular CLI bisher nur für Anwendungen - Alternative Builds wie ng-packagr oder nrwl/nx <> Problem 3: Entwicklung mit aktuellem Stand - npm link - Separate App für Package-Entwicklung 44

46 Testen

47 Testen <> Unit-Tests wichtig für langfristige Wartbarkeit - Tests oft guter Indikator für saubere Architektur - Lesbarkeit & Verständlichkeit der Tests - Tests sind im Idealfall ausführbare Doku <> Test-Driven-Development hilft beim Schneiden - Zusätzlicher Context - Single-Responsibility - Schlecht testbar? Indiz für macht zuviel 46

48 Testen <> Dependency Injection und Mock-Support <> Angular Testing Guide <> Test-Code leider sehr aufgebläht - it('desc', async(inject([dependency, (dep) => {}]))) - Viel Schachtelung, viele Klammern - Keine Verwendung der Typen bei inject 47

49 Lazy-Loading

50 Lazy Loading <> Wichtig für Skalierung - Code on-demand nachladen - Initialen Payload klein halten - Schneller Start bei großen Anwendungen <> Führt nicht gerade zu mehr Übersichtlichkeit - Provider an Modulen - "Referenzierung" von Modulen in Strings statt über import Statements <> Häufiger Fehler: Alles lazy laden 49

51 Lazy Loading 50

52 Lazy Loading 51

53 Lazy Loading 52

54 Lazy Loading 53

55 Zusammenfassung <> Angular bietet viele Konzepte <> Konzepte alleine machen keine gute Architektur <> Saubere Architektur möglich <> Gefahren lauern im Detail <> Über Style-Guide viele Empfehlungen vorhanden 54

56 Philipp Burgmer GitHub: pburgmer