The playground

More information here

simább UX oldal betöltése szögletes resolverek

mint fejlesztő, akkor mindig keres, hogy optimalizálja a kódot. Ez magában foglalja azt a sebességet, amellyel bemutatja a Felhasználónak a teljesen betöltött felhasználói felületet, amely gyakran az adatbázisból származó adatoktól függ. elkerülhetetlenül elkezdi keresni az adatok feloldásának módjait az alkalmazás új oldalára/területére történő navigálás után, anélkül, hogy a felhasználó találkozna az úgynevezett oldal JANKKAL. Ez […]

mint fejlesztő, akkor mindig keres, hogy optimalizálja a kódot. Ez magában foglalja azt a sebességet, amellyel bemutatja a Felhasználónak a teljesen betöltött felhasználói felületet, amely gyakran az adatbázisból származó adatoktól függ.

elkerülhetetlenül elkezdi keresni az adatok feloldásának módjait az alkalmazás új oldalára/területére történő navigálás után, anélkül, hogy a felhasználó találkozna az úgynevezett oldal JANKKAL.

Ez az, amikor az oldal fel-le mozog bizonyos összetevők betöltése közben. Jelentősen befolyásolhatja az UX-t addig a pontig, ahol hibásnak tűnik.

az Angular intuitív megközelítést biztosít az adatok előzetes lekéréséhez az útvonal betöltése előtt; mielőtt a navigált útvonal megoldódik.

ezt Szögfeloldónak nevezik.

egy szögletes Resolver lényegében egy szögletes szolgáltatás. Injektálható osztály, amelyet az útvonal konfigurációjában egy útválasztási modulhoz ad meg. Ez a speciális típusú szolgáltatás akkor kerül bevezetésre és végrehajtásra, amikor a tartalmazó útvonalat navigálják.

ezután a feloldó feloldja az adatokat az oldal betöltése előtt, amely a ActivatedRoute szolgáltatáson keresztül válik elérhetővé. Ez egyszerű és hatékony módot biztosít annak biztosítására, hogy a felhasználó a lehető leggyorsabban rendelkezzen az adatokkal, mielőtt a kezdeti oldalbetöltés szempontjából fontos összetevőnek szüksége lenne rá.

A szögletes Resolver használatának másik módja az, ha módszerként használja a SEO metaadatok azonnali feltöltésére.

a resolverrel garantálja, hogy az adatok az oldal betöltése előtt is léteznek, biztosítva, hogy minden az inicializáláshoz szükséges legyen.

bontsuk le az Angular Resolver

az Angular resolver egy osztály, amely megvalósítja aResolve felületet. A Resolveinterfész megköveteli aresolve nevű függvény implementálását az osztályon belül.

itt van a Resolve interface signature…

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

amint az interfész aláírásából láthatjuk, általános argumentumot igényel T amely a megoldott adatok típusa lesz.

a resolve függvény egy ObservablePromisevagy csak a T típusú adatokat ad vissza . Ezért van egy javaslat, hogy ezt aszinkron módon kell kezelni, különösen akkor, ha az adatokat az adatbázisból tölti le.

a resolve függvény fő célja, hogy teljesítse. Ezt a tényt figyelembe kell venni, amikor az adatokat megfigyelhetővé teszik. A megfigyelhetőnek teljesnek kell lennie. Végül is ez egy megoldó.

Ha a megfigyelhető nem fejeződik be, akkor az adatok soha nem oldódnak meg, és az oldal soha nem töltődik be. Ezért meg kell határoznia azt a pontot, ahol nem kell több értéket felvennie, és az adatok megoldhatók, mivel mindent megtalált, amire szüksége van az adatbázisból. Aszinkron adatfolyamok, például megfigyelhető adatok használata esetén ez az RXJS Csővezetékes operátorainak felhasználási esete.

a csővezetékes operátorok, amelyek eszembe jutnak, amikor egy feltételen alapuló adatfolyam befejezésére gondolnak, a filtertakefirst kombinációja . Ezzel a kombinációval szűrheti az összes olyan értéket, amelyet nem szeretne venni, például null vagy undefined vagy egy üres tömb , majd take az első érvényes érték a take(1).

azok az operátorok, amelyekre szükség lehet egy megfigyelhető korai befejezéséhez, amikor olyan problémákkal vagy hibákkal találkozik, amelyekben nullát vagy átirányítást szeretne visszaadni, acatchError éstimeout . A timeout és catchError kombinációja akkor hasznos, ha az adatok túl sokáig tartanak, és vissza szeretné adni a null értéket, hogy újra megpróbálhassa az összetevő belsejében, vagy átirányítani szeretné.

