The playground

More information here

hladší UX na načtení stránky s úhlovými Resolvery

Jako vývojář se vždy snažíte optimalizovat svůj kód. To zahrnuje rychlost, s jakou prezentujete uživateli plně načtené uživatelské rozhraní, které je často závislé na datech pocházejících z databáze. Nevyhnutelně, začnou hledat způsoby, jak vyřešit údaje ihned po navigaci na novou stránku/oblast své aplikace, aniž by uživatel setká, co je známé jako strana JANK. to je, […]

Jako vývojář se vždy snažíte optimalizovat svůj kód. To zahrnuje rychlost, s jakou prezentujete uživateli plně načtené uživatelské rozhraní, které je často závislé na datech pocházejících z databáze.

Nevyhnutelně, začnou hledat způsoby, jak vyřešit údaje ihned po navigaci na novou stránku/oblast své aplikace, aniž by uživatel setká, co je známé jako strana JANK.

to je, když se stránka pohybuje nahoru a dolů při načítání určitých komponent. To může významně ovlivnit UX do bodu, kdy vypadá „buggy“.

Úhlové poskytuje intuitivní přístup k pre-načítání dat před trase zatížení; před navigovanou trasu řeší.

nazývá se úhlový Resolver.

úhlový Resolver je v podstatě úhlová služba. Injekční třída, kterou poskytnete směrovacímu modulu v konfiguraci trasy. Tento speciální typ služby se vstřikuje a provádí při navigaci obsahující trasu.

Resolver poté vyřeší data před načtením stránky, která budou dostupná prostřednictvím služby ActivatedRoute. To poskytuje jednoduchý a efektivní způsob, jak zajistit, aby váš uživatel má data tak rychle, jak je to možné, než komponenta, která je důležitá pro počáteční načtení stránky bude potřebovat.

dalším způsobem, jak použít úhlový Resolver, je jeho použití jako metody k okamžitému naplnění metadat SEO.

S resolver, poskytujete záruku, že údaje budou existovat předtím, než je stránka načtena, zajistit, že všechno má, co potřebuje na inicializaci.

řekněme, rozdělení Úhlové Resolver

Úhlové resolver je třída, která implementuje Resolve rozhraní. Rozhraní Resolve vyžaduje implementaci funkce ve třídě nazvané resolve.

Tady je Řešení rozhraní podpis…

export interface Resolve<T> {
resolve(route: ActivatedRouteSnapshot, state: RouterStateSnapshot): Observable<T> | Promise<T> | T {
return 'data';
}
}

Jak můžeme vidět z rozhraní podpis, to vyžaduje obecný argument T což bude typ vyřešit naše data.

vyřešit funkce vrací ObservablePromise nebo jen data typu T . Proto existuje návrh, že by s tím mělo být nakládáno asynchronně, zejména při načítání dat z databáze.

hlavním účelem funkce resolve je, že musí být dokončena. Tuto skutečnost je třeba mít na paměti při načítání dat v pozorovatelných. Pozorovatelný musí být dokončen. Koneckonců, je to resolver.

Pokud není pozorovatelné dokončeno, data se nikdy nevyřeší a stránka se nikdy nenačte. Proto musíte definovat bod, ve kterém nemusíte brát žádné další hodnoty a data mohou vyřešit, protože máte vše, co potřebujete z databáze. Při použití asynchronních datových toků, jako jsou pozorovatelné, se jedná o případ použití pro pipeable operátory z RXJS.

pipeable subjekty, které na jaře na mysl, když přemýšlel o dokončení datového toku na základě stavu, je kombinace filtertakefirst . S touto kombinací, můžete filtrovat všechny hodnoty, které nechcete, aby se, například null nebo undefined nebo prázdné pole take první platná hodnota s take(1).

Subjekty, které mohou být potřebné k dokončení pozorovatelný brzy, když se potýkají s problémy nebo chyby, na které budete chtít vrátit null, nebo přesměrovat, je catchErrortimeout . Kombinace timeoutcatchError je užitečné, pokud vaše data je trvá příliš dlouho a vy byste se chtěl vrátit null takže to můžete zkusit znovu uvnitř složky, nebo chcete přesměrovat.

