Hogyan különbözik az Angular az MVC és MVVM megközelítésektől, és mit kell tudni a fejlesztőknek?

Az Angular alkalmazások fejlesztése során a legfontosabb különbség a hagyományos MVC (Model-View-Controller) és az MVVM (Model-View-ViewModel) architektúrák között az adatbinding mechanizmus. Míg az MVC rendszerekben, mint például a Backbone vagy a React, külön render metódusokat kell hívni a HTML sablonok feldolgozásához, az Angularban ez a folyamat a fejlesztő számára teljesen átlátható és zökkenőmentes. Az adatbinding, amely az Angular egyik fő jellemzője, alapvetően különbözik az MVC-től, és az MVVM-ben található.

A DI segítségével az Angular rendkívül rugalmas, és könnyen kezelhetők az egymástól függő szolgáltatások, mivel nem kell aggódniuk azok létrehozásának, inicializálásának vagy törlésének sorrendje miatt. Az Angular sablonok olyan struktúrákat is lehetővé tesznek, amelyek kódújrahasználást biztosítanak különböző direktívák, csövek (pipes), felhasználói vezérlők és egyéb komponensek formájában. Ez a kódújrahasználás lehetővé teszi, hogy az interaktív felhasználói felületek, amelyek gyakran bonyolultak, elkülönüljenek az üzleti logikától vagy a megjelenítési logikától, ezáltal fenntarthatóbbá téve a kódot.

Az Angular 17-es verziója új vezérlési áramlási szintaxist vezetett be, amely a régi direktívák, mint a *ngIf, *ngFor és *ngSwitch helyett az @if, @for, @switch szintaxist alkalmazza. Ezen kívül új elemeket is tartalmaz, mint az @empty, @defer, kontextuális változók és feltételes kifejezések. Az új szintaxis célja, hogy könnyebbé tegye a sablonok olvasását, és elkerülje a régi direktívák minden komponensbe történő importálását egy önálló projektben. Az új szintaxis a könyvben kizárólagosan szerepelni fog, és lehetőséget ad arra is, hogy a meglévő sablonokat új szintaxisra konvertáljuk.

Angular alkalmazásokat két különböző módon lehet létrehozni: egy NgModule projektként vagy önálló projekteként. Az Angular 17 verziója szerint az alapértelmezett módszer az, hogy az alkalmazásokat önálló projektekként indítjuk. Ez az új megközelítés számos előnnyel jár, amelyeket az Angular Router szekció alatt részletesebben is bemutatunk. Azonban a modulok fogalma nem tűnt el, csupán nem kötelezőek a projektek számára. Akár bootstrapApplication, akár bootstrapModule használatával indítjuk az alkalmazást, az Angular komponensei, szolgáltatásai, direktívái, csövei és felhasználói vezérlői elérhetők a bootstrapApplication függvény számára, vagy egy modulokon keresztül vannak megszervezve. Az alkalmazás gyökérszintű konfigurációja biztosítja az első komponens renderelését, a szolgáltatások befecskendezését és az esetlegesen szükséges függőségek előkészítését.

A stand-alone komponensek nem keverendők össze az Angular elemekkel, amelyek a webes szabványoknak megfelelően valósítják meg az egyedi elemeket, más néven Web Components-t. Az Angular elemek megvalósítása jelentős csökkentést eredményezne a keretrendszer méretében, lehetővé téve, hogy az Angular komponensek más webalkalmazásokban is felhasználhatók legyenek, ezzel a megoldással jelentős előnyöket hozva a webfejlesztésben.

Az Angular erőteljesen használja az RxJS könyvtárat, amely reaktív fejlesztési mintákat vezet be az alkalmazásokba, ezzel szemben a hagyományos imperatív fejlesztési minták helyett. Az RxJS lehetővé teszi, hogy a fejlesztők aszinkron adatfolyamokkal dolgozzanak, amelyek kompozíciója és transzformálása a reaktív programozás alapelveinek megfelelően történik. Az Angularban alkalmazott reaktív programozás lehetőséget ad arra, hogy a fejlesztők különböző programozási stílusokban dolgozhassanak, attól függően, hogy objektumorientált vagy funkcionális programozásban szerzett tapasztalataik vannak.

A hagyományos imperatív programozás során a fejlesztőnek minden egyes lépést külön kell meghatároznia, és a logika szoros függőségben van az előző lépésektől. Ezzel szemben a reaktív programozás során az adatok aszinkron módon áramlanak, és az adatfolyamokat kompozícióval alakíthatjuk át, hogy az elvárt eredményeket elérjük. A reaktív programozás tehát lehetőséget ad arra, hogy a program logikai lépései egymástól függetlenül, egyszerűen és tisztán legyenek definiálva.

