Was die neue Version des JavaScript-Frameworks zu bieten hat

Angular 8 erschienen: Das sind die Highlights!

Karsten Sitterberg

© Shutterstock / balthus

Angular 8 ist da. Die achte Major-Version des JavaScript-Frameworks hat wieder viele spannende Neuerungen zu bieten. Was genau sich getan hat, beschreibt Karsten Sitterberg in dieser Folge seiner Kolumne Webentwicklung mit Angular.

Neu in Angular 8

Angular 8 ist erschienen. Neben Aktualisierungen der Abhängigkeiten und den Vorbereitungen des Ivy Renderer ist die deutlichste Veränderung der Support von TypeScript 3.3. Auch in diesem Release haben es die Angular-Entwickler geschafft, den Aufwand für die Aktualisierung überschaubar zu halten, so dass kontinuierlichen Updates nichts entgegensteht.

Der Aufwand für die Aktualisierung auf Angular 8 ist überschaubar.

Nachdem der Ivy-Renderer in Angular 7 nicht fertig wurde, ist er mit Angular 8 nun soweit gediehen, dass er mit einem Feature-Toggle der Allgemeinheit zur Verfügung gestellt wird: Um eine sanftere Migration auf Ivy zu ermöglichen, wird der Ivy-Renderer nur aktiviert, wenn die Angular-Compiler-Option enableIvy auf true gestellt wird. Der Ivy-Renderer wird auch nach dem Release von Angular 8 noch weiter optimiert, um ihn dann voraussichtlich mit Angular 9 zum Default-Renderer zu machen.

Im Folgenden betrachten wir die Änderungen von Angular 8 im Detail.

Angular 8 – die Breaking Changes

Da Angular 8 eine neue Major-Version darstellt, ist durchaus mit inkompatiblen Änderungen zu rechnen. Diese fallen in Angular 8 jedoch wenig dramatisch aus. Nutzern von Angular-CLI wird der Großteil des Updateaufwandes durch den Befehl ng update abgenommen.

Eine wesentliche Neuerung ist, dass mit der Einführung von TypeScript 3.3 der Support für alle niedrigeren TypeScript-Versionen eingestellt wurde. Auf einige der neuen TypeScript-Features wollen wir in einem gesonderten Abschnitt eingehen.

Weiterhin wurde das Auto-Wrapping-Feature abgeschafft: Mit Auto-Wrapping sorgte Angular dafür, dass potentiell invalides HTML-Markup erkannt und “ausgebessert” wurde. Dieses Feature bezog sich dabei speziell auf zu verschachtelnde Elemente, die nicht gemäß der HTML-Spezifikation in vorgeschriebene Elternelemente eingebettet sind. Angular erreichte damit, dass etwa ein alleinstehendes <tr>-Element automatisch mit einem <tbody>-Element umgeben wurde, wenn dies nicht vorhanden war. Dies hat allerdings in einigen Situationen zu unerwünschten Effekten geführt, etwa bei Verwendung einzelner <tr>-Elemente in Verbindung mit Content Projection. Dieses Verhalten wurde mit Angular 8 daher entfernt.

Angular-Entwickler, die das Google-eigene Build-System Bazel nutzen, müssen in Zukunft zusätzlich zu dem Paket @angular/bazel auch noch @bazel/typescript installieren, um Bazel weiterhin nutzen zu können. Ebenfalls sei an dieser Stelle erwähnt, dass für für Angular-Bazel-Builds der Support für SASS-Kompilierung von Stylesheets hinzugefügt wurde.

Ein Beispiel, wie umsichtig das Angular Team mittlerweile mit Breaking Changes umgeht, ist das InjectionToken, um sich in einer Angular App das aktuelle Document injizieren zu lassen. Ursprünglich war das InjectionToken mit Namen “DOCUMENT” Teil des @angular/platform-browser. Mit Angular 4.3 (damals wurde der neue HttpClient grade eingeführt), wurde der Import aus @angular/platform-browser als „deprecated“ markiert. Seitdem ist es Standard, das DOCUMENT-Token aus @angular/common zu importieren. Der als veraltete Import aus @angular/platform-browser wird nun entfernt.