Pokud vaše data nemusí řešit rychle, je založen na komplexní filtrování, logika, obrovské množství volání databáze, jste pravděpodobně problémy čas od času.

To je nejlepší určit nejmenší množství volání databáze, a minimální údaje, které je třeba úspěšně a elegantně načíst stránku.

v důsledku toho mohou těžit z strávit trochu času, před provedením vaši resolver, zaměřit se na oddělující se nad okrajem obsahu z údajů, které mohou být načteny, když se stránka obnoví.

proto můžete rozdělit data potřebná pro hladký UX, od ostatních dat, která by mohla být volána z komponenty, spíše než resolveru.

pak se můžete výhradně zabývat minimálním obsahem nad záhybem prostřednictvím resolveru.

tento dynamický přístup k načítání stránky může být nápomocen s použitím koster. Takže pokud se uživatel okamžitě posouvá dolů, můžete uživateli dát informaci, že se obsah načítá, a následně vylepšit UX.

Krok 1: Vytvoření resolveru

musíme vytvořit úhlový Resolver. Neexistuje však úhlový příkaz CLI, který generuje resolver. Proto budeme muset sami napsat dekorátor (resolver metadata).

Naštěstí, to je jen pár řádků kódu, které tvoří často používaný pro překládání, a můžeme vzít injekční malíř z existující služby, pokud jste se snaží vzpomenout.

Poznámky Profil Resolver třídy s injekční malíř

za Prvé, nabízíme injekční malíř s providedIn: any v konfiguraci.

@Injectable({ providedIn: 'any'})

potom pojmenujeme náš resolver připojením konvence Resolver . V tomto příkladu budeme řešit profilová data (uživatelská data), takže je budeme nazývat ProfileResolver .

Jako je překládání, a Úhlové rozpozná funkci překladače, můžeme implementovat Resolve třídy, který bude poskytovat podpis, které musíme realizovat v naší vyřešit funkce, aby se úspěšně vyřešit údajů.

@Injectable({providedIn: 'any'})
export class ProfileResolver implements Resolve<Profile> {
}

naše funkce resolve vrátí pozorovatelné údaje odpovídající rozhraní Profile. Proto poskytneme rozhraní Profile jako obecný argument pro třídu resolveru a funkci resolve(). Tímto způsobem jsme se přizpůsobili úhlovým požadavkům na resolver.

resolve(route: ActivatedRouteSnapshot, state: RouterStateSnapshot): Observable<T> | Promise<T> | T {
return;
}

řešení implementace nám dává dva parametry, pokud jsou potřeba, routestate . Ty jsou automaticky vyplněny a jsou přístupné z naší funkce resolve().

dále musíme skutečně vyřešit skutečná data z databáze, což bude náš další krok.

Načítání dat z databáze

Chcete-li načíst data pro naše odhodlání funkce, budeme potřebovat aplikovat na servis, který poskytuje data; ten, který komunikuje s databází.

bereme z toho, co potřebujeme, abychom rychle vyřešili, aby uživatel rychle a úspěšně navigoval. Pro účely tohoto dema se nebudeme starat o základní službu, která se zabývá databází. Pouze vložíme službu pomocí dependency injection do argumentu konstruktoru pro naši třídu ProfileResolver.

stejně Jako naše data přichází v podobě Pozorovatelný proud dat s více hodnotami vyzařující asynchronně, budeme jen třeba take(1) pomocí pipeable operátor take importované rxjs/operator . Jinak by pozorovatel nikdy nedokončil a řešitel by nikdy … nevyřešil.

potřebujeme pouze jednu emisí/hodnota a take dokončí pozorovatelné pro nás.

To je tak jednoduché, jak to vytvořit resolver; jen se musíme vrátit pozorovatelné v resolve() funkce, která úhlové bude zpracovávat předplatné.

ProfileResolver Třídy

Jsme zvládnout případné chyby v načítání dat tím, že přesměruje k nadřazené trase.

Bonus: Naplnění dynamických metadat SEO rychle před načtením trasy

