Auteur: Danny Holstein

In mijn blogbericht van december 2024 heb ik een aantal zaken besproken die zich voordeden tijdens het updaten en upgraden van Angular applicaties. In het vorige blogbericht is echter nog lang niet alles besproken. In dit nieuwe blogbericht worden andere zaken die zich voordeden tijdens het upgraden nader behandeld.

Omdat Angular modules minder worden gebruikt, dienen de routes van een applicatie verplaatst te worden. De uitdaging is dat routes zich zowel in de root-module als in (child) feature-modules kunnen bevinden.

In eerdere versies van Angular werden de routes in de imports-array van een module geplaatst. Dit was wel aan regels gebonden, want in de root-module wordt gebruik gemaakt van RouterModule.forRoot(), terwijl in feature-modules er gebruik gemaakt wordt van RouterModule.forChild().

Mijn eigen Angular migratie tool inspecteert alle modules. Er wordt onderzocht of er zich root- of child-routes in de module bevinden. Wanneer dit het geval is, dan worden alle routes gebundeld en geformatteerd, waarbij iedere property van de route op een nieuwe regel komt te staan. Ook wordt er overal gebruik gemaakt van lazy loading door middel van de loadComponent property.

Het voordeel van lazy loading is dat een bepaalde route van de applicatie pas wordt geladen (als chunk/deel) wanneer dat nodig is. Zie de afbeelding hieronder voor het resultaat:

Wanneer er al een lange tijd geen onderhoud is uitgevoerd voor een Angular applicatie, dan geeft Visual Studio Code aan dat de code deprecated is doordat de tekst is doorgehaald. In de linker afbeelding hieronder is dat het geval bij de subscribe functie.

Hierbij is het probleem dat de huidige syntax niet meer gangbaar is. Het wordt afgeraden om deprecated code te gebruiken en vaak wordt dit in een volgende versie niet langer ondersteund. Daarom is het een goede zaak om de code te moderniseren.

In de rechter afbeelding hieronder is de code gemoderniseerd. Er wordt nu een Observer-object (met de next, error en complete callback-methoden) als argument meegegeven aan de subscribe functie.

Een groot Angular project kan echter vele tientallen en soms honderden subscribe functies bevatten. Om tijd te besparen kan mijn eigen Angular migratie tool alle componenten inspecteren en zoeken naar deprecated subscribe functies zoals hier linksboven. Wanneer een verouderde subscribe functie wordt gevonden, dan worden er automatisch accolades voor het object en de callback-methoden in de code geplaatst.

In mijn vorige blogbericht heb ik geschreven dat ontwikkelaars van populaire Angular libraries eveneens modules vervangen door standalone componenten. Opnieuw is Visual Studio Code behulpzaam door de deprecated code aan te geven met een doorhaling in zowel de import-statements als in de code zelf.

Een voorbeeld daarvan is de NgHttpLoader library dat een laadindicator op het scherm toont wanneer er data wordt opgehaald vanuit de WebAPI of iets anders wordt geladen. Zoals de code hieronder aangeeft, kan de deprecated code worden weggehaald en vervangen worden door andere code.

De code waarmee de bovenstaande code vervangen kan worden, was terug te vinden in de documentatie. Omdat de NgHttpLoader library afhankelijk is van de status van de HttpClient, wordt er een extra interceptor toegevoegd met de withInterceptors functie van de HttpClient. Het dollar-teken op het einde van pendingRequestsInterceptor$ doet overigens niets speciaals, dit is meer een signaal naar andere developers dat het hier om een Observable gaat.

Tenslotte kan het standalone component uit de NgHttpLoader library worden opgenomen in app-root. De tag van deze library kan boven de routeroutlet worden geplaatst.

De vervanging van modules door standalone componenten wordt eveneens gereflecteerd in de Angular testbestanden. Deze specification files zijn te herkennen door de extensie: spec.ts. De verandering is dat componenten niet meer worden opgenomen in de declarations-array maar in de imports-array van het TestBed.

Wanneer er tests voor een project zijn geschreven dan zullen er in de nieuwe situatie fouten in de terminal verschijnen. Voor een groot project is het ondoenlijk om de vele tientallen specification files handmatig te updaten. Mijn eigen Angular migration tool plaatst de standalone componenten in de imports-array en leegt hierbij de declarations-array. Wanneer de imports-array nog niet bestaat in de specification file dan wordt deze aangemaakt.

Sinds Angular 18 is er ondersteuning toegevoegd voor Materials 3 met de daarbij behorende nieuwe API’s om kleuren, typografie, en andere zaken aan te passen. Met andere woorden: de Angular Material componenten hebben hiermee een andere visuele stijl gekregen.

Een probleem deed zich voor doordat de SCSS stijlen (SCSS is een superset van CSS) van Angular Material waren gebroken. In het bijzonder was er in de terminal het foutbericht te lezen dat een bepaald theme-bestand niet meer bestaat op een bepaalde locatie. Het bleek zo te zijn dat het Angular Material team de locatie van de map met vooraf gebouwde themes heeft verplaatst.

Door de komst van de nieuwe API’s voor Materials 3 bleken ook bepaalde functies en variabelen niet meer te bestaan. Gelukkig zijn de Material 2 functies en variabelen nog steeds te gebruiken door deze te voorzien van het voorvoegsel: m2-. Ondanks de komst van Materials 3  blijven de Material 2 themes nog steeds ondersteund.

Het updaten en upgraden van Angular applicaties blijft nodig met iedere nieuwe grote publicatie van Angular. Mijn eigen Angular migration tool blijft hierdoor ook in ontwikkeling en bespaart veel typewerk. Het alternatief is om ieder component handmatig te updaten, maar voor een groot project (of meerdere grote projecten) is dat ondoenlijk.