Jak Angular Ivy zvyšuje produktivitu vývojářů prostřednictvím nástrojů, konfigurací a pohodlí

Angular Ivy přináší značné vylepšení pro vývojáře, a to nejen díky rychlejším kompilátorům a lepší podpoře nástrojů, ale i díky přesnějším a konzistentnějším API. V tomto kontextu je důležité si uvědomit, jak Ivy zjednodušuje proces vývoje a jak výrazně ovlivňuje celkovou produktivitu. Tento přístup k vývoji je ve své podstatě zaměřen na zajištění vyšší spolehlivosti a méně chyb, což je základní přínos Ivy pro vývojáře, kteří se chtějí soustředit na kvalitní a rychlý vývoj aplikací.

Další podstatnou změnou je podpora pro různé preprocesory stylů, jako je například Sass. Díky možnosti nastavení volby inlineStyleLanguage ve build konfiguraci je možné využívat moderní přístupy k definici stylů přímo v komponentách. To znamená, že aplikace může lépe využívat funkce těchto preprocesorů, aniž by bylo nutné se uchylovat k externím souborům nebo komplikovaným importům. Tento přístup usnadňuje práci s dynamickými a flexibilními styly, což je výhodné při vytváření komplexních uživatelských rozhraní.

Pokud jde o správu stylů, Ivy přináší předvídatelnost i při použití více vazeb na styl. Dříve mohl být problémem konflikt mezi různými způsoby, jakým byly styly aplikovány na komponenty. Ivy tento problém řeší jasně definovaným pořadím, které zajistí, že složitější případy použití, kde jsou styly kombinovány, budou fungovat podle očekávání. Zajímavé je, že díky tomuto přístupu se nezáleží na pořadí vazeb, ale důležitý je typ vazby, což dává vývojářům větší kontrolu nad tím, jak budou styly aplikovány.

Významným krokem vpřed je také podpora pro přísnější typovou kontrolu šablon. Angular již dlouho poskytuje silnou typovou kontrolu pro komponenty, ale Ivy tuto kontrolu posunul na novou úroveň, kdy jsou všechny šablony a komponenty testovány s ohledem na typy. Tento přístup výrazně zlepšuje testování aplikací, protože umožňuje detekci chyb ještě předtím, než se dostanou do produkce. Pokud například dojde k chybě v testech, je možné se na tuto chybu rychle zaměřit, což zkracuje dobu potřebnou pro opravy a zvyšuje spolehlivost kódu.

Rovněž je třeba zmínit, jak Ivy vylepšuje zážitek při testování aplikací. Nové nástroje pro testování výrazně zjednodušují proces a umožňují rychlejší feedback od vývojářů. Typické výzvy při psaní testů, jako je synchronizace mezi testovacím prostředím a produkční verzí aplikace, jsou minimalizovány díky vylepšené podpoře AOT kompilace v testech. To znamená, že testování je blíže reálnému prostředí, což se promítá do rychlejší detekce chyb a lepší údržby kódu.

Pokud jde o migrace mezi verzemi, Ivy zjednodušil aktualizace díky přehledným chybovým hlášením a nástrojům, které pomáhají automatizovat proces přechodu mezi verzemi. Tento proces se ještě dále zjednodušuje díky možnosti používat příznak --create-commits, který umožňuje vytvářet jednotlivé Git commity pro každý krok migrace. Tento přístup je obzvláště užitečný pro velké projekty, kde může být migrace mezi verzemi složitým a časově náročným úkolem.

Jedním z nejdůležitějších aspektů, na které se Ivy soustředí, je zajištění kompatibility s nástroji pro integraci IDE, což umožňuje lepší podporu při práci s Angular projekty. Například nové chybové hlášky týkající se neplatných URL šablon a stylů, tipy na deklarace modulů a zvýraznění syntaxe pro in-line šablony a styly znamenají, že vývojáři mohou snadněji pracovat a zaměřit se na to, co je důležité. Tyto změny přinášejí zásadní zlepšení v kvalitě vývoje a testování.