iJS React Cheat Sheet

Free: React Cheat Sheet

You want to improve your knowledge in React or just need some kind of memory aid? We have the right thing for you: the iJS React Cheat Sheet (written by Joel Lord). Now you will always know how to React!

API Summit 2019
Thilo Frotscher

API-Design – Tipps und Tricks aus der Praxis

mit Thilo Frotscher (Freiberufler)

Golo Roden

Skalierbare Web-APIs mit Node.js entwickeln

mit Golo Roden (the native web)

Angular 8 – die Big Features

Entwickler freuen sich meist auf neue Features, auch Angular 8 bringt dazu welche bei. Ein wesentliches Feature in Angular 8 ist natürlich der Ivy-Renderer, der sich aber noch hinter dem Flag enableIvy: true des Angular-Compilers verbirgt. Dieses Flag kann in der tsconfig.json aktiviert werden, wie der folgende Code-Ausschnitt zeigt.

{
  "compilerOptions": { … }
  "angularCompilerOptions":  {
    "enableIvy": true
  }
}

Weiterhin lag ein Fokus auf Konsistenz innerhalb des Frameworks bzw. besserer Benutzbarkeit des Frameworks an sich. So wurden die ViewChild– und ContentChild-Queries erweitert:

Bisher war es vom Ergebnis der Queries abhängig, zu welchem Zeitpunkt die Queries aufgelöst wurden. Befand sich das zu suchende Element etwa in einer Sub-View (z.B. innerhalb eines *ngIf), so wurde die Query erst nach einem Change-Detection-Lauf aufgelöst. Das Resultat stand dann erst im ngAfterViewInit (bzw. ngAfterContentInit) zur Verfügung. Falls das Element unabhängig von Bindings direkt im Template vorhanden war, also statisch, konnte die Query schon direkt nach Erzeugen der Nodes aufgelöst werden, womit das Resultat z.B. schon im ngOnInit zur Verfügung steht. Wenn nun in ein bestehendes Template ein *ngIf (oder auch ein *ngFor) hinzugefügt wurde, konnte es passieren, dass bestehender Code anschließend nicht mehr funktionierte.

Um den Zeitpunkt, zu dem die Queries aufgelöst werden, expliziter zu machen, wurde das Flag “static“ zu den beiden Queries hinzugefügt.

@ViewChild('myTemplateRef', {static: false}) foo: TemplateRef;

Wird static auf den Wert false gesetzt, wird die Query immer erst nach der Change Detection aufgelöst. Ist static auf den Wert true gesetzt, sind die Query-Resultate schon im ngOnInit-Callback verfügbar. Allerdings werden mit static auf true keine Resultate innerhalb eines *ngIf oder dergleichen unterstützt.

Diese neue Option gilt nur für die ViewChild– und ContentChild-Queries. ViewChildren und ContentChildren werden generell immer nur nach der Change Detection aufgelöst.

Für alle Entwickler, die momentan auf dem Migrationspfad von AngularJS nach Angular sind (ngUpgrade), wird die Zusammenarbeit der beiden Frameworks beim Routing erweitert. Somit kann nun auch Hash-basiertes Routing in hybriden Angular-AngularJS Anwendungen verwendet werden.

Das Forms-API von Angular wurde um die Methode markAllAsTouched() erweitert, welche ein Formular inklusive aller seiner Kinder als “touched” markieren kann. Diese Methode ist direkt auf dem Angular-AbstractControl definiert und kann somit sowohl auf einer FormGroup, einem FormArray oder auch einem FormControl verwendet werden. Damit spart der Entwickler wiederholte Logik, um Formularbäume zu traversieren und Änderungen durchzuführen.

Abgekündigte Features in Angular 8 (Deprecations)

Neben den Breaking Changes sind auch die Deprecations in neuen Angular-Versionen interessant, da diese einen Hinweis darauf geben, welche inkompatiblen Änderungen in zukünftigen Angular-Versionen anstehen können.