Hogyan oldjuk meg a teljesítménybeli problémákat az Angular alkalmazásokban?

A modern webalkalmazások teljesítménye kulcsfontosságú tényező, amely közvetlenül befolyásolja a felhasználói élményt. Az Angular és hasonló SPA (Single Page Application) keretrendszerek esetében számos olyan probléma adódhat, amely lassíthatja a betöltést és a működést. Az alábbiakban a leggyakoribb teljesítménybeli problémákra és azok megoldásaira koncentrálunk, beleértve a JavaScript betöltési és végrehajtási folyamatokat, a hibernálási kérdéseket, valamint a modern megoldásokat, mint a minimalista JavaScript könyvtárak és az SSR (Server-Side Rendering).

A legtöbb alkalmazás kezdő lépése az, hogy letölti a szükséges JavaScript fájlokat, amelyek tartalmazzák az alkalmazás logikáját, a keretrendszert és harmadik féltől származó könyvtárakat. Ahogy ezek a fájlok egyre nagyobbak lesznek, úgy egyre lassabban töltődnek be. A következő lépés, hogy a JavaScript kódot a böngésző letölti, de azt előbb ki kell csomagolni és memóriába tölteni, majd a JavaScript motor végrehajtja a kódot. Ezen kívül a DOM (Document Object Model) elemeket is fel kell építeni és a framework hook-okat kell inicializálni. A következő fázisban a framework megkezdi az alkalmazás állapotának számítását és vizuális megjelenítését, miközben a felhasználói eseményekhez kapcsolódó eseménykezelőket is hozzárendeli. Végül, ha minden jól működik, a változásdetektálás során a keretrendszer átvizsgálja a komponensfát, hogy meghatározza, frissíteni kell-e az alkalmazás felhasználói felületét a belső állapot változásai alapján.

Ezek a lépések mindaddig nem okoznak problémát, amíg az alkalmazásunk kódja nem tartalmaz komoly hibákat. Azonban ha az alkalmazásunk növekszik, vagy komplexebb funkcionalitásokat kell megvalósítanunk, akkor a következő problémák léphetnek fel:

1. A túl nagy JavaScript fájlok lassítják a betöltést. Az egyre bővülő alkalmazás és a harmadik féltől származó könyvtárak miatt a letöltött fájlok mérete gyakran túllépheti a kívánt határokat.

2. A túl sok interaktív komponens megjelenítése. Ahelyett, hogy csak a szükséges elemeket renderelné a keretrendszer, mindent egyszerre kell megjeleníteni, ami jelentősen rontja a teljesítményt. Ennek kiküszöbölésére gyakran kézzel kell módosítani a komponensek életciklusát, hogy a keretrendszer szokásos működése helyett gyorsabb megoldásokat alkalmazzunk.

3. Változásdetektálás. Mivel a SPA alapú alkalmazások folyamatosan figyelik az állapotváltozásokat, minden egyes változtatás esetén a teljes komponensfa újra kiértékelődik, ami rendkívül időigényes lehet.

Az ilyen problémák kezelése érdekében sok fejlesztő minimalista megoldásokhoz nyúl, amelyek csökkentik a szükséges JavaScript kód mennyiségét. Az ECMAScript 2022 például számos olyan funkciót biztosít, amelyek lehetővé teszik a gyorsabb és reagálóbb webalkalmazások fejlesztését anélkül, hogy egy nagy keretrendszert kellene használni. Az ArrowJS könyvtár egy ilyen példa, amely mindössze 1-2 kb-nyi kódot tartalmaz, mégis lehetővé teszi a teljesítmény jelentős javítását. Justin Schroeder előadásában, amelyet a Frontrunners 2023 konferencián hallgattam meg, bemutatta a könyvtár működését, amely a gyenge referenciákon alapuló WeakMap, a middleware típusú Proxy, és az egyedi string interpolációval rendelkező Tagged template literals alkalmazásával biztosít hatékony működést.

Azonban egy másik megoldás, amely ugyanazokat az alapvető technológiai megoldásokat alkalmazza, de teljesen új szemléletmódot képvisel, a Qwik.js. A Qwik.js az Angular megalkotójától, Miško Heverytől és más iparági szakértőktől származik, és célja, hogy megoldja azokat a mélyebb problémákat, amelyeket a népszerű SPA keretrendszerek, mint az Angular, React és Vue, nem tudtak elkerülni. A Qwik.js segítségével a fejlesztők egy olyan alkalmazást hozhatnak létre, amely mindössze 1 kb-nyi kódból képes működni, és amely az állapotot nem hibernálja, hanem az alkalmazás egyszerűen és gyorsan renderelhető HTML payload-ként kerül letöltésre.

