Hogyan kezeljük a kisebb képernyők elrendezését egyedi CSS tulajdonságokkal és média lekérdezésekkel?

A kisebb képernyőkön történő elrendezés kezelésére szükség van egy sor egyedi szempont figyelembevételére. Az ilyen típusú igényekkel való munka komplexitása miatt gyakran elkerülhetetlen a testreszabott témák alkalmazása. Ugyanakkor, ha jól ismerjük a CSS Grid és a média lekérdezések kombinálásának módszereit, akkor egy kompakt és könnyen érthető megoldást érhetünk el anélkül, hogy túlságosan bonyolult kódot kellene írni. A videó- és szövegstílusú CSS osztályok bevezetésével és egyedi CSS tulajdonságok használatával, miközben a tartály (container) grid oszlopait is figyelembe vesszük, az elrendezés egyszerűen kezelhetővé válik.

Vegyünk egy példát egy CSS osztályra, amely a videókat és a szövegeket kezeli:

css
Copy code
.tile {

  background: var(--tilebackground, grey);
  padding: 15px 15px 15px;
  overflow: hidden;
  &.video {
    grid-column: span var(--videosize, 9);
  }
  &.text {
    grid-column: span var(--textsize, 3);
  }
}

Ebben az esetben a videó méretének és a szöveg méretének CSS tulajdonságai határozzák meg, hogy hány oszlopot foglal el az adott elem. A tartály grid-jének deklarációja így nézhet ki:

css
Copy code
.container {
  display: grid;

  grid-template-columns: repeat(12, 1fr);

  grid-template-rows: 1fr;
  grid-auto-flow: dense;
  padding: 15px 15px 15px;
  align-content: center;
}

Ezeket az új CSS osztályokat a Course komponensben kombinálhatjuk, hogy a videókat a hozzájuk tartozó szöveges leírásokkal jelenítsük meg. A megfelelő méretek szabályozása érdekében bevezethetünk két új változót a téma komponensbe: a videó méretét és a szöveg méretét. Ezeket a változókat az elérhető oszlopok száma (ebben az esetben 12) határozza meg. Érdemes úgy beállítani, hogy ezek az értékek összege megegyezzen a grid oszlopainak számával.

A videó méret és a szöveg méretét szabályozó csúszkák a téma kiválasztójában is megjelenhetnek:

html
Copy code
<mat-slider [(ngModel)]="videoSize" min="3" max="7"></mat-slider>
<mat-slider [(ngModel)]="textSize" min="1" max="5"></mat-slider>

Ezek a csúszkák a téma kiválasztóján keresztül beállíthatók, és lehetővé teszik a videó és a szöveg méretének dinamikus változtatását. Ha a csúszkák értékei változnak, a grid elrendezését automatikusan frissíthetjük a location.reload() használatával.

css
Copy code
.tile {
  background: var(--tilebackground, grey);
  padding: 15px 15px 15px;
  overflow: hidden;

  @media screen and (min-width: 768px) {

    &.video {
      grid-column: span var(--videosize, 9);
    }
    &.text {
      grid-column: span var(--textsize, 3);
    }
  }
  @media only screen and (max-width: 768px) {
    grid-column: span 12;
  }
}

A megoldás egyik legnagyobb előnye, hogy képesek vagyunk külső komponensek (például a YouTube lejátszó) megjelenítésére is, miközben fenntartjuk a grid elrendezését, és biztosítjuk, hogy az összes komponens a kívánt módon legyen elhelyezve. Az ilyen típusú integrációk a vállalati dizájn rendszerekben használt téma beállításokkal is összekapcsolhatók, anélkül hogy az alkalmazás újraépítése szükséges lenne.

Ezek a technikák fontos szerepet játszanak az olyan alkalmazásokban, amelyek reszponzív felületeket kívánnak kialakítani, és segítenek fenntartani a rugalmas, dinamikus dizájnokat, amelyek alkalmazkodnak a különböző képernyőméretekhez.

Miért fontos a Debugging az Angular Ivy környezetében?

Az Angular Ivy bevezetésével új API-k váltak elérhetővé, amelyek jelentősen megkönnyítik az alkalmazások futásidejű hibakeresését. Az előző NgProbe API-t felváltó új eszközkészlet célja, hogy az Angular fejlesztők számára gyorsabb, hatékonyabb módot kínáljon a komponensek, események és a DOM-beli kötéseik vizsgálatára. Az új funkciók, mint például a ng.applyChanges, a ng.getComponent vagy a ng.getListeners, segítségével könnyedén ellenőrizhetjük az aktív komponensek állapotát, azok összetevőit, valamint a felhasználói interakciók hatásait.

