Hogyan használjuk az Angular CDK vágólap API-ját különböző helyzetekben?

Az Angular CDK vágólap API-ja egy olyan direktívát és szolgáltatást kínál, amely lehetővé teszi a böngészőn keresztüli interakciót az operációs rendszer vágólapjával. A CdkCopyToClipboard direktíva deklaratív módon használható, míg a Clipboard szolgáltatás olyan esetekben nyújt előnyt, amikor programozott API-ra van szükség. Az API különösen hasznos a hosszú szövegek kezelésében a PendingCopy osztály révén. Az alábbiakban bemutatjuk, hogyan használhatjuk mindkét elemet az Angular CDK csomagban.

A CdkCopyToClipboard direktíva a ClipboardModule-ban található, amely az @angular/cdk/clipboard alcsomag része. Ennek a direktívának a szelektoja: [cdkCopyToClipboard]. A direktívához tartozó bemeneti tulajdonság ugyanezt a nevet viseli, és a másolandó szöveget fogadja el, amikor a hozzá rendelt elemre kattintunk. Mivel a böngészők biztonsági okokból csak akkor engedélyezik a vágólapra másolást, ha a felhasználó által kiváltott kattintás történik, ezért a szöveg másolása csak egy ilyen esemény hatására történhet.

A direktíva rendelkezik egy további bemeneti tulajdonsággal, a cdkCopyToClipboardAttempts-szel, amely megadja a próbálkozások számát, amíg a szöveget a vágólapra másolja, mielőtt feladja a műveletet. Ez különösen nagyobb szövegeknél hasznos, mivel egy implementációs részlet biztosítja a böngészők közötti kompatibilitást, amíg az új vágólap API-t minden jelentős böngésző nem támogatja. A PendingCopy osztályról ebben a fejezetben bővebben is szó lesz.

A direktíva másik fontos tulajdonsága az output esemény, a cdkCopyToClipboardCopied, amely Boolean értéket ad vissza minden egyes próbálkozás alkalmával, és jelzi, hogy a másolás sikeres volt-e.

A PendingCopy osztály egy példányát a Clipboard#beginCopy metódus adja vissza. Az egyik legfontosabb dolog, amit tudnunk kell róla, hogy az összes példányt le kell bontani a PendingCopy#destroy metódussal, miután végeztünk velük, különben alkalmazásunk erőforrást szivárogtathat ki. A PendingCopy#copy metódus nem vár paramétereket, és egy Boolean értéket ad vissza, amely azt jelzi, hogy a másolás sikeres volt-e. Ha false értéket kapunk, újabb próbálkozást kell ütemeznünk.

A CdkCopyToClipboard direktíva és a retry paraméterek segítségével már beszéltünk a nagy szövegek vágólapra másolásának próbálkozási stratégiájáról. Most, hogy részletesen megismerkedtünk az Angular CDK vágólap API-jával, készen állunk arra, hogy alkalmazásunkban a gyakorlatban is használjuk az itt tanultakat.

A PendingCopy osztály és a vágólap API használata tehát fontos eszköz lehet minden Angular alkalmazás számára, amely bonyolultabb interakciókat igényel a felhasználókkal a vágólap kezelésében. Azonban a fejlesztőknek mindenképpen figyelniük kell az eszközök megfelelő használatára és a szükséges erőforrások kezelésére a hatékony alkalmazás létrehozása érdekében.

Hogyan használhatjuk az Angular komponens tesztelési segédleteit?

Az Angular alkalmazásfejlesztés során, amikor UI kódot tesztelünk, gyakran elkerülhetetlen, hogy szorosabban összekapcsolt teszteket végezzünk a DOM struktúrával. Azonban az Angular Ivy új megoldásokat kínál a problémák kezelésére. A komponens tesztelő segédletek (component testing harnesses) lehetővé teszik, hogy olyan tesztelési API-t fejlesszünk ki a komponenseinkhez, amely az ipari szabványnak számító Page Object mintát alkalmazza, ám egy sokkal finomabb szinten. Ezen kívül az Angular Ivy már tartalmazza az Angular Material direktívák és komponensek tesztelő segédleteit is.

A következő szakaszokban bemutatjuk, hogyan használhatjuk az Angular komponensek tesztelési segédleteit és hogyan készíthetünk saját komponens tesztelő segédleteket, hogy megkönnyítsük a komponenseink tesztelését.

Az Angular Material komponens tesztelő segédletei

A Material Button tesztelésének példáját már korábban, a "Az Angular Komponens Funkcióinak Felfedezése" című fejezetben láttuk. Most nézzük meg, hogyan tesztelhetjük a témakomponenst a Material tesztelő segédletekkel, "tesztelés felhasználóként" stratégiával.