A Qwik.js azon képessége, hogy az alkalmazás egyes funkcióit szükség szerint tölti be, valamint az agresszív késleltetett kódvégrehajtás segít abban, hogy az alkalmazás ne pazarolja az erőforrásokat. Az egyes elemek csak akkor kezdenek el működni, amikor a felhasználó interakcióba lép velük. Ez a megoldás drámaian javítja a teljesítményt, és a webalkalmazás több szempontból is dinamikusan reagálhat a felhasználói tevékenységekre.

A webalkalmazások fejlesztése során tehát érdemes figyelmet fordítani az alkalmazás betöltési idejére, a kód hatékonyságára, valamint a keretrendszerek működésére. A Qwik.js és az ArrowJS hasonló megoldásokat kínálnak, de mindkettő különböző módon közelíti meg a problémát. Az ilyen minimalista JavaScript megoldások nemcsak a fejlesztők számára teszik gyorsabbá és egyszerűbbé az alkalmazás készítését, hanem jelentősen javítják a felhasználói élményt is.

A webfejlesztők számára fontos, hogy megértsék, mikor érdemes inkább egy minimalista megoldást választani, és mikor szükséges egy teljesebb keretrendszer, például az Angular vagy a React. A teljesítmény optimalizálása érdekében célszerű kerülni a túlzott kódbetöltést, és alkalmazni a késleltetett kódvégrehajtást és az egyes komponensek aszinkron kezelését, amelyek javíthatják az alkalmazások reakcióidejét és csökkenthetik a rendszer erőforrás-igényét.

Hogyan javítható a fejlesztői élmény a modern webalkalmazások építése során?

Az alkalmazásfejlesztés folyamatosan fejlődő világában kulcsfontosságú a megfelelő eszközök és módszerek kiválasztása a hatékony munkafolyamatokhoz. A fejlesztői élmény (DevEx) javítása érdekében számos eszközt és technikát vehetünk igénybe, amelyek nemcsak a sebességet növelik, hanem a kódolás során felmerülő problémákat is minimálisra csökkenthetik. Az alábbiakban bemutatott fejlesztői eszközök és gyakorlatok kulcsszerepet játszanak abban, hogy egy modern, skálázható webalkalmazást gyorsan és hatékonyan építhessünk meg.

Az Nx az automatikus függőségfrissítést is lehetővé teszi, amely egy időigényes és fontos karbantartási feladatot végez el a webprojektek számára. A fejlesztőknek nem kell manuálisan figyelemmel kísérniük a függőségek frissítéseit, mivel ezt az eszköz automatikusan végzi el. Az Nx-ról további információkat találhatunk a https://nx.dev/ weboldalon.

A Cypress a modern tesztelés egyik legjobb eszköze, és a régi, elavult tesztelő eszközök, mint a Karma és a Jasmine, helyett használható. A Cypress különösen az e2e (end-to-end) tesztelésre lett kifejlesztve, de alkalmassá vált komponens tesztek írására is. A Cypress egy fekete doboz tesztelési megközelítést alkalmaz, amely könnyebbé teszi az új tesztek írását, de nem nevezhető hagyományos egység tesztelésnek. Ha az összes új tesztelési eszközt és technológiát sikeresen integráljuk, az Angular egy erősebb, jövőálló keretrendszerré válhat. A jövőben a Qwik.js is érdekes alternatívát jelenthet azok számára, akik kiemelten fontosnak tartják a teljesítményt.

A GitHub projekt setup-jához a következő lépéseket érdemes követni:

1. Lépjünk be a GitHub repóba.

2. Nyissuk meg a Projects fület.

3. Kattintsunk az "Új projekt" opcióra.

4. Adjunk nevet a projektnek.

5. Válasszuk a Team backlog sablont.

6. Kattintsunk a "Létrehozás" gombra.

Ezzel egy egyszerű Kanban tábla jön létre, amely segíti a feladatok nyomon követését és azok időben történő elvégzését. A Kanban táblák egyik legnagyobb előnye, hogy biztosítják a transzparenciát és segítenek a feladatok kezelésében, miközben biztosítják a csapat számára a folyamatos, valós idejű információkat.