Eine wesentliche Deprecation ist mit der Anpassung des Angular Frameworks an die kontinuierliche Weiterentwicklung moderner Web-Standards verbunden. Konkret geht es um die Lazy-Loading-Syntax: Das „lazy“ zu ladende Modul wird über das Property loadChildren in der Routen-Konfiguration des Angular-Routers angegeben. Dabei war es bisher üblich, einen “magischen” String anzugeben, welcher den Pfad zum entsprechenden Modul und dessen Modulnamen in folgender Form miteinander verband:

{
  //...
  loadChildren: './path/to/my-feature.module#MyFeatureModule'
}

Für die Zukunft ist allgemein im Web-Umfeld vorgesehen, dynamische import()-Ausdrücke für solche Zwecke zu verwenden. Diese Syntax wird nun auch von Angular und dem Angular-CLI unterstützt, die loadChildren-Angabe bekommt damit folgende Form:

{
  //...
  loadChildren: () =&gt; import('./path/to/my-feature.module').then(mod =&gt; mod.MyFeatureModule)
}

Diese Variante ist standardkonform und bietet darüber hinaus eine deutlich explizitere und sicherere Syntax, weshalb dies in Zukunft die einzige von Angular unterstützte Variante sein wird. Daher wird die Lazy-Loading-Variante mit Strings in Angular 8 als „deprecated“ markiert. Um ein möglichst reibungsloses Update auf die neue Syntax zu gewährleisten, bietet es sich an, das Angular-CLI Kommando ng update zu verwenden. Mit dessen Hilfe werden die bisherigen String-Angaben automatisch analysiert und in die neue Syntax überführt.

Auch das Testing-Framework von Angular ist von Änderungen betroffen. Bisher war es in Tests möglich, sich etwa einen Service per TestBed.get() aus der Testumgebung injizieren zu lassen. Dabei waren sowohl der Übergabewert als auch der Rückgabewert der Funktion vom Typ any (also TestBed.get(any): any). Diese Variante ist offensichtlich nicht typsicher, außerdem ist dadurch eine direkte Unterstützung des Entwicklers durch Werkzeuge, wie eine IDE, erschwert. Daher wurde diese Variante durch ein typsicherers TestBed.get() ersetzt und die Variante mit any gleichzeitig „deprecated“. Die Umstellung auf die neue Version sollte in aller Regel keinen Aufwand verursachen, da es sich hierbei im Wesentlichen um eine neue, typsichere Signatur der Methode handelt.

Des Weiteren werden zwei experimentelle Funktionalitäten abgekündigt, die wenig bis gar nicht genutzt und dadurch ebenso unregelmäßig gewartet wurden. Zum einen betrifft dies die Integration mit Googles “Web Tracing Framework”. Diese Integration war ursprünglich zur erweiterten Anwendungsanalyse, etwa für Performance, gedacht. Da diese Integration allerdings seitdem nicht mehr gewartet wurde (und auch vermutlich so für die meisten Anwendungen damit nicht mehr funktioniert), wird diese Integration nun abgekündigt.

Weiterhin gab es schon seit den Anfängen von Angular das Bestreben, die komplette Angular-Anwendung im Wesentlichen in Web Worker ablaufen zu lassen. Daraus ist das Paket @angular/platform-webworker hervorgegangen. Mit der Zeit hat sich allerdings gezeigt, dass ein solches Herangehen für die meisten Anwendungen unpraktikabel ist – zum Beispiel aufgrund mangelnder Unterstützung des Web-Worker-API durch Webcrawler und auch bei Build- und Bundling-Tools. Daher wird das Paket @angular/platform-webworker nun abgekündigt. Dies bedeutet jedoch unter keinen Umständen, dass Webworker nicht mit Angular verwendet werden können oder sollten. Im Gegenteil wird sogar mit diesem Release die Unterstützung für Webworker durch Angular CLI verbessert, siehe unten. Web Worker sollten in diesem Modell allerdings eher für rechenintensive Aufgaben verwendet werden, welche nicht im Haupt-Thread ablaufen sollen.

TypeScript