typescript
Copy code
it('should be able to read default header background color theme setting', async () => {

  const headerBackground: MatInputHarness = await loader.getHarness(

    MatInputHarness.with({ selector: '#headerBackground' })
  );

  expect(await headerBackground.getValue()).toBe('#00aa00');

});

Itt azt várjuk, hogy az alapértelmezett beállítás '#00aa00' legyen. A tesztelő segédletből a getValue() metódussal olvassuk ki az értéket. Egy bonyolultabb tesztet is építhetünk, amely lehetővé teszi számunkra, hogy megváltoztassuk a fejléc háttérszínének beállítását:

typescript
Copy code
it('should be able to change the header background color theme setting', async () => {

  const headerBackground: MatInputHarness = await loader.getHarness(

    MatInputHarness.with({ selector: '#headerBackground' })
  );

  headerBackground.setValue('#ffbbcc').then(() => {

    expect(themeService.getSetting('headerBackground')).toBe('#ffbbcc');
  });
});

A fenti példában az új értéket '#ffbbcc'-ra állítjuk be, és ellenőrizzük, hogy ez a beállítás bekerült a téma konfigurációba.

Érdemes megjegyezni, hogy a tesztben nem alkalmaztuk a fixture.detectChanges() metódust. Ennek az az oka, hogy a komponens tesztelő segédletet használjuk, amely kezeli a DOM műveleteket. A DOM műveletek használata bonyolult lehet, ha például színválasztót kell tesztelnünk, de a komponens tesztelő segédlet segítségével ezt egyszerűsíthetjük. Így elkerülhetjük a tesztek törékenységét, amelyek a változásokra való érzékenységet okozhatnák.

Komplexebb interakciók tesztelése

Hasonlóképpen, a MatSliderHarness és MatInputHarness segédleteket használhatjuk, hogy elkerüljük a DOM műveleteket a Video Size csúszka beállításainak tesztelésekor:

typescript
Copy code
it('should be able to check default text and video slider settings', async () => {

  const videoSizeSetting = Number(themeService.getSetting('videoSize'));
  expect(videoSizeSetting).toBe(7);

  const videoSizeSlider: MatSliderHarness = await loader.getHarness(

    MatSliderHarness.with({ selector: '#videoSizeSlider' })
  );

  expect(await videoSizeSlider.getId()).toBe('videoSizeSlider');

  expect(await videoSizeSlider.getValue()).toBe(Number(videoSizeSetting));
});

A tesztelő segédlet segítségével könnyedén ellenőrizhetjük a csúszka értékét anélkül, hogy közvetlenül a DOM-hoz kellene hozzáférnünk. Az async/await konstrukcióval együtt a teszt kompakt és könnyen érthető.

Komponens tesztelő segédletek létrehozása

A komponens tesztelésénél fontos, hogy mindig egyetlen referencia pontot használjunk - a DOM-ot - minden egyes oldalhoz. Az alapvető megközelítés, hogy elkezdjük a tesztet a Course komponensből, amely tud a Video komponensről, amely viszont ismeri a YouTube Player komponenst. Így a Course komponensből tesztelhetjük a Video komponens tesztelő segédletét, amely a workspace-video szelektort encapsulálja. Az alábbi kód mutatja be, hogyan:

typescript
Copy code
export class VideoHarness extends ComponentHarness {
  static hostSelector = 'workspace-video';

  protected getTextElement = this.locatorFor('.text');

  async getText(): Promise<string> {

    const textElement = await this.getTextElement();

    return textElement.text();
  }
  textEquals(video: IVideo, text: string): boolean {
    return text?.toLowerCase().trim().includes(video.title.trim().toLowerCase());
  }
}

Most a video címét a getText() metódussal érhetjük el. A textEquals metódussal összehasonlíthatjuk a megjelenített szöveget a várható értékkel:

typescript
Copy code
it('should render the video title in text when displaying it', async () => {

  const renderedVideos = await loader.getAllHarnesses(VideoHarness);

  courseService.getCourse('1').subscribe((course) => {

    renderedVideos.forEach(async (video: VideoHarness) => {

      const text = await video.getText() || "";

      expect(course.videos.find((v) => video.textEquals(v, text))).toBeTruthy();
    });
  });
});

Ez a teszt ellenőrzi, hogy minden egyes megjelenített videó címe helyesen jelenik meg az adott kurzusban, amelyet a Course Service-ből nyerünk ki.

