23 en 24 maart zijn we met een hoop collega’s naar de NG-BE conferentie gegaan. Deze was georganiseerd in het Holiday-Inn Gent Expo hotel. Dit was een zeer leuke locatie met tal van activiteiten, elke dag was gevuld met zeer interessante talks. De dag begon met een lekker ontbijt en natuurlijk een koffie. Daarna mocht iedereen naar een bepaalde meeting room om een talk te volgen. We kregen ook voldoende pauze om even een frisse neus te halen en natuurlijk weer wat te eten. Hieronder een overzicht van mijn favoriete talks:
Test harnesses
Het eerste deel gaat over test harnesses; deze werd gegeven door Alisa Duncan. Zij is een Senior Developer Advocate bij Okta en een ervaren ontwikkelaar met een passie voor het bouwen van communities en het leren van nieuwe dingen. Ze is een erkende Google Developer Expert in Angular en een Women Techmaker Ambassador die zich inzet voor de ontwikkeling van vrouwen in de technologie.
Alisa praat over het gebruik van test harnesses bij het testen van front-end componenten in Angular. Test harnesses zijn een soort API voor het testen van HTML-fragmenten, waardoor de implementatie details van de componenten worden geëncapsuleerd en het testen gemakkelijker wordt. Het gebruik van test harnesses zorgt ervoor dat de innerlijke werking van de geëncapsuleerde componenten genegeerd kan worden, waardoor tests gemakkelijker te lezen en te schrijven zijn en minder onderhoud nodig hebben. Alisa merkt op dat Angular Material-components test harnesses ingebouwd hebben voor elk van hun controls, wat het testen nog gemakkelijker maakt. Als je Angular V12 of hoger gebruikt en Angular Material-componenten gebruikt, is het raadzaam om test harnesses te gebruiken. Alisa raadt aan om eerst je tests te upgraden naar test harnesses voordat je de MVC-update van Angular V15 uitvoert. In de presentatie wordt uitgelegd hoe test harnesses er in actie uitzien en hoe ze gebruikt kunnen worden om componenten te testen.
Laten we eens kijken naar een voorbeeld van hoe test harnesses gebruikt kunnen worden bij het testen van Angular Material-componenten. Stel je voor dat we een Angular-app hebben met een loginpagina, waarop de gebruiker zijn e-mailadres moet invoeren om in te loggen. Op deze pagina gebruiken we een Angular Material-input veld.
Zonder test harnesses zouden we de DOM van de input moeten manipuleren om deze te vinden en te testen, wat nogal omslachtig kan zijn. Met test harnesses kunnen we echter een gestandaardiseerde API gebruiken die specifiek is ontworpen voor het testen van Angular Material-componenten.
Hier is een voorbeeld van hoe we het e-mailadres veld zouden kunnen testen met een test harness:
In dit voorbeeld gebruiken we de MatInputHarness van Angular Material om toegang te krijgen tot het e-mailadres veld. We kunnen dit doen door te zoeken op de CSS-selector #email-input die we hebben toegevoegd aan de HTML-code van onze pagina. Vervolgens kunnen we de setValue()-methode gebruiken om de waarde van het veld in te stellen op “test@example.com”. Daarna controleren we of de waarde van het veld inderdaad is bijgewerkt met getValue().
Dit is slechts één voorbeeld van hoe test harnesses kunnen worden gebruikt bij het testen van Angular-apps, maar het geeft een idee van hoe handig ze kunnen zijn. Door test harnesses te gebruiken in plaats van rechtstreeks met de DOM te werken, kunnen we onze tests eenvoudiger schrijven en onderhouden, en ze zijn minder kwetsbaar voor wijzigingen in de HTML-code van onze app.
Partial DOM hydration
De volgende talk gaat over partial DOM hydration in Angular. Gegeven door Jeff Whepley, Co-founder en CTO bij GetHuman, Google Developer Expert met Angular, Boston AI Meetup Organizer, Co-Creator van Angular Universal (server rendering).
Dit is een van de meest gewilde features in Angular. Jeff heeft een zeer leerrijke (en leuke) presentatie gegeven over dit onderwerp. Zelfs zijn vrouw en kinderen kwamen aan bod om partial DOM hydration te visualiseren. Ik stel voor dat je dat eens gaat bekijken op YouTube en dat je hopelijk even hard geniet als ik ervan genoten heb.
Nu om wat meer in detail te gaan. Stel je voor dat je een webpagina hebt met duizenden elementen die allemaal zichtbaar zijn, en je wilt er slechts een paar wijzigen op basis van een gebruikersactie. Met traditionele client-side rendering (CSR) frameworks zoals Angular, zou je de hele pagina opnieuw moeten renderen, wat niet alleen inefficiënt is, maar ook de prestaties van de app kan beïnvloeden.
Dit is waar partial DOM hydration in beeld komt. Het is een functie die momenteel wordt ontwikkeld voor Angular en die ervoor zorgt dat alleen de gewijzigde delen van de DOM (Document Object Model) worden bijgewerkt in plaats van de hele pagina te renderen.
Stel je bijvoorbeeld voor dat je een lijst hebt met 100 items en je klikt op een knop om slechts één item te bewerken. Met behulp van partial DOM hydration hoeft Angular alleen het bewerkte item opnieuw te renderen en de wijzigingen opnieuw in te voegen in de DOM, in plaats van de hele lijst opnieuw te renderen.
Dit verbetert niet alleen de prestaties van de app, maar vermindert ook de kans op fouten en bugs. Stel je voor dat je een formulier hebt met 20 velden en je gebruiker vergeet één veld in te vullen en vervolgens op de knop “Opslaan” klikt. Met partial DOM hydration worden alleen de foutmeldingen weergegeven voor de vergeten velden en hoeft de gebruiker niet alle velden opnieuw in te vullen.
Het is dan ook niet verwonderlijk dat partial DOM hydration een van de meest gevraagde functies is in Angular. Het zal niet alleen de prestaties van de app verbeteren, maar het zal ook de gebruikerservaring verbeteren door het sneller en gemakkelijker te maken om gegevens te bewerken en te valideren.
Signals & fine grained reactivity in Angular
Deze talk werd gedaan door Michael Hladky, een Google Developer Expert, Microsoft MVP, trainer en consultant met een focus op Angular en RxJS. Al jarenlang helpt hij bedrijven en ontwikkelaars bij het opzetten van schaalbare architecturen en prestatiegerichte processen, waardoor teams kunnen bijblijven met de nieuwste ontwikkelingen.
In Angular V16 komt er een heel nieuw concept aan, namelijk signals. Signals kan je vergelijken met Observables van RxJS, maar dan zonder het hele subscription gebeuren.
Je kan hieronder zien hoe je Signals kan integreren met Angular.
Je zet een variable aan `count` en geeft 0 mee als initiële waarde. Om de waarde bij te werken en eventueel te resetten doe je dit met de set-functie. Hier geef je een value aan mee wat de Signal moet bijwerken.
Om een value op te halen kan dit heel simpel met oproepen van de Signal variable.
Stel dat er een andere waarde afhankelijk is van de waarden van andere signalen en opnieuw berekend moet worden wanneer een van die afhankelijkheden verandert. In dat geval kunnen we de computed() functie gebruiken om een nieuwe Signal te maken die automatisch wordt bijgewerkt wanneer de afhankelijkheden veranderen. computed() maakt een memorizing Signal dat zijn waarde berekent op basis van de waarden van een aantal Signals dat meegegeven worden als parameter.
Let wel op dat de computed functie een Signal returned en geen WritableSignal, wat betekent dat deze niet handmatig kan worden aangepast met behulp van methoden zoals set, update of mutate. In plaats daarvan wordt het automatisch bijgewerkt wanneer een van zijn afhankelijke Signals wijzigt.
Hoewel het nog steeds een preview is en er nog enkele wijzigingen kunnen plaatsvinden, kunnen we al experimenteren met de functionaliteiten.
Hetgeen waar ik het meest naar uitkijk, en vooral ga gebruiken, zijn Signals. Huidige change detection in Angular maakt gebruik van zone.js. Vanwege de complexe aard van change detection wordt bij elke wijziging (bijvoorbeeld de uitvoering van een event handler) de hele component hiërarchie opnieuw geëvalueerd voor change detection. Hoewel change detection in Angular efficiënt is, kan het bij grotere toepassingen prestatieproblemen veroorzaken. Daarnaast is een Signal ook een pure function. Het gebruik hiervan creëert geen side-effects waardoor de code predictable en mutable blijft.
Hopelijk hebben jullie iets bijgeleerd uit mijn blog!
Bodhi Vandael
Front-end Crafter
Software developer with knowledge and experience in the big world of programming. Someone with lots of passion, motivation and work ethic. He mainly focuses on building apps with Vue and React in combination with TypeScript. Not scared of writing some back-end code in Laravel or Node.js. But mainly a frontender :). He would love to dive into some more languages in the future!