Angular 8 stellt den Support für TypeScript-Versionen kleiner 3.3 ein und ist selbst im Wesentlichen schon auf TypeScript-Version 3.4 umgestellt. Mit diesen beiden Versionen sind einige neue Features und Sprachkonzepte hinzugekommen, die es lohnt, sich anzuschauen.

Eine wichtige Neuerung, die die beiden TypeScript-Versionen mit sich bringen, sind inkrementelle Builds, sowohl für multiple Projekte als auch innerhalb eines Projektes. Durch das Flag –incremental wird so in Zukunft für einen deutlich schnelleren und angenehmeren Entwicklungsprozess gesorgt (Angular-CLI unterstützt das incremental-Flag leider noch nicht, siehe Issue auf GitHub: https://github.com/angular/angular-cli/issues/13941). Wird die Option aktiviert, so werden Informationen über den Projektgraphen während der letzten Kompilierung in einer .tsbuildinfo-Datei abgelegt. Wird das nächste Mal ein Build mit –incremental gestartet, werden die Informationen aus der .tsbuildinfo-Datei genutzt, um Type-Checks so effizient wie möglich durchzuführen und das so kompilierte Projekt auszugeben. Falls die Datei .tsbuildinfo nicht existiert, wird sie generiert. Damit kann sie auch gefahrlos jederzeit gelöscht werden.

Mit TypeScript 3.4 wird die Typ-Inferenz für generische Funktionen verbessert, sodass auch verkettete generische Funktionen immer typsicher bestimmt werden können. Diese Verbesserung ist sehr hilfreich bei Verarbeitungsketten, wie sie etwa mit den pipeable-Operatoren von RxJS auftreten.

Bisher gibt es in TypeScript schon den Array-Datentypen ReadonlyArray. Dieser kann nur ausgelesen, aber nicht intern verändert werden. Dies bedeutet, dass keine neuen Einträge in das Array hinzugefügt werden können und bestehende weder entfernt noch verändert werden können. Eine solche immutable Datenstruktur ist hilfreich, um die Korrektheit einer Anwendung sicherzustellen. Vor allem für viele funktionale Programmiermuster ist Unveränderlichkeit auch ein Mittel zur Performance-Optimierung, um geänderte Daten an einer geänderten Referenz erkennen zu können. Um ein ReadonlyArray einfacher und analog eines herkömmlichen Array definieren und verwenden zu können, wird nun ein neuer Modifier readonly speziell für Arrays eingeführt.

function myFuncArray(arr: readonly string[]) {
  console.log(arr[0]);
  arr.push('test'); // Error, immutable!
  arr[1] = 'foo'; // Error, immutable!
}

Neben Arrays ist der neue Modifier auch auf Tupels anwendbar. Für Tupel gelten analoge Regeln:

function myFuncTupel(tupel: readonly [string, number]) {
  console.log(arr[0]);
  arr[1] = 42; // Error, immutable!
}

Zu beachten ist hierbei, dass der Readonly-Modifier in dieser Form nur auf Array- und Tupel-Typen anwendbar ist:

let foo: readonly Map<string>; // error!
let bar: readonly Array<number>; // error!

let myArr: readonly string[]; // ok
let myTupel: readonly [string, number]; // ok

 

Ein weiteres interessantes Feature in TypeScript 3.4 sind die sogenannten const Assertions. Eine const Assertion kann ähnlich wie eine Type-Assertion auf einen Wert angewendet werden. Insbesondere ermöglichen const Assertions eine stärkere Typ-Einschränkung:

// Typ ist nicht einfach 'string', sondern "henry"
let name = 'henry' as const

Wird die const Assertion auf Arrays angewendet, so wird aus dem Array ein readonly-Tupel:

// Typ ist 'readonly ['Helene', 42]'
let person = ['Helene', 42] as const;

Bei Objekten sorgt die const Assertion dafür, dass die Properties des Objektes readonly werden:

// Typ ist '{ readonly x: 12, readonly y: 42 }'
let location = { x: 12, y: 42 } as const;

Ähnlich wie der readonly-Modifier für Arrays verbessert die const Assertion somit Fähigkeiten zur Performance-Analyse und erhöht außerdem die Korrektheit von TypeScript-Anwendungen.

Angular CLI

Eine Neuerung im Angular CLI macht sich direkt während des Update- bzw. Installationsprozesses bemerkbar, denn der User wird nach Installation der Abhängigkeiten gefragt, ob er seine CLI-Nutzungsdaten per Analytics zur Verfügung stellen möchte. Diese Daten sollen eingesetzt werden, um das CLI nutzergerecht weiterzuentwickeln. Neben dem Update wird der Anwender auch bei Neuanlage eines Projektes gefragt, ob er für dieses  Nutzungsstatistiken zur Verfügung stellen möchte.

Differential Loading

Bereits in früheren Versionen gab es Plug-ins für sogenanntes “Differential Loading”. Mit “Differential Loading” ist es möglich, die Anwendung so zu bauen, dass für jeden Browser bzw. jede Browserversion eine möglichst optimierte Variante der Anwendung zur Verfügung gestellt werden kann. Dies bedeutet, dass älteren Browsern etwa eine nach ES5 kompilierte Version der Anwendung zur Verfügung gestellt wird, während neuere Browser eine nach ES2015 kompilierte Anwendung ausgeliefert bekommen, wodurch neueste Sprachfeatures nativ und ohne Polyfills genutzt werden können. Das reduziert die Dateigröße, spart damit Bandbreite und führt zu schneller geladenen Anwendungen.

In Angular CLI Version 8 wird Differential Loading nun auch standardmäßig aktiviert. Um zu entscheiden, welche Varianten der Anwendungen zu bauen sind, wird – falls nicht schon vorhanden – eine Datei browserslist generiert. In dieser Datei können die gewünschten Ziel-Browser hinzugefügt werden, das CLI passt dann automatisch den Build auf die Zielplattformen an.

Webworker

Um im Browser rechenintensive Funktionalitäten ablaufen zu lassen, ist es ratsam, nicht den JavaScript-DOM-Thread zu nutzen, da es sonst schnell dazu kommt, dass die Oberfläche  blockiert und die Anwendung nicht reagiert. Um die Oberfläche nicht zu blockieren, kann für solche Aufgaben ein Webworker verwendet werden. Auch wenn Webworker an sich schon verhältnismäßig „alt“ sind (auch IE 10 bietet Webworker-Support, https://caniuse.com/#feat=webworkers), konnte ihre Einbindung in den Build-Prozess von Angular CLI doch aufwändig sein. Mit Angular CLI 8 wird dies deutlich vereinfacht.

Unterstützt durch Angular Schematics kann ein neuer Webworker sogar automatisiert generiert werden: Der Befehl ng g worker DataProcessing fügt dem Projekt die zum Bauen eines Webworker nötige Konfiguration hinzu und generiert den Worker in der Datei src/app/data-processing.worker.ts. Innerhalb des Worker-Script wird dann im Wesentlichen ein Eventlistener für das message-Event hinzugefügt.

addEventListener('message', ({ data }) =&gt; {
  const response = `worker response to ${data}`;
  postMessage(response);
});

Bekommt der Worker nun ein Message-Event, so wird der Listener-Callback ausgeführt. In diesem wird nun der rechenintensive Arbeitsschritt erledigt. Das Ergebnis der Berechnung wird nun per postMessage an den DOM-Thread zurückgeschickt. Im DOM-Thread kann der Worker nun angebunden werden, etwa im OnInit der AppComponent:

ngOnInit() {
  if (typeof Worker !== 'undefined') {
    const worker = new Worker('./data-processing.worker', {type: 'module'});

    worker.onmessage = ({data}) =&gt; console.log('Message', data);

    worker.postMessage('Hallo Worker');
  } else {
    console.log('Webworker nicht unterstuetzt');
  }
}

Um den Worker zu erzeugen, muss das TypeScript-Modul angegeben werden, in dem sich der Code befindet, der im Worker-Thread ausgeführt wird. Hier ist das ./data-processing.worker. Anschließend wird ein Callback registriert, der auf die Message-Events – und damit die Ergebnisse – reagiert, die aus dem Worker emittiert werden. Damit der Worker nun seine Arbeit verrichtet, wird dieser per Post-Messaging angetriggert.

SVG-Templates

SVG-Elemente bieten im Browser die Möglichkeit, komplexe Grafiken durch eine eigene XML-Markup-Syntax zu erstellen und diese darüber hinaus mit Animationen zu versehen. Um mit solchen SVG-Grafiken dynamisch interagieren zu können, ist es in Angular (schon lange) möglich, dynamisch an SVG-Attribute zu binden, wie in folgender Grafik dargestellt ist.

Angular 8 - Dynamisches Binden an SVG-Attribute innerhalb eines Angular-Templates

Dynamisches Binden an SVG-Attribute innerhalb eines Angular-Templates

Damit können diese SVG-Elemente auch gesteuert werden, um so sogar eigene SVG-Angular-Komponenten zu schreiben. So können etwa Komponenten wie diese Skalen-Anzeige erstellt werden:

Angular 8 - Skalen-Komponente, umgesetzt mit Angular und SVG-Template

Skalen-Komponente, umgesetzt mit Angular und SVG-Template (Anleitung: Angular SVG)

Mit diesem Update werden die Einsatzmöglichkeiten von SVG mit Angular noch mehr erweitert, denn nun ist es auch möglich, ganze .svg-Dateien als Angular-Template zu verwenden. Damit lassen sich sowohl grafisch ansprechende als auch hoch dynamische Komponenten entwickeln, die sich beliebig skalieren lassen und gleichzeitig eine geringe Dateigröße aufweisen.

Angular 8 - Angular-Komponente, die eine SVG-Datei als Template referenziert

Angular-Komponente, die eine SVG-Datei als Template referenziert

Builder

Angular-CLI stellt Möglichkeiten zur Verfügung, um Code zu generieren oder auch zu verändern. Dies sind die sogenannten Schematics. Außerdem kann man mit dem Angular-CLI Arbeitsschritte auf bestehendem Code ausführen, etwa Builds anstoßen, Linting oder Testing. Im Rahmen der Standardisierung des sogenannten Angular-CLI „Architect API“ werden nun die sogenannten Builder eingeführt, welche genau diese Aufgaben übernehmen sollen.

Mit den Buildern wird es – analog der Schematics – einfach möglich sein, bestehende Arbeitsschritte anzupassen oder eigene Arbeitsschritte in Form eines Builders umzusetzen, um diesen dann einfach in einem bestehenden Angular-CLI-Projekt nutzen zu können. Eine umfangreiche Beschreibung des Architect API und der Builder führt in diesem Artikel zu weit, daher sei an dieser Stelle auf eine detaillierte Beschreibung von Angular-CLI Team-Lead Hans Larsen verwiesen.

Allgemeines

Mit Angular CLI 8 wird das Paket node-sass, welches eine nativen Implementierung des Sass-Compilers nutzt, gegen das Paket sass ausgetauscht, das den Sass-Compiler als reines JavaScript-Paket zur Verfügung stellt. Dies dient zum einen einer Vereinheitlichung der Build-Infrastruktur und dürfte zum anderen vor allem in firmeninternen Netzwerken zu einfacheren Setups führen – vor allem, wenn sich diese hinter einem Proxy befinden und keinen Download von Binaries aus dem Internet zulassen. Gerade in CI-Setups hat das immer wieder zu unnötigen Problemen geführt.

Auch das Ordner-Layout wurde etwas überarbeitet, sodass sich die E2E-Testdateien von Apps, welche per ng generate app erzeugt wurden, nun innerhalb des jeweiligen /project/-Unterordners befindet. Außerdem werden nun für die E2E-Tests keine eigenen Projekte innerhalb der angular.json mehr angelegt. Stattdessen sind die E2E-Tests nun Teil der architect-Konfiguration der jeweiligen App.

Angular Material

Neben vielen kleineren Neuerungen und Bugfixes gibt es mit Material 8 drei Änderungen, die vor allem Auswirkungen auf die Projektstruktur haben und deshalb hier kurz vorgestellt werden.

Damit der Nutzer klarer erkennen kann, aus welchem Teil der Material-Library bestimmte Symbole kommen, wird es ab Material 8 deprecated sein, direkt von @angular/material zu importieren. Stattdessen sollte direkt aus einem bestimmten Feature, zum Beispiel @angular/material/button, importiert werden. Da dies in @angular/cdk genauso gehandhabt wird, sorgt dies auch für eine bessere Einheitlichkeit zwischen den beiden Libraries. Der direkte Import bewirkt zudem, dass ungenutzte Features gar nicht erst im Build landen.

Falls man einen Blick in den Quellcode von Angular Material werfen möchte, oder gar einen eigenen Beitrag zum Projekt leisten möchte, sollte man darauf achten, dass das Repository auf GitHub von angular/material2 in angular/components umbenannt wurde. In der inneren Ordnerstruktur des Projektes wurde der Ordner src/lib in src/material umbenannt.

Für einige Komponenten der Material-Bibliothek haben sich die Konstruktor-Signaturen geändert. Beispielsweise im Bereich der Tab-Komponenten, der List-Komponenten, des Progress-Spinners und der Buttons und Badges. Da der Konstruktor in der Regel nicht manuell aufgerufen wird, sollten diese Änderungen allerdings keine große Behinderung beim Update darstellen.

Upgrade auf Angular 8

Ein Upgrade auf die neue Angular-Version ist nicht sehr aufwändig, wenn man bisher sein Projekt gut gepflegt hat. Vor allem wenn Angular-CLI genutzt wird, ist das Upgrade dank des eingebauten Befehls ng update denkbar einfach.

Durch den Befehl ng update werden zunächst alle Abhängigkeiten aufgelistet, die aktualisiert werden können. Das Update an sich geschieht dann, indem man die zu aktualisierende Abhängigkeit angibt, z.B. ng update @angular/core. Es kann passieren, dass das Projekt Abhängigkeiten besitzt, die inkompatibel zu einer neuen Angular-Version sind oder es zumindest deklarieren. Um für Testzwecke dennoch die neue Angular-Version installieren zu können, gibt es die Kommandozeilenoption force, z.B. ng update @angular/core –force. Beim Update der lokalen Angular-CLI-Version ist es bisweilen nötig, die Versionen anzugeben, auf die und von der upgedatet werden soll: ng update @angular/cli –from 7.3.9 –to 8.0.0.

Durch den immer weiter verbesserten und erweiterten Update-Befehl des Angular CLI wird ein Angular-Update mit jeder Version angenehmer. Dies gilt insbesondere, wenn ein Projekt gut gepflegt wird, wodurch man automatisch einen Blick auf größere anstehende Änderungen erhält. Diese Erfahrung haben zum Beispiel auch die Entwickler von Air France – KLM gemacht. In ihrem Erfahrungsbericht beschreiben sie, wie der Aufwand für Major-Versionupdates jedesmal geringer wurde.

Angular 8 – Fazit

Insgesamt kann gesagt werden, das Angular ein stabiles Framework ist, das mittlerweile zuverlässige, unaufgeregte und einfache Upgrade-Pfade ermöglicht. Dabei ist ein wesentlicher Faktor die Funktionalität, die das Angular CLI mit dem Befehl ng update zur Verfügung stellt. Ein anderer Faktor ist, dass das Angular Team alles daran setzt, einfache Updates zu ermöglichen. Die eigenen Projekte auf Angular 8 zu aktualisieren ist damit auf alle Fälle sinnvoll, besonders, wenn man schon bisher darauf geachtet hat, die Projekte möglichst aktuell aktuell zu halten. Empfehlenswert ist sicherlich, bereits jetzt Projekte mit dem neuen Ivy-Renderer zu validieren und damit gut für Angular 9 gerüstet zu sein.

Geschrieben von
Karsten Sitterberg
Karsten Sitterberg
Karsten Sitterberg ist als freiberuflicher Entwickler, Trainer und Berater für Java und Webtechnologien tätig. Karsten ist Physiker (MSc) und Oracle-zertifizierter Java Developer. Seit 2012 arbeitet er mit trion zusammen.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: