Az alkalmazásunk „járó vázát” azzal a céllal alakítottuk ki, hogy a menedzser szerepét betölthesse. Ahhoz, hogy hozzáférhessünk az általunk létrehozandó összes komponenshez, szükség van arra, hogy a menedzsert felhatalmazzuk a POS és készlet modulok elérésére. A következőkben két új gombot kell hozzáadni a ManagerComponent-hez:

ts
src/app/manager/manager.component.ts

Ezek a router linkek olyan helyekre irányítanak, amelyek kívül esnek a ManagerModule-on, ezért teljesen természetes, hogy a menedzser-specifikus másodlagos eszköztár eltűnik. A következő lépés a két új modul megvalósítása, melyhez magas szintű lépéseket biztosítok, valamint utalásokat adok egy korábbi modulra, amely alapján modellezheted az újakat. Ha elakadnál, nézd meg a projects/stage7 mappát a GitHub projektben.

PosModule

A PosModule nagyban hasonlít a UserModule-ra, azonban a PosModule alapértelmezett útvonal volt, így az alapértelmezett komponens a PosComponent lesz. Mivel ez a komponens bonyolulttá válhat, sok alkomponenssel, ezért nem ajánlott inline sablonok vagy stílusok használata. A következő lépéseket kell követnünk:

  1. Hozd létre a PosComponent-et.

  2. Regisztráld a PosComponent-et alapértelmezett útvonalként.

  3. Konfiguráld a késleltetett betöltést a PosModule-hoz.

  4. Ellenőrizd, hogy az alkalmazás működik-e.

InventoryModule

A InventoryModule hasonlóan a ManagerModule-hoz, az alábbi módon valósítható meg:

  1. Hozd létre az alap Inventory komponenst.

  2. Regisztráld a MaterialModule-ot.

  3. Hozd létre a Inventory Home, Stock Entry, Products, és Categories komponenseket.

  4. Konfiguráld a szülő-gyermek útvonalakat az inventory-routing.module.ts-ben.

  5. Konfiguráld a késleltetett betöltést az InventoryModule-hoz.

  6. Valósíts meg egy másodlagos eszköztárat az InventoryComponent belső navigációjához.

  7. Ellenőrizd, hogy az alkalmazás működik-e.

Tesztelés és Hibajavítás

Miután a vázlatos alkalmazás kész, elengedhetetlen, hogy átvizsgáld a CLI kimenetét, hogy megbizonyosodj arról, hogy minden várt modul és komponens késleltetve van betöltve. Fontos, hogy minden tesztelési hibát javíts meg, mielőtt továbblépsz. A következő parancsok futtatásával ellenőrizheted az alkalmazás működését:

bash
npm test
npm run e2e

Közös Tesztelési Modul

Most, hogy sok modulunk van, fáradságossá válik az importok és szolgáltatók konfigurálása minden egyes teszt fájlhoz külön-külön. Ehhez létrehozhatunk egy közös tesztelési modult, amely tartalmazza azokat az alapértelmezett beállításokat, amelyeket újra felhasználhatunk.

  1. Hozd létre a common/common.testing.ts fájlt.

  2. Töltsd fel közös tesztelési szolgáltatókkal, hamisított komponensekkel és modulokkal.

ts
import { HttpClientTestingModule } from '@angular/common/http/testing';


import { ReactiveFormsModule } from '@angular/forms';


import { NoopAnimationsModule } from '@angular/platform-browser/animations';


import { RouterTestingModule } from '@angular/router/testing';


import { MatIconTestingModule } from '@angular/material/icon/testing';


export const commonTestingModules = [
    ReactiveFormsModule,
    NoopAnimationsModule,
    HttpClientTestingModule,
    RouterTestingModule,
    MatIconTestingModule,
] as unknown[];

Ezzel a közös tesztelési beállítással gyorsíthatjuk a tesztelési folyamatot, de figyeljünk arra, hogy ne töltsük túl sok felesleges modullal a rendszert.

CI Pipeline a Teszteléshez

Ahhoz, hogy mindig biztosak legyünk abban, hogy a tesztjeink sikeresek, érdemes CI pipeline-t alkalmazni. A CircleCI segítségével automatikusan tesztelhetjük az alkalmazásunkat a kód kiadás előtt. A CI/CD folyamatról bővebben a 10. fejezetben olvashatsz, amely bemutatja a CI pipeline létrehozását és az alkalmazás kiadását.

Az Adatok Entitások Mentén Történő Tervezése

A következő lépés a router-alapú architektúra negyedik szintje, a stateless, adatalapú tervezés megvalósítása. Ehhez először is az API-kat kell az alapvető adatkomponensek köré szerveznünk. Ez a felépítés hasonló ahhoz, ahogy az Angular alkalmazásunk különböző komponenseiben dolgozunk az adatainkkal. Az adatok entitásainak meghatározása fontos lépés, amit az alábbiakban mutatok be egy példán keresztül:

A fenti mintát alapul véve, az adatok tárolásához bármilyen adatbázist választhatunk, azonban ha rugalmas megoldást keresünk, a NoSQL alapú MongoDB lehet a legjobb választás, mivel jobban alkalmazkodik a változó követelményekhez.

Felhasználói Élmény és Alkalmazás Felépítése

A felhasználói élmény (UX) kialakításakor fontos, hogy az alkalmazás könnyen navigálható legyen, és az összes szükséges funkció és adat könnyen hozzáférhető legyen. A képernyőtervek és a mock-upok segítenek abban, hogy meghatározzuk a szükséges komponenseket és vezérlőelemeket, amelyek az alkalmazás alapvető részét képezik.

A Wikik Fontossága a Fejlesztési Folyamatban

A projekt során minden létrehozott tervezési anyagot érdemes dokumentálni egy wiki oldalon, amelyet a csapat minden tagja könnyen elérhet. A Slack, Teams vagy e-mail rendszerek jó kommunikációs eszközök, de nem biztosítanak tartós dokumentációt. A wiki egy élő dokumentációs rendszer, amely lehetővé teszi a csapat számára, hogy folyamatosan frissítse és hozzáférjen a projekt különböző alkotásaihoz, mint például a mock-upok vagy a tervezési döntések.

Hogyan kezeljük az űrlapadatok dinamikus megjelenítését és mentését Angularban?

A modern webalkalmazások egyik legfontosabb eleme a dinamikusan kezelhető, többlépcsős űrlapok implementálása. Az Angular keretrendszerben a FormArray és a template-ben definiált inline függvények segítségével egyszerűbbé és átláthatóbbá válik a felhasználói adatok bevitele, kezelése és ellenőrzése. Egy ilyen többlépcsős űrlap esetében a folyamat végén a felhasználó az összes begyűjtött adatot egyetlen áttekintő nézetben ellenőrizheti, majd mentheti el.

A felhasználói profil megjelenítésére szolgáló komponens (például a viewUser komponens) az @Input() dekorátor használatával fogadja be a kívülről érkező adatokat, amelyek megfelelnek az IUser interfésznek. A komponens életciklusában az ngOnChanges metódus gondoskodik arról, hogy az egyszerű JSON objektum adatokat egy összetettebb, metódusokat is tartalmazó User osztállyá alakítsa át, ezzel lehetővé téve a számított tulajdonságok, mint például a teljes név, helyes megjelenítését. Ez a konverzió megakadályozza, hogy a megjelenítés során csak nyers adatokat kezeljünk, és ezáltal növeli az alkalmazás robusztusságát.

A legújabb Angular verziók (például a 17.1) már jeleznek áttérést a jelzésalapú (signal-based) komponensek irányába, amelyek jelentősen csökkentik a változásfigyelés által okozott teljesítménybeli terhelést. Ez a fejlesztés lehetőséget ad arra, hogy a jövőben könnyebben kezeljük a komplex adatokat, és hatékonyabbá tegyük a felhasználói felületeket.