A hibakeresés egyik alapvető eleme, hogy mindig tisztában legyünk az alkalmazás aktuális állapotával. Az Angular alkalmazások esetében különösen fontos megérteni, hogyan működnek a komponensek, hogyan kommunikálnak egymással, és miként reagálnak a felhasználói interakciókra. Az új Ivy hibakeresési API segítségével a fejlesztők pontosabban nyomon követhetik a dinamikusan változó állapotokat, és gyorsan reagálhatnak a felmerülő problémákra.

Az Ivy hibakeresési API-jának egyik legfontosabb új funkciója a ng.applyChanges. Ez lehetővé teszi, hogy jelezzük a komponensnek, hogy végezzen el egy "dirty checking"-et, különösen akkor, ha az OnPush változásellenőrzési stratégiát használ. Ezzel a módszerrel optimalizálhatjuk az alkalmazás teljesítményét, mivel csak akkor történik újra renderelés, ha valóban szükséges. A ng.applyChanges tehát egy erőteljes eszköz a hatékony változásellenőrzéshez, amely segít abban, hogy az alkalmazásunk ne végezzen felesleges műveleteket.

A ng.getListeners segítségével megvizsgálhatjuk az eseménykezelőket is, amelyek az adott DOM elemhez vannak rendelve. Ez a funkció különösen akkor jön jól, amikor szeretnénk ellenőrizni, hogy egy adott interakció valóban meghívja-e a kívánt eseményeket, vagy ha az események nem a várt módon működnek.

A hibakeresési eszközök és funkciók megértése és hatékony használata elengedhetetlen ahhoz, hogy a fejlesztési munkafolyamatokat jelentősen gyorsíthassuk és optimalizálhassuk. Az Angular Ivy hibakeresési funkciói nemcsak a problémák gyors felismerését és elhárítását teszik lehetővé, hanem a fejlesztői élményt is jelentősen javítják, hiszen lehetőséget adnak arra, hogy az alkalmazás állapotát valós időben és mélyebb szinten is megértsük.

Az Angular Ivy és a kapcsolódó új hibakeresési API-k hatékony használatának elsajátítása alapvetően növeli a fejlesztők hatékonyságát, mivel segítenek abban, hogy jobban megértsük a működési mechanizmusokat és gyorsabban reagáljunk a felmerülő problémákra. Az Angular alkalmazások fejlesztése során tehát rendkívül fontos, hogy mindig tisztában legyünk a környezetünkkel, és képesek legyünk a megfelelő hibakeresési eszközöket alkalmazni a hatékony fejlesztés érdekében.

Hogyan optimalizálhatjuk az Angular alkalmazásunk tesztelését és építését CI/CD munkafolyamatokban?

Az Angular alkalmazások fejlesztésében és tesztelésében a hatékonyság kulcsfontosságú tényező. Különösen akkor, amikor több alkalmazást kezelünk egy monorepo-ban, és az alkalmazások különböző Angular könyvtárakat, például az Angular CDK-t vagy az Angular Material-t használják. A különböző alkalmazásokban csak a szükséges csomagokat kell lefordítani, és nem minden egyes csomagot, amit az adott könyvtár tartalmaz. Az Angular alkalmazásaink tesztelésénél és építésénél az optimalizálás jelentős időmegtakarítást eredményezhet, ha megfelelően kezeljük a könyvtárak és csomagok fordítását.

A monorepo-ban való munkavégzés során különböző alkalmazások használhatnak eltérő Angular könyvtárakat, és mindegyik alkalmazás csak egy részét importálja ezeknek a csomagoknak. Ha van egy CI vagy CD munkafolyamatunk, amely egyetlen alkalmazásra van szabva, például egy adott alkalmazás tesztelésére vagy építésére, akkor érdemes figyelembe venni ezt a tényezőt, hogy ne szükségszerűen fordítsuk le az összes Angular könyvtárat, csak azokat, amelyeket az adott alkalmazás használ.

Például, ha egy monorepo-ban két Angular alkalmazás található, és az egyik a Bootstrap UI komponens könyvtárat, a másik pedig az Angular Material-t használja, akkor a tesztelési vagy építési folyamatban érdemes az alábbi parancsot használni:

