The playground

More information here

tasaisempi UX sivun kuormituksessa Kulmaresolvereilla

kehittäjänä haluat aina optimoida koodisi. Tämä sisältää nopeuden, jolla esität käyttäjälle täysin ladatun käyttöliittymän, joka on usein riippuvainen tietokannasta tulevista tiedoista. väistämättä alkaa etsiä tapoja ratkaista tietoja heti navigoitaessa sovelluksen uudelle sivulle / alueelle ilman, että käyttäjä kohtaa niin sanotun page Jankin. tällöin sivu liikkuu ylös ja alas tiettyjä komponentteja ladatessa. Se voi merkittävästi vaikuttaa […]

kehittäjänä haluat aina optimoida koodisi. Tämä sisältää nopeuden, jolla esität käyttäjälle täysin ladatun käyttöliittymän, joka on usein riippuvainen tietokannasta tulevista tiedoista.

väistämättä alkaa etsiä tapoja ratkaista tietoja heti navigoitaessa sovelluksen uudelle sivulle / alueelle ilman, että käyttäjä kohtaa niin sanotun page Jankin.

tällöin sivu liikkuu ylös ja alas tiettyjä komponentteja ladatessa. Se voi merkittävästi vaikuttaa UX siihen pisteeseen, jossa se näyttää ”buginen”.

Angular tarjoaa intuitiivisen lähestymistavan tietojen ennakkohakuun ennen reittilatauksia; ennen suunnistusreitin ratkaisemista.

sitä kutsutaan Kulmaratkaisijaksi.

Kulmaresolveri on oleellisesti Kulmaresolveri. Injektoitava luokka, jonka annat reititysmoduulille reittiasetuksissa. Tämä erityinen palvelu ruiskutetaan ja suoritetaan, kun sisältävää reittiä navigoidaan.

ratkaisija purkaa tämän jälkeen tiedot ennen sivukuormaa, joka tulee saataville ActivatedRoute – palvelun kautta. Tämä tarjoaa yksinkertaisen ja tehokkaan tavan varmistaa, että käyttäjällä on tiedot mahdollisimman nopeasti ennen kuin alkuperäisen sivun kuormituksen kannalta tärkeä komponentti tarvitsee sitä.

toinen tapa käyttää Kulmaresolveria on käyttää sitä menetelmänä, jolla SEO-metadata kansoitetaan heti.

resolverilla taataan, että tieto on olemassa ennen kuin sivu on ladattu, varmistaen, että kaikki on sitä, mitä se tarvitsee alustettaessa.

eritellään Kulmaresolveri

Kulmaresolveri on luokka, joka toteuttaa Resolve rajapinnan. Resolve – liitäntä edellyttää, että luokan sisällä toteutetaan funktio nimeltä resolve.

tässä on Resolve-rajapinnan allekirjoitus…

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

kuten rajapinnan allekirjoituksesta näkyy, se vaatii yleisen argumentin T, joka on selvitetyn datamme tyyppi.

resolve-funktio palauttaa ObservablePromise tai vain tyypin T . Siksi on ehdotettu, että tämä olisi käsiteltävä asynkronisesti, varsinkin jos haetaan tietoja tietokannasta.

resolve-funktion päätarkoitus on, että sen on täydennettävä. Tämä seikka on muistettava, kun haetaan tietoja havainnoitavissa. Havaittava on täytettävä. Loppujen lopuksi se on ratkaisija.

Jos havaittava ei täydenny, tieto ei koskaan ratkea, eikä sivu koskaan lataudu. Siksi, sinun täytyy määritellä kohta, jossa sinun ei tarvitse ottaa enää arvoja ja tiedot voivat ratkaista, koska sinulla on kaikki mitä tarvitset tietokannasta. Käytettäessä asynkronisia datavirtoja, kuten havainnoitavia, tämä on rxjs: n pipeable operatorsin käyttötapaus.

pipetoitavat operaattorit, jotka tulevat mieleen ajateltaessa tietovirran täydentämistä jonkin ehdon perusteella, on yhdistelmä filtertakefirst . Tällä yhdistelmällä voit suodattaa kaikki arvot, joita et halua ottaa, kuten null tai undefined tai tyhjä array , sitten take ensimmäinen kelvollinen arvo take(1).

operaattorit, joita saatetaan tarvita havaittavan tehtävän suorittamiseen varhaisessa vaiheessa kohdatessasi ongelmia tai virheitä, joissa haluat palauttaa nollan tai uudelleenohjata, ovat catchError ja timeout . Yhdistelmä timeout ja catchError on hyödyllinen, jos tietosi kestävät liian kauan ja haluat palauttaa null, jotta voit yrittää uudelleen komponentin sisällä tai haluat uudelleenohjata.