Ezután a Video tesztelő segédlet a YouTubePlayerHarness-t is kapszaulálja, amely az Angular YouTube Player komponenssel kapcsolatos részleteket kezeli. Az alábbi kód mutatja, hogyan építhetjük ezt a tesztelő segédletet:

typescript
Copy code
class YoutubePlayerHarness extends ComponentHarness {
  static hostSelector = 'youtube-player';

  async getVideoId(): Promise<string> {

    const host = await this.host();

    return await host.getAttribute('ng-reflect-video-id');

  }
}

Itt a Video tesztelő segédlet elrejti a YouTube Player implementációs részleteit a Course komponens tesztje elől, így a tesztelés során csak a szükséges funkciókat használjuk.

Hogyan végezzük el az Angular Ivy-re való migrációt a View Engine-ről?

A ViewChild és a View Engine szolgáltatások Angular verzió 8-ban történő migrálásakor, a static opció kötelezővé vált. Eredetileg a ViewChild lekérdezései a következőképpen néztek ki:

typescript
Copy code
@ViewChild('error') errorElement?: ElementRef;
@ViewChild('greeting') greetingElement?: ElementRef;

Az Angular 8-as verzióra történő frissítést követően azonban szükségessé vált a static opció megadása, így a következő módon alakultak át a lekérdezések:

typescript
Copy code
@ViewChild('error', { static: false }) errorElement?: ElementRef;

@ViewChild('greeting', { static: true }) greetingElement?: ElementRef;

A migráció során az Angular képes volt automatikusan meghatározni a legjobb beállítást a static paraméterre. Az olyan elemek, amelyek beágyazott nézetekben találhatók, például egy szerkezeti direktíva által generált elemek, dinamikus lekérdezésekként kezelődnek (static: false). Angular 9-re történő frissítés után a static opció opcionálissá vált, alapértelmezett értéke pedig false lett. Az alábbiakban bemutatott lekérdezésekkel találkozhatunk:

typescript
Copy code
@ViewChild('error') errorElement?: ElementRef;

@ViewChild('greeting', { static: true }) greetingElement?: ElementRef;

Fontos, hogy az Angular Ivy migrálás előtt alaposan átvizsgáljuk a tartalom- és nézetlekérdezéseinket, és konzultáljunk a hivatalos migrációs útmutatókkal, amelyek elérhetők az Angular dokumentációban.

A waitForAsync migráció, amely az async tesztelő callback wrapperének átnevezését tartalmazza, az Angular 11-es verzióban kerül bevezetésre. Ez a változtatás segít elkerülni a zűrzavart az async-await kifejezéssel. Az új elnevezés jobban tükrözi, hogy mi történik, amikor egy teszt esetet egy aszinkron műveletet váró callback-be csomagolunk. Az waitForAsync várakozik minden mikrotasks és makrotasks befejezésére, mielőtt befejeződik a teszt.

A @Injectable és a hiányzó provider definíciók migrációja az Angular 9-es verzióban automatikusan hozzáadja az @Injectable dekorátort a modul szolgáltatásainak osztályaihoz. Ez különösen fontos a class-based modul szolgáltatások esetében, mivel a View Engine és Angular Ivy eltérően értékelik őket. Azok a modulok, amelyek nem rendelkeznek @Injectable dekorátorral, értékeként undefined-ot adnak vissza, így a migrációs folyamat során automatikusan hozzáadódik a szükséges dekorátor. A migrálás után ellenőrizzük a useValue: undefined részt, mivel valószínűleg nem ez volt az alkalmazásunk szándéka.

Az Angular CLI verzió 12 automatikusan a production módra állítja be a projekt alapértelmezett konfigurációját. Ez azt jelenti, hogy nem szükséges minden alkalommal megadni a --configuration=production parancsot a ng build során. Azonban a meglévő projektek nem kerülnek automatikusan átállításra erre az új alapértelmezett beállításra, így az opcionális migrációs folyamat segíthet a meglévő projektek frissítésében.

A kézi migrációs lehetőségek is fontosak, hogy az Angular Ivy alkalmazásunk készen álljon a jövőbeli verziókhoz. Az elsődleges navigáció kezelésében például eltávolításra kerültek a régi értékek, mint a true, false, legacy_enabled és legacy_disabled, és helyettük az új enabledBlocking és enabledNonBlocking értékek kerültek bevezetésre. Az előbbi az Angular Universal használatakor javasolt, mivel a gyökérkomponens indítása előtt elindítja az elsődleges navigációt.

Migráláskor mindig vegyük figyelembe a jövőbeli fejlesztésekhez szükséges változtatásokat, hogy a projektünk mindig az Angular legújabb verzióihoz igazodjon.

Hogyan befolyásolja az Angular Ivy az alkalmazás fejlesztési folyamatát és a tesztelést?

Az Angular Ivy bevezetése jelentős változásokat hozott az Angular alkalmazások fejlesztésében, különösen a teljesítmény, a típusbiztonság és a tesztelés terén. A változások hatással vannak a fejlesztők napi munkájára, a hibák kezelésére, és a kód karbantartásának hatékonyságára is. Az alábbiakban áttekintjük, hogyan változott az Angular tesztelése az Ivy bevezetésével, és milyen új eszközök állnak a fejlesztők rendelkezésére.

Az Angular Ivy egyik legfontosabb újítása az, hogy alapértelmezetten a "Ahead-of-Time" (AOT) fordítót használja minden fejlesztési fázisban, beleértve a tesztelést is. Ez az új fordító jelentős előnyöket biztosít, például gyorsabb fordítást és kisebb alkalmazáscsomagokat, de néhány hátrányt is hozhat, különösen a hibák kezelésében és az aszinkron függőségek inicializálásában.

Az AOT fordítóval kapcsolatos egyik legfontosabb újítás a TestBed.inject statikus módszer, amely a gyengébben típusos TestBed.get módszert váltja fel. A TestBed.get visszaadott értéke any típusú volt, így gyakran előfordult, hogy a fejlesztők nem jelezték a visszaadott érték típusát. Az új TestBed.inject módszer erősen típusos, tehát most már kötelező megadni a megfelelő típusokat a tesztelt szolgáltatások számára. Ez javítja a típusbiztonságot, és csökkenti a hibák esélyét a fejlesztési folyamat során.

A TestBed.inject és a régi TestBed.get között a legfontosabb különbség az, hogy az új módszer szigorúbb típusellenőrzést végez, és csak a megfelelő típusú provider tokenek fogadását engedélyezi. A korábban támogatott gyenge típusú provider tokenek, mint a stringek, számok vagy szimbólumok, már nem támogatottak, mivel ezek elavultak az Angular 4-es verziója óta. Az új módszer lehetővé teszi, hogy a tesztelők és fejlesztők pontosabban meghatározzák a függőségek típusát, és elkerüljék a futásidőben fellépő hibákat.

A tesztelés során fontos szem előtt tartani, hogy a TestBed.inject módszer nemcsak a típusokat ellenőrzi, hanem az injektált függőségek kezelését is szigorúbbá teszi. Ha a megadott típus nem egyezik meg a provider token típusával, akkor először az értéket unknown típusra kell konvertálni, majd a kívánt típusra. Ez különösen hasznos lehet, ha stub-okkal vagy mock-okkal dolgozunk, mivel ez segít megelőzni a típushibákat és biztosítja, hogy a tesztek a várt módon működjenek.

Mindezek mellett az Angular Ivy további előnye, hogy az AOT fordító révén a kódot már a fejlesztési fázisok elején fordítja le, így a hibák már korábban kiderülnek. Ez lehetővé teszi, hogy a fejlesztők gyorsabban reagáljanak a problémákra, és megelőzzék a runtime-ban felmerülő hibákat. Az AOT előnyei különösen akkor nyilvánvalóak, ha kis vagy közepes méretű alkalmazásokat fejlesztünk, mivel a bundle mérete csökkenthető, és a kód futtatása gyorsabbá válik.

Az AOT fordító hatékonysága azonban nem minden alkalmazás esetében egyformán érvényesül. A komplexebb alkalmazások esetében előfordulhat, hogy a fő csomag mérete megnövekszik, miközben a lazy-loaded kódrészek mérete csökken. Ezzel párhuzamosan azonban a nagyobb fő csomag mérete hosszabb betöltési időket eredményezhet, így a fejlesztőknek mérlegelniük kell a trade-offokat, amikor az Ivy vagy a View Engine közötti választásra kerül sor.

Fontos tehát, hogy a fejlesztők tisztában legyenek az Ivy által hozott változásokkal, és alaposan mérlegeljék, hogyan befolyásolják ezek a tesztelési és fejlesztési folyamataikat. Az Angular Ivy használatával a fejlesztési sebesség növekedésére és a kód minőségének javulására lehet számítani, azonban az új funkciók és eszközök megfelelő alkalmazása kulcsfontosságú a problémák elkerülése érdekében. Az alapos tesztelés, a típusbiztonság javítása és az aszinkron függőségek megfelelő kezelése mind hozzájárulnak a sikeres migrációhoz és a magas színvonalú Angular alkalmazások fejlesztéséhez.