ha az adatok nem oldódnak meg gyorsan, összetett szűrésen, logikán, hatalmas mennyiségű adatbázis-híváson alapul, akkor valószínűleg időről időre problémákat tapasztal.

a legjobb, ha meghatározzuk a legkevesebb adatbázis-hívást, valamint a minimális adatokat, amelyek szükségesek az oldal sikeres és kecses betöltéséhez.

következésképpen hasznos lehet, ha a resolver bevezetése előtt időt fordít arra, hogy elkülönítse a ‘hajtás felett’ tartalmat az oldal inicializálásakor betölthető adatoktól.

ezért megoszthatja a sima UX-hez szükséges adatokat az összetevőből meghívható többi adatból, nem pedig a resolverből.

ezután kizárólag a minimális, a hajtás feletti tartalommal foglalkozhat a felbontón keresztül.

az oldal betöltésének ez a dinamikus megközelítése csontvázak használatával segíthető. Annak érdekében, hogy ha a felhasználó azonnal lefelé görget, akkor jelezheti a felhasználónak, hogy a tartalom betöltődik, később javítva az UX-t.

1. lépés: A Resolver létrehozása

létre kell hoznunk a szögletes Resolvert. Nincs azonban olyan szögletes CLI parancs, amely feloldót generálna. Ezért magunknak kell megírnunk a dekoratőrt (resolver metaadatokat).

szerencsére csak néhány sornyi kód alkotja a feloldó kazánját, és az injektálható lakberendezőt egy meglévő szolgáltatásból is elvihetjük, ha nehezen emlékszel rá.

jegyezze fel a Profilfeloldó osztályt egy injektálható dekorátorral

először az injektálható dekorátort biztosítjukprovidedIn: any a konfigurációban.

@Injectable({ providedIn: 'any'})

ezután elnevezzük a megoldónkat a konvenció hozzáfűzésévelResolver. Ebben a példában a profiladatokat (felhasználói adatokat) oldjuk meg, ezért hívjuk ProfileResolver .

mivel ez egy resolver, és az Angular felismeri a resolverek funkcióját, megvalósíthatjuk a Resolve osztályt, amely biztosítja az aláírást, amelyet a resolve funkciónkban végre kell hajtanunk az adatok sikeres feloldásához.

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

a resolve függvényünk aProfile interfésznek megfelelő adatokkal rendelkező megfigyelhető értéket ad vissza. Ezért megadjuk aProfile interfészt a resolver osztály általános argumentumaként és aresolve() függvényt. Így már megfelelt szög követelmények egy resolver.

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

a resolve implementáció két paramétert ad meg, ha szükséges, routeés state. Ezek automatikusan feltöltődnek, és a resolve() funkciónkból érhetők el.

ezután ténylegesen meg kell oldanunk a valós adatokat az adatbázisból, ami a következő lépés.

Adatok lekérése az adatbázisból

a resolve funkciónk adatainak lekéréséhez be kell adnunk az adatokat szolgáltató szolgáltatást; az egyik, amely kölcsönhatásba lép az adatbázissal.

azt vesszük ki belőle, amire szükségünk van a gyors megoldáshoz, hogy a felhasználó gyorsan és sikeresen navigáljon. Ennek a bemutatónak az alkalmazásában nem fogunk aggódni az alapul szolgáló szolgáltatás miatt, amely az adatbázissal foglalkozik. Csak a dependency injection használatával adjuk be a szolgáltatást a ProfileResolver osztály konstruktor argumentumában.

mivel az adataink megfigyelhető adatfolyam formájában érkeznek, több értékkel, amelyek aszinkron módon bocsátanak ki, csak take(1)a csővezetékes operátor használatával takeimportált rxjs/operator. Máskülönben a megfigyelhető soha nem teljesedne be, és a feloldó soha…nem oldódna meg.

csak egy emisszióra/értékre van szükségünk, és a take befejezi a számunkra megfigyelhető értéket.

Ez olyan egyszerű, mint, hogy hozzon létre egy resolver; csak meg kell, hogy visszatérjen a megfigyelhető a resolve() függvény, amely angular kezeli az előfizetés.

a ProfileResolver osztály

az adatok lekérésével kapcsolatos hibákat a szülő útvonalra történő átirányítással kezeljük.

bónusz: A dinamikus SEO metaadatok gyors feltöltése az útvonal betöltése előtt

a <meta> címkék feltöltésének előnyei azonnal nyilvánvaló előnyökkel járnak. Minél gyorsabban töltődik be SEO metaadataink,annál gyorsabban tükrözi helyesen és pontosan az oldal tartalmát.