Jos tietosi eivät ratkea nopeasti, perustuvat monimutkaiseen suodatukseen, logiikkaan, valtaviin määriin tietokantapuheluita, koet todennäköisesti ongelmia aika ajoin.

on parasta määrittää pienin määrä tietokantapuheluita, sekä vähimmäistiedot, joita tarvitaan sivun lataamiseen onnistuneesti ja sulavasti.

näin ollen saatat hyötyä siitä, että käytät jonkin aikaa, ennen kuin otat resolverisi käyttöön, keskittyäksesi erottamaan ”above the fold” – sisällön tiedoista, jotka voidaan ladata sivun alustuksen yhteydessä.

näin ollen tasaiseen UX: ään tarvittavat tiedot voidaan jakaa resolverin sijaan muusta aineistosta, jota voidaan kutsua komponentista.

tämän jälkeen voit käsitellä ainoastaan minimaalista, taitoksen yläpuolista sisältöä resolverin kautta.

tätä dynaamista lähestymistapaa sivujen lataamiseen voidaan avustaa luurankojen avulla. Niin, että jos käyttäjä rullaa alas heti, voit antaa käyttäjälle merkinnän, että sisältö ladataan, myöhemmin parantaa UX.

Vaihe 1: Luodaan resolveri

meidän täytyy luoda Kulmaresolveri. Kulmikas CLI-komento ei kuitenkaan luo resolveria. Siksi meidän täytyy kirjoittaa decorator (resolver metadata) itse.

onneksi ratkaisijan keittolevy muodostuu vain muutamasta rivistä koodia, ja voimme ottaa injektoitavan sisustajan olemassa olevasta palvelusta, jos sinulla on vaikeuksia muistaa sitä.

merkitse Profiilin Resolveriluokka injektoitavalla sisustajalla

ensin annamme injektoitavalle sisustajalle providedIn: any kokoonpanossa.

@Injectable({ providedIn: 'any'})

nimeämme ratkaisijamme liittämällä yleissopimukseen Resolver . Tässä esimerkissä selvitämme profiilitietoja (käyttäjätietoja), joten kutsumme sitä nimellä ProfileResolver .

koska se on resolveri, ja kulmikas tunnistaa resolverien funktion, voimme toteuttaa Resolve luokan, joka antaa allekirjoituksen, joka meidän on toteutettava resolvifunktiossamme datan ratkaisemiseksi onnistuneesti.

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

resolve-funktiomme palauttaa havaitun tiedon Profile – rajapinnan mukaisesti. Siksi tarjoamme Profile – rajapinnan yleisenä argumenttina resolveriluokalle ja resolve() – funktiolle. Näin olemme mukautuneet resolverin Kulmavaatimuksiin.

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

resolve-toteutus antaa tarvittaessa kaksi parametria, route ja state . Nämä ovat automaattisesti asuttuja, ja ne ovat käytettävissä resolve() funktion sisällä.

seuraavaksi meidän on ratkaistava todelliset tiedot tietokannasta, mikä on seuraava askeleemme.

noudetaan tietoja tietokannasta

hakeaksemme tiedot resolve-toimintoamme varten, meidän on ruiskutettava palvelu, joka tarjoaa tiedot; palvelu, joka on vuorovaikutuksessa tietokannan kanssa.

otamme siltä tarvitsemamme ratkaisun nopeasti, jotta käyttäjä navigoi nopeasti ja onnistuneesti. Tätä demoa varten emme murehdi taustalla olevaa palvelua, joka käsittelee tietokantaa. Pistämme palvelun vain riippuvuussuihkulla constructor-argumentissa ProfileResolver Luokka.

koska tietomme tulee havaittavan datavirran muodossa, jossa on useita arvoja, jotka säteilevät asynkronisesti, meidän tarvitsee vain take(1) pipeable operator take tuotu rxjs/operator . Muuten havaittava ei koskaan päättyisi,eikä ratkaisija koskaan … päättyisi.

tarvitsemme vain yhden emission/arvon ja take täydentää havaitun meille.

resolverin luominen on niin yksinkertaista; täytyy vain palauttaa resolve() funktio, joka angular hoitaa tilauksen.

ProfileResolver-Luokka

hoidamme mahdolliset virheet tietojen hakemisessa ohjaamalla ne emoreitille.

Bonus: Populate dynaaminen SEO metadata nopeasti ennen kuin reitti on ladattu

<meta> tagien kansoittamisesta on heti ilmeisiä etuja. Mitä nopeammin SEO metadata on asuttu, sitä nopeammin SEO oikein ja tarkasti heijastaa sivun sisältöä.