bash
Copy code
npx ngcc --first-only --properties es2015 module fesm2015 esm2015 browser main --create-ivy-entry-points --tsconfig projects/bootstrap-app/tsconfig.app.json --use-program-dependencies

Ebben az esetben a Bootstrap alkalmazás a megfelelő TypeScript konfigurációs fájl elérési útvonalát kapja a --tsconfig paraméterrel, és az --use-program-dependencies opcióval kizárhatók azok a csomagok, amelyeket nem használunk, például az Angular Material alcsomagjai. Ezzel jelentős számítási időt takaríthatunk meg, mivel a CI szerverünk nem fogja lefordítani az Angular Material alcsomagjait, ha azok nem kerültek importálásra.

Ha az alkalmazás az Angular Material-t használja, akkor hasonló parancsok alkalmazásával csökkenthetjük a fordítási időt, mivel csak azokat az Angular Material alcsomagokat fordítjuk le, amelyeket az alkalmazás importál. Például:

bash
Copy code
npx ngcc --first-only --properties es2015 module fesm2015 esm2015 browser main --create-ivy-entry-points --tsconfig projects/material-app/tsconfig.app.json --use-program-dependencies

Itt a --tsconfig opcióhoz a megfelelő TypeScript konfigurációs fájl elérési útvonalát adjuk meg. Ezzel a megközelítéssel a fordítási idő jelentősen csökkenthető, mivel a rendszer csak a ténylegesen szükséges csomagokat dolgozza fel.

Az Angular Kompatibilitás Fordító (ngcc) használata lehetővé teszi számunkra, hogy a meglévő Angular könyvtárakat, amelyek a régi View Engine formátumban vannak, átalakítsuk az új Angular Ivy formátumba. Ez a folyamat különösen fontos a migrációs időszakban, amikor egyes Angular könyvtárak még mindig a View Engine-t használják, miközben az új alkalmazások már az Angular Ivy-t alkalmazzák. Az ngcc tehát egy kulcsfontosságú eszköz, amely segíti a régi és új könyvtárak közötti kompatibilitást.

A legújabb Angular verziók már támogatják a részben Ivy-vel fordított Angular könyvtárakat az Angular Linker segítségével, amely elősegíti az Angular Kompatibilitás Fordító fokozatos eltűnését. Az Angular Linker célja, hogy teljesen felváltja az ngcc-t, és lehetővé teszi az Ivy-vel kompatibilis könyvtárak közvetlen használatát. Az ngcc és az Angular Linker közötti különbségek és előnyök fontosak, amikor az Angular alkalmazások gyorsításáról és optimalizálásáról beszélünk.

Az Angular alkalmazások CI/CD folyamatainak optimalizálása érdekében az ngcc és hasonló eszközök használata mellett fontos, hogy figyelembe vegyük a könyvtárak és csomagok megfelelő kezelését, és ne fordítsunk le szükségtelen elemeket. Ez jelentős időmegtakarítást és gyorsabb build időket eredményezhet, különösen nagyobb monorepo-ban, ahol több alkalmazás is fut. Az optimalizált build idő kulcsfontosságú az alkalmazások gyorsabb fejlesztéséhez és teszteléséhez, különösen, ha folyamatos integrációval és szállítással dolgozunk.

Az Angular migráció során érdemes figyelmet fordítani arra is, hogy bár az automatizált eszközök, például az Angular Update Guide segítségével nagyban könnyíthetjük a migrációs folyamatot, a manuális migrációk elvégzése is szükséges lehet. A jól megtervezett migrációs lépések biztosítják, hogy a különböző Angular verziók közötti váltás ne okozzon inkompatibilitást vagy hibát a rendszerben, és az új verziók zökkenőmentesen működjenek.

Hogyan optimalizáljuk a regionális támogatást javított globalizációs API-kkal?

A többnyelvű alkalmazások globalizációt használnak annak érdekében, hogy a felhasználók a különböző országokból és háttérrel rendelkező emberek számára regionális élményt nyújtsanak. Az Angular rendelkezik beépített API-kkal a nemzetközivé tétel (i18n) és lokalizálás (l10n) kezelésére. Ebben a szakaszban a konfigurációs és implementációs példákon keresztül bemutatjuk az új globalizációs lehetőségeket, amelyeket az Ivy biztosít számunkra.

Az Angular a helyi adatokat használja a különböző régiós formátumok kezelésére, például a dátumok, pénznemek, tizedes számok és százalékok esetében. Az Angular Ivy-ben lehetőség van arra, hogy egyetlen helyet is beépítsünk az alkalmazásba a localize build opció segítségével. Tegyük fel, hogy szeretnénk, ha alkalmazásunk a francia helyi beállítást (locale) használja. Ezt a projekt build konfigurálásával érhetjük el, az alábbi módon:

json
Copy code
{
  "projects": {
    "my-app": {
      "projectType": "application",
      "i18n": {
        "locales": {
          "fr": "src/locales/translations.fr.xlf"
        }
      },
      "architect": {
        "build": {
          "builder": "@angular-devkit/build-angular:browser",
          "options": {

            "localize": ["fr"]

          }
        }
      }
    }
  }
}

A localize opció segítségével meghatározzuk, hogy a francia locale ("fr") be legyen csomagolva és betöltve az alkalmazással együtt, miközben a locales.fr opció a francia fordítás fájl helyét is megadja. Az Ivy-re való migráláskor szükség van a ng add @angular/localize parancs futtatására, hogy az Angular beépített globalizációs API-jait engedélyezzük. Ha nem használjuk ezeket az API-kat, akkor nyugodtan kihagyhatjuk ezt a csomagot, hogy elkerüljük az alkalmazás méretének növekedését. Emellett dönthetünk úgy is, hogy minden egyes locale esetében külön build konfigurációt készítünk, de ezt most hagyjuk meg gyakorlásra.

Az Ivy jelentősen javította a lokalizálás sebességét.

A helyi adatok késleltetett betöltése

A következő kód egy osztály alapú szolgáltatást mutat be, amely a locale kiválasztóval együtt használható:

typescript
Copy code
import { Injectable } from '@angular/core';

import { EMPTY, from, Observable } from 'rxjs';

import { catchError, mapTo } from 'rxjs/operators';
import { LanguageTag } from '../../shared/ui/language-tag';
@Injectable({
  providedIn: 'root',
})
export class LocaleLoader {

  load(locale: LanguageTag): Observable {

    return from(import(`@angular/common/locales/global/${locale}`)).pipe(
      catchError(() => {

        console.error(`Error when loading locale "${locale}"`);

        return EMPTY;
      }),
      mapTo(undefined)
    );
  }
}

A LanguageTag típus egy szöveges karakterláncot képvisel, amely megfelel a BCP47 formátumnak (https://www.ietf.org/rfc/bcp/bcp47.txt). A LocaleLoader szolgáltatás a dinamikus importálás segítségével tölti be késleltetve a locale adatokat, miközben a hibákat a böngésző konzolra írja ki. Ez mind egy observable-ban van becsomagolva.

A lokalizációs kiválasztó használata

A következő kód egy template-t mutat be, amely az input elemet használja az autocompletelés engedélyezésére a szövegmezőben, és a selectedLocale form vezérlőt a localeChange eseményhez köti:

typescript
Copy code
import { Component, Input, Output } from '@angular/core';

import { FormControl, Validators } from '@angular/forms';
import { Observable } from 'rxjs';

import { LanguageTag } from '../../shared/ui/language-tag';

import { validValueChanges } from '../../shared/ui/valid-value-changes';
import { localeValidator } from './locale-validator';
@Component({
  selector: 'app-locale-picker',
  templateUrl: './locale-picker.component.html',
})
export class LocalePickerComponent {
  @Input() set locale(value: LanguageTag) {
    this.selectedLocale.setValue(value, { emitEvent: false, emitViewToModelChange: false });
  }

  @Input() locales: ReadonlyArray<string> = [];

  @Output() localeChange: Observable<string> = validValueChanges(this.selectedLocale);
  selectedLocale = new FormControl('', [Validators.required, localeValidator]);
}

A localeValidator egy összetett validátor, amely biztosítja, hogy a bevitt érték megfeleljen a BCP47 formátumnak. Az allLocales lista tartalmazza az összes ismert locale-t, és a validátor ellenőrzi, hogy a bevitt nyelvi kód szerepel-e a listában.

A megfelelő dir attribútum dinamikus beállítása

A fent bemutatott példák és technikák révén az Angular Ivy sokkal könnyebbé és gyorsabbá tette a lokalizációs folyamatokat, lehetővé téve a rugalmas és dinamikus regionalizálást. A modern globalizációs API-k alkalmazásával a felhasználói élmény optimalizálása az egyes nyelvi és kulturális preferenciák figyelembevételével egyszerűbbé vált. A dinamikus betöltés és a fordítások rugalmas kezelése segíthet abban, hogy alkalmazásaink globálisan versenyképesek maradjanak.