Důležité je také mít na paměti, že Angular Ivy nabízí několik nových funkcí pro práci s moderními webovými technologiemi. Například podpora pro CSS Custom Properties, které jsou nativními proměnnými CSS, přináší nové možnosti pro dynamickou změnu stylů v aplikacích. To znamená, že vývojáři mohou snadno upravovat hodnoty stylů v závislosti na specifických podmínkách aplikace. V kombinaci s Dependency Injection a novými poskytovatelskými rámci v Ivy se tyto možnosti stávají výkonným nástrojem pro vývoj moderních a flexibilních aplikací.

Endtext.

Jak migrovat Angular aplikaci z View Engine na Ivy a co tím získáte

Přechod z View Engine na Ivy není pouze otázkou technologické aktualizace. Znamená zásadní změnu v samotném způsobu, jak Angular interpretuje a vykonává kód – jak během vývoje, tak v produkčním prostředí. Ivy není pouze rychlejší a efektivnější, ale mění i samotnou filozofii práce s Angular aplikacemi. Tento přechod se však neobejde bez určité míry složitosti, a proto je důležité znát nejen automatizované nástroje, ale i ruční zásahy, které mohou být během migrace nezbytné.

Automatizovaný migrační proces je v současnosti spolehlivý a opírá se o Angular CLI a příkaz ng update. Tento příkaz zvládne většinu základních migrací knihoven a kódu, pokud se aplikace držela konvencí Angularu. Nicméně je klíčové projít si celý proces manuálně a pochopit změny, které byly provedeny – ne vše lze řešit pouze automaticky. Často se objevují problémy s knihovnami třetích stran, které nejsou kompatibilní s Ivy, a právě zde přichází ke slovu Angular Compatibility Compiler (ngcc), jehož úlohou je přizpůsobit starší View Engine balíčky novému Ivy prostředí.

Ngcc funguje jako transpilační most mezi View Engine a Ivy. Umožňuje, aby aplikace psaná s Ivy mohla používat knihovny, které zatím nebyly přepsány na Ivy nativně. V CI/CD prostředí je důležité začlenit ngcc do build procesu tak, aby byl spuštěn automaticky před kompilací aplikace. V monorepo workspacech je rovněž možné zacílit ngcc pouze na jednu aplikaci nebo subset balíčků, čímž se dramaticky zrychlí build proces.

Ruční migrace se týká především případů, kdy aplikace používá nestandardní patterny, vlastní build nástroje, nebo přímo modifikuje Angular runtime. Zde je nutné znát nové API a strukturální změny, které Ivy přináší. Například způsob práce s NgZone, nebo optimalizace change detection mechanismu, se změnily natolik, že nepochopení těchto principů může vést k výrazným výkonovým problémům. V některých případech může být vhodné změnit samotnou strategii detekce změn a využít OnPush režim s kombinací explicitních eventů.

Při přechodu na Ivy získává testování nový rozměr. API TestBed.inject zajišťuje silnější typovou bezpečnost a přesnější kontrolu nad testovanými službami. To je důležité zejména v rozsáhlých aplikacích, kde typová nekonzistence vede k těžko odhalitelným chybám. Dále se rozšiřuje možnosti ladění aplikace přímo v runtime prostředí díky novému Ivy debugging API, které umožňuje zkoumat komponenty, jejich stav a strukturu přímo v konzoli.

Ahead-of-Time (AOT) kompilace se v Ivy stává výchozím standardem. Kompilace již neprobíhá pouze jako build-time fáze, ale zasahuje i do běhu aplikace a testování. Tím se zajišťuje rychlejší start a menší velikost bundle. Nicméně AOT má své limity – některé dynamické konstrukce, zejména při práci s asynchronními závislostmi, vyžadují specifické přístupy. Například je nutné inicializovat proměnné metadat explicitně a často využívat APP_INITIALIZER, pokud je potřeba zavést asynchronní závislost ještě před bootstrapem aplikace.

Dále je důležité pochopit význam poskytování hodnot pomocí funkcí a jejich vztah ke statickému DI systému Angularu. Funkce mohou být využity k deklaraci hodnot, které se mění v čase, ale stále potřebují být dostupné v rámci DI stromu jako statické hodnoty během kompilace.