tämä tarkoittaa, että robottien, kuten Googlen ja Bingin kaltaisten hakukoneiden, on helpompi ja nopeampi ryömiä sivustoosi ja hakea sisältö.

tämä ei ole niin tärkeää esirenderöidyillä sivuilla tai niillä, jotka ovat Angular Universalin renderöimiä, koska kaikki renderöinti on valmis ennen kuin robotit saavat sisällön.

kuitenkin, jos luotat Googlen robottien (usein kyseenalaiseen) kykyyn jäsentää JavaScriptiä SEO: llesi, tai sinulla on-demand-ratkaisu, kuten nukketeatteri, joka tarvitsee varmuuden siitä, että SEO on oikea ennen kuin palautat RENDERÖIDYN DOM: n, niin resolverin, joka sisältää SEO: n, pitäisi auttaa. Joten se auttaa, kun crawler on aikarajoitettu.

se myös erottaa huolet komponentista, jolloin komponentin ei tarvitse käsitellä mitään hakukoneoptimointiin liittyvää. Yksi tärkeimmistä syistä, miksi pidän resolvers.

Vaihe 2: pistä resolveri reititysmoduuliin

Profileroutingmoduuli, jossa tarjoamme resolverimme on laiska ladattu moduuli. Siksi juuripolkumme on tyhjä parametritunnuksella userSlug , josta meidän on haettava oikeat profiilitiedot.

tarjotaksemme ratkaisijamme, annamme vain objektin, jonka avaimena on tietomme nimi ja arvona tietty ratkaisija, joka vastaa kyseisen tiedon ratkaisemisesta.

voit nimetä avaimen miksi haluat, mutta kutsumme sitä vain dataksi.

meidän ProfileRoutingModule

muuta ei tarvita reititysmoduulissa, jotta voimme käyttää resolveriamme.

seuraavaksi meidän on haettava ja käytettävä dataamme komponentissa.

Vaihe 3: Alustaa komponentti ratkaistuilla tiedoilla

nyt kun olemme selvittäneet tietomme reitin aktivoinnista, tiedot ovat saatavilla ActivatedRoute – palvelun kautta. Koska kyseessä on havainnoitavat kohteet, koko sovelluksen ajan luomme data – ominaisuuteen sitoutuvan virran, joka on selvitetty datamme.

ensin pistetään ActivatedRoute meidän ProfileComponent . Seuraavaksi this.route.dataprofile$ havainnoitavissa. Haluamme myös siirtyä käyttämään havainnoitavaa, kun päivitetyt tiedot saapuvat tietokannasta, jotta meillä on tuoretta tietoa, kun olemme vuorovaikutuksessa sovelluksen kanssa.

tähän käytämme startWith niin, että aloitamme virtamme arvolla, joka on helposti saatavilla this.route.snapshot.data. Tämän jälkeen käytetään data omaisuutta kuten this.route.snapshot.datastartWith osoittaa arvon, jolla aloittaa, ensimmäisenä virtamme emissiona.

Profiilikomponenttimme

se, mitä välittömästi saatavilla oleva tieto tekee komponentille

välittömästi saatavilla oleva tieto vähentää käyttäjän havaitsemaa kyseisen sivun yksittäisten osien lataamiseen käytettyä aikaa. Jos tällaista resolveria ei käytetä, sivu saattaa näyttää latautuvan hajanaisesti, mikä ei ole visuaalisesti miellyttävää.

näin ollen sinun on kiinnitettävä huomiota siihen, mitkä HTML-mallineesi elementit riippuvat mistäkin datasta. Sinun pitäisi sitten kirjoittaa resolverisi tukemaan näitä elementtejä ja yleistä vaikutusta sivun lataamiseen UX.

on olemassa useita tapoja, joilla komponentti voi ladata pirstaloituneena

  • yksi näistä on, jos ngIf useassa HTML-mallin osassa.
  • toinen on ngFor .

on hyvä käytäntö rajoittaa ngIf kirjoittamaasi määrää, jotta voidaan rajoittaa selaimen koon muuttamista.

sivun lataaminen ennen tietojen saamista voi aiheuttaa sen, että osa sivusta hyppää, viivyttää ja muuttaa kokoaan jatkuvasti, jolloin UX kärsii.

resolverin käyttöönotto voi olla ero 3-5 sekunnin hyppäämisen ja koon muuttumisen välillä verrattuna 0,5 sekuntiin, mikä on usein liian nopeaa vahingoittaakseen yleistä UX: ää.

That ’ s it! Meillä on resolveri, jossa on parannettu UX sivun kuormituksessa.

Vastaa

Sähköpostiosoitettasi ei julkaista.