výhody naplnění našich značek <meta> má okamžitě zjevné výhody. Čím rychleji jsou naše metadata SEO naplněna, tím rychleji naše SEO správně a přesně odráží obsah stránky.

To znamená, je to jednodušší a rychlejší pro roboty, jako jsou provozovány vyhledávače jako Google a Bing, procházet vaše stránky a načíst obsah.

To není tak důležité, na pre-tavené stránky, nebo ty, které jsou vykresleny pomocí Úhlové Univerzální, protože veškeré vykreslování je kompletní před roboty přijímat obsah.

Nicméně, pokud jste se spoléhat na (často sporné) možnost pro google roboty analyzovat javascript pro vaše SEO, nebo máte on-demand řešení, jako loutkář, že potřebuje ujištění, že SEO bude správné, před vrácením poskytnuté DOM, pak resolver, který zahrnuje SEO by mělo pomoci. Pomáhá tedy, když je prolézací modul časově omezený.

také odděluje obavy od komponenty, takže komponenta nemusí řešit nic související se SEO. Jeden z hlavních důvodů, proč mám rád resolvery.

2. Krok: Aplikujte resolver do směrovací modul

ProfileRoutingModule, kde budeme poskytovat naše resolver je líný načten modul. Proto bude naše kořenová cesta prázdná s parametrem token userSlug, který budeme muset načíst správná data profilu.

poskytnout našim resolver, jsme jen poskytovat objekt s názvem naše data jako klíčový a specifický překladač jako hodnotu, která bude odpovědná za řešení tohoto data.

klíč můžete pojmenovat, jak chcete, ale budeme mu říkat data.

Naše ProfileRoutingModule

to je vše, co je požadováno v směrování modulu pro nás využít náš překladač.

dále musíme načíst a použít naše data v komponentě.

Krok 3: Inicializujte komponentu s vyřešenými daty

Nyní, když jsme vyřešili naše data o aktivaci trasy, jsou data přístupná prostřednictvím služby ActivatedRoute. Jak se zabýváme pozorovatelnými, v celé aplikaci vytvoříme proud, který se váže na vlastnost data, která bude našimi vyřešenými daty.

nejprve vložíme ActivatedRoute do konstruktoru našeho ProfileComponent . Dále přiřadíme this.route.dataprofile$ pozorovatelné. Budeme také chtít přejít na použití pozorovatelného, když aktualizovaná data přicházejí z databáze, abychom měli při interakci s aplikací nová data.

Pro toto, budeme používat startWith takže začneme náš stream s hodnotou, které je snadno přístupné z this.route.snapshot.data. Poté přistupujeme kdata vlastnost jako this.route.snapshot.datastartWith označuje hodnotu pro začátek, jako první emise našeho proudu.

Náš Profil Komponenty

Co okamžitě dostupné údaje pro složky

Okamžitě přístupné dat snižuje čas strávený načítání jednotlivých částí stránky, která je pozorována uživatelem. Výsledkem nepoužívání resolveru, jako je tento, je to, že se Stránka může načítat fragmentovaným způsobem, což není vizuálně příjemné.

v důsledku toho budete muset věnovat pozornost tomu, které prvky vašich šablon HTML jsou závislé na tom, jaká data. Pak byste měli napsat svůj resolver na podporu těchto prvků a celkový vliv na načítání stránky UX.

Existuje několik způsobů, že komponenta může načíst roztříštěné

  • Jedna z nich je, když máte ngIf více částí HTML šablony.
  • další je ngFor .

nejlepší praxí je omezit množství jednotlivých ngIf píšete za účelem omezení velikosti velikosti prohlížeče.

načtení stránky před získáním dat může způsobit, že části stránky budou neustále skákat, zaostávat a měnit velikost, což způsobí utrpení UX.

implementací resolveru může být rozdíl mezi uživatelem, který zažívá 3-5 sekund skákání a změny velikosti vs. 0,5 sekundy, což je často příliš rychlé na to, aby poškodilo celkový UX.

to je ono! Máme resolver s vylepšeným UX na načtení stránky.

Napsat komentář

Vaše e-mailová adresa nebude zveřejněna.