Migrace na Ivy není jen technologickou změnou, ale i příležitostí ke zjednodušení, modernizaci a lepší optimalizaci vývoje Angular aplikací. Vývojový cyklus se zkracuje, testování je přesnější, debugování jednodušší a build systém předvídatelnější. Přechodem na Ivy se Angular dostává do nové fáze svého vývoje – stabilnější, výkonnější a lépe integrované do moderního TypeScript ekosystému.

Jak získat a manipulovat s instancí komponenty v Angularu během běhu aplikace?

Pro programové zkoumání naší aplikace během běhu je často potřeba získat referenci na aktivní instanci komponenty. Jakmile máme takovou referenci, můžeme měnit její vlastnosti vázané na šablonu, volat event handlery nebo jiné metody. Prvním krokem je získat referenci buď na instanci direktivy, nebo na DOM element, který komponentu obsahuje.

V šabloně komponenty je použit materiálový tlačítkový prvek Angular Material. Po získání reference na DOM element v $0 můžeme pomocí runtime API Angularu vyřešit dvě různé instance komponent: ng.getComponent($0) vrátí instanci přímo navázanou na DOM element (například MatButton), zatímco ng.getOwningComponent($0) vrátí instanci „vlastníka“ šablony, tedy v tomto případě naši RandomNumberComponent. Toto rozlišení je klíčové, protože komponenta tlačítka je jen podřízenou součástí širší komponenty generující náhodná čísla.

Když máme instanci komponenty, můžeme například přímo nastavit hodnotu vlastnosti generatedNumber, například na 42. Nicméně samotná změna této vlastnosti neaktualizuje zobrazení v DOM, protože Angular neví, že stav komponenty byl změněn manuálně. Proto je potřeba zavolat ng.applyChanges s touto instancí komponenty, čímž se spustí detekce změn a DOM se aktualizuje podle nové hodnoty.

Kromě samotných instancí komponent je užitečné zkoumat i event listenery navázané na DOM elementy. Například u tlačítka s navázanou událostí click lze získat posluchače událostí pomocí ng.getListeners($0), kde $0 je DOM element tlačítka. Výsledkem je pole Listener objektů, přičemž každá Listener obsahuje callback funkci, kterou lze vyvolat a tím simulovat kliknutí na tlačítko programově. Opět je však nutné po vyvolání callbacku spustit ng.applyChanges, aby Angular zpracoval nové změny stavu.

Event listenery mohou pocházet nejen z DOM událostí, ale i z vlastních komponentních výstupů (output). Například u vlastního eventu numberGenerated může Angular registrovat dva posluchače: jeden pro DOM typ události a druhý pro vlastní výstup komponenty. Využitím ng.getListeners na příslušném DOM elementu získáme oba posluchače a můžeme programově vyvolat jejich callback funkce. Pokud chceme, aby změny byly viditelné, opět použijeme ng.applyChanges.

Je důležité zdůraznit, že runtime API Angularu, jako jsou ng.getComponent, ng.getOwningComponent, ng.getListeners a ng.applyChanges, umožňují hlubokou integraci a kontrolu nad komponentami během běhu aplikace, což je mimořádně užitečné při ladění i při vytváření dynamických funkcí. Zároveň ale vyžadují porozumění rozdílům mezi instancí přímo vázanou na DOM element a vlastní komponentní instancí, stejně jako povědomí o nutnosti ručně spouštět detekci změn po zásahu do stavu komponenty.

V kontextu runtime ladění a manipulace s Angular aplikací je zásadní pochopit architekturu komponent, vazby mezi DOM a komponentami, a jak Angular detekuje a aplikuje změny. Tato znalost umožňuje efektivní využití ladících nástrojů a rozšiřuje možnosti vývojáře při práci s dynamickými a interaktivními uživatelskými rozhraními.

Jak optimalizovat migraci aplikace v Angularu při přechodu na Ivy