A többlépcsős űrlap utolsó lépése az összegzés, ahol a felhasználó áttekintheti a megadott adatokat, majd mentheti azokat. A mentés során egy aszinkron HTTP POST kérés küldődik, melynek sikeres válasza visszaadja a mentett adatokat. Ezeket az adatokat a forma automatikusan frissíti a formGroup.patchValue() metódussal, amely gondoskodik arról, hogy az űrlap mindig a szerver által jóváhagyott adatokat tartalmazza. Ez a megoldás biztosítja, hogy az esetleges szerveroldali változtatások vagy validációk eredményei azonnal megjelenjenek a felhasználó számára. Hiba esetén az üzenetek megjelennek az űrlapon, ezzel segítve a hibák gyors javítását.

Az űrlap visszaellenőrzéséhez egy újrahasználható komponens (például app-view-user) szolgál, amely a megadott adatokat kompakt módon jeleníti meg. A felhasználói élményt tovább növeli, hogy az űrlap egyszerűen visszaállítható a stepper.reset() hívásával, így a felhasználó bármikor kezdheti újra a bevitel folyamatát.

Fontos, hogy az ilyen komplex űrlapok fejlesztése során figyeljünk az alkalmazás architektúrájára. A hibás vagy túlzottan összetett kód akár a fejlesztési költségek növekedéséhez és a karbantarthatóság romlásához vezethet. Éppen ezért érdemes a formát részekre bontani és újrahasználható komponensekre építeni. Ez a megközelítés lehetővé teszi, hogy még nagyszámú mező esetén is könnyen módosítható és bővíthető maradjon az alkalmazás anélkül, hogy exponenciálisan növekedne a hibalehetőségek száma.

Az Angular formok mélyebb megértése megköveteli, hogy az olvasó tisztában legyen a komponens alapú adatkezelés, az életciklus-horgok, valamint az aszinkron adatfolyamok (például Observable-k) működésével. Ezen felül fontos a validációk helyes alkalmazása, és annak felismerése, hogy a szerverrel való adatcsere nem egyszerű adatküldés, hanem a kliens-oldali állapot folyamatos szinkronizálása a valós adatokkal. A hatékony kód újrafelhasználás és a jövőbeni keretrendszer-fejlesztésekre való felkészülés (például a signal-alapú inputok) hosszú távon fenntartható, gyors és stabil alkalmazások készítését teszi lehetővé.

Hogyan érhetünk el folyamatos integrációt és automatizált tesztelést Angular alkalmazásokban?

A fejlesztők gyakran azzal a magyarázattal élnek, hogy “De nálam működik!”, amikor a szoftverek hibásan működnek, vagy nem teljesítenek elvárt módon. Az egyik kulcsfontosságú tényező a szoftverek hibamentes működésének biztosítása érdekében a folyamatos integráció (CI) és a folyamatos telepítés (CD) alkalmazása. A CI/CD pipeline-ok lehetővé teszik a gyors, megbízható és gyakori kiadások elérését, miközben biztosítják a kód minőségét és stabilitását. Ez a gyakorlat különösen fontos vállalati környezetekben, ahol a gyors ütemű fejlesztés mellett elengedhetetlen a stabilitás.

A CI/CD rendszerek megvalósítása nemcsak a kód integrálásáról szól, hanem a fejlesztési és telepítési folyamatok automatizálásáról is, amelyek lehetővé teszik, hogy a kódot folyamatosan ellenőrizzük és deploy-oljunk a felhőbe, minimalizálva ezzel az emberi hibák lehetőségét. A folyamatos tesztelés a rendszer szerves része, mivel segít biztosítani, hogy az új változtatások ne okozzanak regressziókat, és hogy minden egyes módosítás valóban javítja a rendszer teljesítményét és funkcióit.

A fejlesztés során gyakran találkozunk a kihívással, hogy a szoftveres hibákat és a nem megfelelő működést a legnagyobb szakszerűséggel is kijavítsuk. Ilyenkor a CI/CD folyamatait beépíthetjük a rendszerbe, hogy minden egyes változás tesztelve legyen. A tesztelés az egyik legfontosabb rész, amely lehetővé teszi, hogy a kódot stabil állapotban tartjuk, miközben folyamatosan fejlődik.