Ez azt jelenti, hogy a robotok, mint például a Google és a Bing által működtetett robotok, könnyebben és gyorsabban feltérképezik a webhelyet, és letöltik a tartalmat.

Ez nem olyan fontos az előre renderelt oldalakon, vagy azokon, amelyeket az Angular Universal renderel, mert az összes renderelés befejeződött, mielőtt a robotok megkapják a tartalmat.

Ha azonban a google robotok (gyakran megkérdőjelezhető) képességére támaszkodik a SEO javascript elemzésére, vagy van egy igény szerinti megoldása, mint például a puppeteer, amely biztosítja, hogy a SEO helyes lesz, mielőtt visszaadja a renderelt DOM-ot, akkor a SEO-t tartalmazó resolvernek segítenie kell. Tehát segít, ha a bejáró időben korlátozott.

ezenkívül elválasztja az aggodalmakat az összetevőtől, így az összetevőnek nem kell foglalkoznia a SEO-val kapcsolatos dolgokkal. Az egyik fő oka annak, hogy szeretem a resolvereket.

2.lépés: fecskendezze be a resolvert az útválasztási modulba

a profileroutingmodule, ahol a resolverünket biztosítjuk, egy lusta betöltött modul. Ezért a gyökérútvonalunk üres lesz a userSlug paraméter tokennel , amelyre szükségünk lesz a helyes profiladatok lekéréséhez.

a megoldónk megadásához csak egy objektumot adunk meg, amelynek kulcsa az adataink neve, az adott megoldó pedig az az érték, amely az adatok feloldásáért felelős.

a kulcsot tetszés szerint nevezhetjük el, de csak adatnak hívjuk.

Profileroutingmodule

Ez minden, ami szükséges az útválasztási modulban, hogy használhassuk a resolverünket.

ezután le kell töltenünk és használnunk kell az adatokat az összetevőben.

3. lépés: Az összetevő inicializálása megoldott adatokkal

most, hogy megoldottuk az útvonal aktiválására vonatkozó adatainkat, az adatok a ActivatedRoute szolgáltatáson keresztül érhetők el. Mivel megfigyelhető dolgokkal foglalkozunk, az alkalmazás során létrehozunk egy adatfolyamot, amely kötődik a data tulajdonsághoz, amely a megoldott adataink lesznek.

először adjuk be aActivatedRouteaProfileComponent konstruktorába . Ezután hozzárendeljük this.route.data a profile$ megfigyelhető. Azt is szeretnénk váltani egy megfigyelhető használatára, amikor frissített adatok érkeznek az adatbázisból, hogy friss adatok legyenek az alkalmazással való interakció során.

ehhez a startWithértéket fogjuk használni, hogy az adatfolyamot azzal az értékkel kezdjük, amely könnyen elérhető a this.route.snapshot.data. Ezután hozzáférünk a datatulajdonsághoz, mint a this.route.snapshot.datastartWith egy kezdő értéket jelöl, mint az adatfolyamunk első kibocsátását.

Profilösszetevőnk

mit jelent az azonnal hozzáférhető adatok az összetevőhöz

az azonnal hozzáférhető adatok csökkentik az oldal egyes részeinek betöltésével töltött időt, amelyet a felhasználó megfigyel. Ha nem használ ilyen felbontót, az az eredmény, hogy az oldal töredezett módon töltődik be, ami vizuálisan nem kellemes.

következésképpen figyelni kell arra, hogy a HTML-sablonok mely elemei függenek az adatoktól. Ezután írja meg a resolverét, hogy támogassa ezeket az elemeket és az oldal betöltésének általános hatását.

az összetevő többféle módon töltheti be a töredezett

  • ezek egyike az, ha van egyngIf A HTML sablon több részében.
  • egy másik angFor.

a legjobb gyakorlat, hogy korlátozza az egyes ngIf ‘s ír abból a célból, hogy korlátozza az összeg átméretezés a böngésző kell tennie.

az oldal betöltése az adatok megszerzése előtt az oldal egyes részeinek ugrását, késését és átméretezését okozhatja, ami az UX szenvedését okozhatja.

a resolver megvalósítása lehet a különbség a felhasználó 3-5 másodperces ugrása és átméretezése között, szemben a 0,5 másodperccel, ami gyakran túl gyors ahhoz, hogy károsítsa az Általános UX-t.

ez az! Van egy felbontónk, amelynek továbbfejlesztett UX-je van az oldal betöltésekor.

Vélemény, hozzászólás?

Az e-mail-címet nem tesszük közzé.