Při migraci aplikace v Angularu z View Engine na Ivy je nezbytné věnovat pozornost několika klíčovým oblastem, které mohou ovlivnit nejen výkon aplikace, ale také její chování v konkrétních případech. Jedním z důležitých aspektů je optimalizace detekce změn a správa asynchronních závislostí, které mohou během vývoje způsobit neočekávané chyby. Ačkoliv Angular Ivy přináší mnoho vylepšení, přechod na tento nový kompilátor vyžaduje pečlivé plánování a testování.

Ivy je nová generace kompilátoru a běhové vrstvy v Angularu, která se zaměřuje na zrychlení a zefektivnění procesu kompilace. Klíčovým rozdílem mezi View Engine a Ivy je způsob, jakým jsou generovány a optimalizovány datové struktury pro aplikaci. Zatímco View Engine využívá složité datové struktury, které jsou interpretovány za běhu aplikace, Ivy přechází na Instruction Set, což znamená, že opakované využívání stejných instrukcí pro různé části aplikace vede k menší velikosti balíčku a rychlejšímu vykonávání.

Vliv na detekci změn

Pokud jde o detekci změn, přechod na Ivy může mít pozitivní vliv na výkon aplikace, ale zároveň přináší některé změny v chování. Příklad takové změny je chyba NG0100, která je běžně spojována s použitím nastavení detekce změn při práci s asynchronními událostmi. V Ivy je detekce změn vylepšena tím, že se více než v předchozích verzích spoléhá na řízený průběh detekce změn, což vede k lepšímu chování aplikace při interakci s DOM.

Testování a typová bezpečnost

Jedním z významných vylepšení v Ivy je nový způsob práce s TestBed, což je nástroj pro psaní testů v Angularu. V předchozích verzích Angularu byla metoda TestBed.get slabě typová, což znamenalo, že vrácený objekt byl typu any. To může vést k problémům při psaní testů, zejména pokud se aplikace stane komplexní.

S příchodem Ivy byla představena metoda TestBed.inject, která je silně typová a umožňuje explicitně deklarovat, jaký typ očekáváme. To přispívá k vyšší bezpečnosti typů a zjednodušuje údržbu kódu. Příklad použití TestBed.inject místo TestBed.get může vypadat následovně:

typescript
Copy code
it('zobrazuje dlaždice na dashboardu', () => {

   const dashboardService = TestBed.inject(DashboardService);
   // (...)
});

Pokud je potřeba vrácený objekt přetypovat, je nyní nutné použít explicitní přetypování:

typescript
Copy code
it('zobrazuje dlaždice na dashboardu', () => {

   const dashboardServiceStub = TestBed.inject(DashboardService) as unknown as DashboardServiceStub;
   // (...)
});

Tato změna nejen zlepšuje bezpečnost kódu, ale také znamená, že některé starší metody, jako například používání TestBed.get s obecnými typy, byly označeny za zastaralé.

Asynchronní závislosti a jejich inicializace

Dalším problémem, na který je potřeba dávat pozor při přechodu na Ivy, je správa asynchronních závislostí. V některých případech může být nezbytné řešit asynchronní závislosti ještě před inicializací aplikace. To se obvykle provádí prostřednictvím specifických technik, které umožňují načítání závislostí v konkrétním pořadí. Například pokud aplikace vyžaduje, aby některé služby byly plně inicializovány před samotným spuštěním, může být nutné využít nástroje pro správu asynchronních operací.

Kompilace před spuštěním a její vliv na výkon

Přechod na kompilaci před spuštěním (Ahead-of-Time – AOT) byl klíčovým krokem v rámci Angularu Ivy. Zatímco v minulých verzích Angularu byla kompilace před spuštěním pomalejší než kompilace za běhu (Just-in-Time – JIT), v Ivy se tento proces stal efektivnějším, což vedlo k rychlejšímu startu aplikace a nižší velikosti výsledného balíčku. Tento přístup nejen zrychluje vývoj, ale také minimalizuje možnost chyb, které by se mohly objevit pouze v produkčním prostředí.