A CI/CD folyamatok során a GitHub és a CircleCI kulcsfontosságú szereplők, és az alkalmazásokat gyakran Docker alapú konténerekbe csomagoljuk. A Docker lehetővé teszi, hogy a fejlesztők és üzemeltetők ugyanazt a környezetet használják, amely megkönnyíti a telepítési hibák elkerülését, valamint biztosítja a rendszer hordozhatóságát különböző infrastruktúrák között.

A tesztelési és fejlesztési folyamatok során elengedhetetlen, hogy az alkalmazásokat többféle teszttel vizsgáljuk. Az unit tesztek és az end-to-end (e2e) tesztek, mint például a Cypress használata, elengedhetetlenek a folyamatos integrációhoz. Az e2e tesztelés során az egész alkalmazást szimuláljuk, így biztosítva, hogy a felhasználói interakciók és az üzleti logika megfelelően működjenek.

Ezen kívül az infrastruktúra kódba integrálása (IaC) lehetővé teszi, hogy az alkalmazásokat ne csak a fejlesztés során, hanem az üzemeltetési környezetben is automatizált módon telepítsük és ellenőrizzük. Az IaC segítségével elérhetjük, hogy a környezetek mindig szinkronban legyenek a kódunkkal, elkerülve az infrastrukturális eltérésekből adódó problémákat.

A CI/CD folyamatok bevezetése nemcsak technikai előnyöket biztosít, hanem segíti a csapatok közötti együttműködést is. Mivel a kód minden egyes változása gyorsan és automatizált módon kerül tesztelésre, a csapatok számára világossá válik, hogy mikor és hogyan történnek a hibák, valamint könnyebben azonosíthatják a problémás részeket. Az egész folyamat folyamatos kommunikációt igényel a fejlesztők és az üzemeltetők között, hogy mindenki biztos lehessen abban, hogy a végfelhasználók számára biztosított szoftver megfelel a minőségi elvárásoknak.

Továbbá, az automatizált tesztelés nemcsak a rendszer hibáinak elkerülését segíti elő, hanem a fejlesztési időt is lerövidíti. Mivel a kód gyorsan tesztelhető, a fejlesztők gyors visszajelzést kapnak a változtatásaikról, és ha valami nem működik, azt azonnal kijavíthatják, mielőtt nagyobb problémákhoz vezetne. A CI/CD rendszer tehát nemcsak a hibák elkerülésében segít, hanem a fejlesztési ciklusok felgyorsításában is.

Az alkalmazások telepítése és kezelése során kulcsfontosságú szerepe van a felhőszolgáltatásoknak, mint a Vercel és a Firebase, amelyek a CI/CD folyamatokat támogatják. Ezek a szolgáltatások lehetővé teszik, hogy az alkalmazásokat gyorsan és megbízhatóan telepítsük a felhőbe, miközben biztosítják a rugalmas skálázhatóságot és a globális elérhetőséget. A CircleCI és a Docker segítségével pedig egyszerűsíthetjük a telepítési folyamatokat, elérve a kód újrafelhasználhatóságát különböző környezetekben.

A fejlesztők számára elengedhetetlen, hogy mindig a legfrissebb verziót használják, és folyamatosan figyeljék a kód és az infrastruktúra frissítéseit. Mivel a CI/CD rendszerek és a kapcsolódó eszközök, mint a Docker és a CircleCI, gyorsan fejlődnek, a fejlesztőknek is folyamatosan alkalmazkodniuk kell az új változásokhoz. A GitHub és a különböző tesztelő rendszerek segítségével a kód karbantartása és monitorozása hatékonyan végezhető el, garantálva a magas szintű minőséget és megbízhatóságot.

Hogyan érhetjük el a tartós felépülést a szenvedélybetegségekből?
Hogyan segíthet a Coroot az alkalmazások megfigyelésében és a problémák megelőzésében a felhőalapú környezetekben?
Hogyan befolyásolják a kétnyelvű szótárak a nyelvtanulást és a szókincset?