Gemäß des im Dezember 2016 veröffentlichten Plans gibt es zweimal jährlich ein neues Major-Release von Angular. Wenngleich das die Möglichkeit für Breaking Changes eröffnet, sollten sich diese jedoch in Grenzen halten. Ein Beispiel dafür ist, dass beim Umstieg auf eine neue Angular-Version auch TypeScript zu aktualisieren ist. Da aber gerade im UI-Umfeld die Zeit nicht stillsteht, hat sich das Angular-Team eine Deprecation Policy auferlegt. Demnach können mit jedem Major-Release Konzepte als veraltet erklärt werden. Die Entwickler haben dann mindestens bis zum nächsten Major Zeit, diese zu ersetzen. Auch das war bis jetzt selten Hexerei. Beispielsweise wurde die Klasse OpaqueToken durch InjectionToken<T> ersetzt, und aus dem Element template wurde ng-template, um Konflikte zu vermeiden. Teams, denen die halbjährlichen Zyklen zu kurz sind, können stattdessen auch auf Long-Time-Support-Versionen von Angular setzen. Diese werden jeweils für ein Jahr gepflegt. Die erste dieser Versionen ist 4.x. Somit wird sowohl dem Wunsch mancher Teams nach weniger Veränderung, aber auch der rasanten Weiterentwicklung von UI-Technologien Rechnung getragen. Wie auch schon beim Übergang von Version 2 auf 4 gestaltet sich der Sprung auf Angular 5 sehr evolutionär. Neue Möglichkeiten in Bereichen wie Internationalisierung, Performance oder Progressive Web-Apps runden den Leistungsumfang ab.

Internationalisierung vereinfacht

In Sachen Internationalisierung ist seit Version 4.0 einiges passiert. Beispielsweise lässt sich das Angular-Team nun durch den Autor der bekannten Bibliothek ngx-translate verstärken. Diese Bibliothek gilt im Angular-Umfeld als De-facto-Standard für das Laden von Übersetzungstexten. Der Autor hat sich vor allem um die Pipes zum Formatieren von Zahlen und Datumswerten gekümmert. Beispiele dafür sind number, currency und date. In Angular 2 und 4 basieren diese noch auf dem Internationalisierungs-API der Browser. Da dieses jedoch nicht durchgängig implementiert ist, war ein problematisches Systemverhalten die Folge. Version 5 verfolgt deswegen dieselbe Strategie wie der Vorgänger AngularJS: Es existiert nun pro Kombination aus Sprache und Land, kurz Locale genannt, eine TypeScript-Datei mit Metadaten. Diese sind natürlich nicht von Hand geschrieben, sondern werden aus dem Unicode-Repository generiert [1]. Um die Bundle-Größe nicht unnötig anwachsen zu lassen, muss die Anwendung die gewünschten Dateien zunächst importieren. Danach kann eine dieser Locales als Standard festgelegt werden. Möchte die Anwendung davon abweichen und auf ein anderes der eingebundenen Locales wechseln, kann sie das damit einhergehende Kürzel an den letzten Parameter der Pipes übergeben.

Die Standardsprache lässt sich hingegen nicht im Nachhinein ändern. Auch wenn das auf den ersten Blick seltsam erscheint, gibt es dafür gute technische Gründe. Es geht dabei um das wohl wichtigste Architekturziel von Angular: Performance. Um die Handhabe der Pipes zu optimieren, sieht Angular das Konzept der puren Pipes vor. In Anlehnung an die Welt der funktionalen Programmierung sind das Pipes, deren Ausgaben einzig und allein von ihren Eingaben bestimmt werden. Sich ändernde Nebeneffekte, wie eine globale Variable mit der Standard-Locale, dürfen sich auf solche Pipes nicht auswirken. Aufgrund dieser Einschränkung muss Angular pure Pipes auch nur erneut ausführen, wenn sich die Eingaben ändern. Nicht-pure Pipes, die von Nebeneffekten abhängen, muss Angular hingegen immer und immer wieder ausführen, konkret nach jedem Ereignis. Zumal es die Nebeneffekte nicht überwachen kann. Das ist auch der Grund, warum die meisten von Angular gelieferten Pipes pur sind. Und das betrifft auch die hier genannten. Ein Be...