V Ivy je AOT kompilace zapnutá ve všech fázích vývoje, včetně testování, serverového renderování a běhu aplikace v prohlížeči. Tento způsob kompilace zajišťuje, že chyby jsou odhaleny dříve v procesu vývoje a aplikace se stává stabilnější. U aplikací s menšími balíčky může tento přechod výrazně snížit dobu načítání, což zlepšuje uživatelský zážitek.

Je však třeba mít na paměti, že pro aplikace s velmi složitou strukturou může přechod na Ivy vést k určitému zvětšení velikosti hlavního balíčku. Tento nárůst je kompenzován zmenšením velikosti dalších lazily načítaných částí aplikace.

Při migraci na Ivy je důležité dobře porozumět těmto změnám a včas reagovat na potenciální problémy. Správné využití nových funkcí, jako je silná typová bezpečnost a optimalizace AOT kompilace, může významně zlepšit jak vývojářský zážitek, tak i výkon aplikace v produkci.

Jak optimalizovat podporu pro regiony s vylepšenými API pro globalizaci

Angulární aplikace často vyžadují lokalizované formátování pro data, měny, desetinná čísla a procenta. Když používáme Angular Ivy, můžeme do sestavení přidat podporu pro jednotlivé lokality pomocí možnosti localize ve výstavbě projektu. Příklad, jak by mohl vypadat soubor konfigurace, pokud bychom chtěli aplikaci nastavit na francouzskou lokalitu, vypadá následovně:

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"]
          }
        }
      }
    }
  }
}

Dále, ve verzi Angular Ivy došlo k výraznému zrychlení procesu lokalizace při sestavování aplikací. Zajímavou novinkou je také podpora pro lazy loading (dynamické načítání) dat pro jednotlivé lokality. Před příchodem Ivy bylo nutné načítat a registrovat data pro všechny podporované lokality v aplikaci, kromě "en-US", která byla vždy součástí základního balíčku. Tento přístup umožňuje efektivněji spravovat podporu pro různé jazyky bez zbytečného zvyšování velikosti aplikace.

Pokud bychom nevyužívali vestavěná internacionalizační API, můžeme využít dynamické importování locale dat, což je ideální pro aplikace používající dynamické knihovny pro překlady, jako jsou ngx-translate nebo Transloco. Následující kód ukazuje, jak by mohl vypadat služba pro dynamické načítání locale dat pro francouzštinu:

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

import { EMPTY, from, Observable } from 'rxjs';
import { catchError, mapTo } from 'rxjs/operators';
@Injectable({
  providedIn: 'root',
})
export class LocaleLoader {

  load(locale: string): Observable<void> {

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

        console.error(`Chyba při načítání locale "${locale}"`);

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

Tento kód umožňuje dynamicky importovat locale data a zachytit případné chyby při načítání. Při výběru locale uživatelem je možné zajistit, že se načtou pouze potřebná data pro vybraný jazyk, což je efektivní způsob, jak udržet aplikaci co nejmenší a přitom poskytovat flexibilitu pro různé regiony.

Tato komponenta zajišťuje, že vybraný jazyk bude odpovídat validnímu tagu jazyka podle specifikace BCP47. K tomu slouží regulární výraz, který ověřuje formát jazykového tagu a zajišťuje, že uživatel může vybrat pouze platnou lokalitu.

Důležitou součástí tohoto procesu je validace jazyka na základě předem definovaného seznamu známých lokalit. Tento seznam umožňuje ověřit, že uživatel nevybere jazyk, který není podporován aplikací. Validace tagu jazyka je prováděna pomocí dvou validačních funkcí: jedna ověřuje správnost formátu jazyka, druhá kontroluje, zda daný jazyk existuje v seznamu podporovaných lokalit.

Pro zajištění co nejlepší uživatelské zkušenosti a efektivity v lokalizaci je rovněž vhodné použít různé nástroje pro optimalizaci a monitorování procesů globalizace. Důležité je mít na paměti, že podpora více lokalit je nejen technickým, ale i kulturním aspektem, který vyžaduje pečlivé zohlednění specifických potřeb jednotlivých regionů.