JavaScripti raamistikud / teegid, näiteks Vue, võivad teie saidi sirvimisel pakkuda fantastilist kasutuskogemust. Enamik pakub viisi lehe sisu dünaamiliseks muutmiseks, ilma et peaks iga kord serverile päringut saatma.

Sellel lähenemisel on siiski küsimus. Esialgu oma veebisaidi laadimisel ei saa teie brauser kuvamiseks tervet lehte. Selle asemel saadetakse lehe koostamiseks hunnik tükke (HTML, CSS, muud failid) ja juhised nende kõigi kokku panemiseks (JavaScripti raamistik / teek) Kogu selle teabe kokku panemine võtab mõõdetavalt palju aega enne, kui teie brauseril on tegelikult midagi kuvada. See on nagu oleks saadetud hunnik raamatuid koos tavalise raamatukapiga. Kõigepealt peate ehitama raamatukapi ja seejärel raamatutega täitma.

Lahendus sellele on nutikas: laske veebisaidil kasutada raamistiku / teegi versiooni server see võib luua kuvamiseks valmis lehe. Seejärel saatke see täielik leht brauserisse koos võimalusega teha täiendavaid muudatusi ja teil on endiselt dünaamiline lehe sisu (raamistik / teek), nagu ka teile saadetakse valmis raamatukapp koos mõne raamatuga. Kindlasti peate raamatud ikkagi raamatukappi panema, kuid teil on kohe midagi kasutatavat.

Lisaks rumalale analoogiale on ka hunnik muid eeliseid. Näiteks harva muutuvat lehte, näiteks lehte Teave meie kohta, pole vaja uuesti luua iga kord, kui kasutaja seda küsib. Nii et server saab selle ühe korra luua ja seejärel vahemällu salvestada või kuhugi edaspidiseks kasutamiseks salvestada. Sellised kiiruse täiustused võivad tunduda pisikesed, kuid keskkonnas, kus reageerimisvõimeni kuluva aja millisekundites (või vähem) mõõtmist, loeb iga natuke.

Kui soovite lisateavet SSR-i eeliste kohta Vue keskkonnas, peaksite seda kontrollima Vue enda artikkel SSR-i kohta . Nende tulemuste saavutamiseks on erinevaid võimalusi, kuid kõige populaarsem, mis on ka soovitas Vue meeskond , Nuxt.

Miks Nuxt.js

Nuxt.js põhineb SSR-i rakendamisel populaarsel React'i teegil nimega Next. Pärast selle disaini eeliste nägemist kujundati Vue jaoks sarnane teostus nimega Nuxt. Need, kes tunnevad kombinatsiooni React + Next, avastavad rakenduse kujunduses ja kujunduses hulga sarnasusi. Siiski pakub Nuxt Vue-spetsiifilisi funktsioone, et luua Vue jaoks võimas, kuid paindlik SSR-lahendus.

Aastal värskendati Nuxt tootmiseks valmis versiooniks 1.0 Jaanuar 2018 ning on osa aktiivsest ja hästi toetatud kogukonnast. Üks suurepäraseid asju on see, et projekti ehitamine Nuxtiga ei erine nii palju kui mis tahes muu Vue projekti ehitamine. Tegelikult pakub see hulga funktsioone, mis võimaldavad teil lühikese aja jooksul luua hästi struktureeritud koodibaase.

Teine oluline asi, mida tähele panna, on Nuxt ei pea SSR-i jaoks kasutama . Seda reklaamitakse kui universaalsete Vue.js-rakenduste loomise raamistikku ja see sisaldab käsku (nuxt generate) staatiliselt loodud Vue-rakenduste loomiseks sama koodibaasi abil. Nii et kui te kardate sügavale SSR-i sukeldumist, ärge paanitsege. Võite alati luua selle asemel staatilise saidi, kasutades samal ajal Nuxt'i funktsioone.

Nuxt'i potentsiaali mõistmiseks loome lihtsa projekti. Selle projekti lõplik lähtekood on võõrustas GitHubis kui soovite seda näha või saate seda näha vaadata reaalajas versiooni loodud nuxt generate abil ja hostitud Netlify'is.

Nuxt projekti loomine

Alustamiseks kasutame Vue projekti generaatorit nimega vue-cli näidisprojekti kiireks loomiseks:

# install vue-cli globally npm install -g vue-cli # create a project using a nuxt template vue init nuxt-community/starter-template my-nuxt-project

Pärast paari valiku läbimist loob see kausta my-nuxt-project projekti või mida iganes sa täpsustasid. Siis peame lihtsalt installima sõltuvused ja käivitama serveri:

cd my-nuxt-project npm install # Or yarn npm run dev

Seal me läheme. Avage brauser localhost:3000 ja teie projekt peaks käima. Ei erine palju Vue Webpacki projekti loomisest. Kui aga vaatame rakenduse tegelikku ülesehitust, pole seal midagi eriti, eriti kui võrrelda midagi sellist nagu Vue Webpacki mall.

Vaadates package.json näitab ka seda, et meil on ainult üks sõltuvus, Nuxt ise. Seda seetõttu, et Nuxt'i iga versioon on kohandatud töötama Vue, Vue-ruuteri ja Vuexi konkreetsete versioonidega ning komplekteerib need kõik teie jaoks.

Samuti on olemas nuxt.config.js fail projekti juur. See võimaldab teil kohandada paljusid funktsioone, mida Nuxt pakub. Vaikimisi määrab see teie jaoks päisemärgendid, laadimisriba värvi ja ESLinti reeglid. Kui soovite vaadata, mida saate seadistada, siin on dokumentatsioon ; käsitleme selles artiklis mõningaid võimalusi.

Mis on nende kataloogide puhul nii erilist?

Projekti paigutus

Kui sirvite loodud katalooge, on neil kõigil kaasas olev Readme, kus on lühike kokkuvõte selles kataloogis sisalduvast ja sageli link dokumentidele.

See on üks Nuxt'i kasutamise eelis: teie rakenduse vaikestruktuur. Ükskõik hea esiotsa arendaja struktureerib sellele sarnase rakenduse, kuid neid on palju erinevad ideed struktuuride kohta ja meeskonnas töötades läheb paratamatult aega selle struktuuri arutamiseks või valimiseks. Nuxt pakub teile ühe.

Nuxt otsib teatud katalooge ja loob teie rakenduse teie jaoks sõltuvalt sellest, mida see leiab. Uurime neid katalooge ükshaaval.

Lehed

See on ainus nõutud kataloogi. Kõik selles kataloogis olevad Vue komponendid lisatakse automaatselt kausta vue-router nende failinimede ja kataloogistruktuuri põhjal. See on äärmiselt mugav. Tavaliselt oleks mul nagunii eraldi kataloog Pages ja ma peaksin kõik need komponendid käsitsi teise ruuteri faili registreerima. See ruuterifail võib suuremate projektide jaoks muutuda keerukaks ja võib loetavuse säilitamiseks vajada jagamist. Selle asemel tegeleb Nuxt kogu selle loogikaga teie eest.

Selle demonstreerimiseks võime luua Vue komponendi nimega about.vue kataloogi Pages sees. Lisame lihtsalt sellise lihtsa malli nagu:

export default { layout: 'admin-layout' }

See on kõik, mis seal on. Lehe komponendid kasutavad default paigutus, kui pole täpsustatud, kuid kui navigeerite saidile /admin, kasutab see nüüd admin-layout.vue paigutus. Muidugi võiks seda paigutust soovi korral jagada mitme administraatori ekraani vahel. Üks oluline asi, mida meeles pidada, on paigutused peavad sisaldama elementi .

Paigutuste juures on veel üks viimane asi. Võib-olla olete katsetamise ajal märganud, et kui sisestate vale URL-i, kuvatakse teile tõrke leht. See vealeht on tegelikult teine ​​paigutus. Nuxtil on oma veapaigutus ( lähtekood siin ), kuid kui soovite seda muuta, looge lihtsalt error.vue paigutus ja seda kasutatakse selle asemel. Siin on hoiatus see veapaigutusel ei tohi olla elementi . Teil on juurdepääs ka error komponent objektil koos kuvatava põhiteabega. (Kui soovite seda uurida, prinditakse see välja Nuxt käitavas terminalis.)

Vahevara

Vahevara on funktsioonid, mida saab käivitada enne lehe või küljenduse renderdamist. Seda võib teha mitmel põhjusel. Marsruudi valvamine on populaarne kasutusviis, kus saate kontrollida Vuexi poest kehtivat sisselogimist või mõne parameetri kinnitamist (selle asemel, et komponendis endas kasutada meetodit validate). Ühes projektis, mille kallal hiljuti töötasin, kasutasin vahevara, et genereerida marsruudi ja parameetrite põhjal dünaamilisi leivapuru.

Need funktsioonid võivad olla asünkroonsed; lihtsalt ole ettevaatlik, sest kasutajale ei näidata midagi enne, kui vahevara on lahendatud. Neil on juurdepääs ka Nuxt’i kontekstile, mida ma hiljem selgitan.

Pistikprogrammid

See kataloog võimaldab teil enne rakenduse loomist registreerida Vue pistikprogrammid. See võimaldab pistikprogrammi Vue eksemplaris kogu teie rakenduses jagada ja sellele pääseb juurde mis tahes komponendis.

Enamikul peamistest pistikprogrammidest on Nuxt versioon, mida saab nende dokumente järgides hõlpsalt registreerida Vue eksemplaris. Siiski on olukordi, kui töötate välja pistikprogrammi või peate selleks olemasolevat pistikprogrammi kohandama. Dokumendilt laenatud näide näitab, kuidas seda vue-notifications jaoks teha. Esiteks peame installima paketi:

npm install vue-notifications --save

Seejärel looge pistikprogrammide kataloogis fail nimega vue-notifications.js ja sisaldavad järgmist:

import Vue from 'vue' import VueNotifications from 'vue-notifications' Vue.use(VueNotifications)

Väga sarnane sellele, kuidas registreeriksite pistikprogrammi tavalises Vue keskkonnas. Seejärel muutke nuxt.config.js faili projekti juur ja lisage objektile module.exports järgmine kirje:

plugins: ['~/plugins/vue-notifications']

See on kõik. Nüüd saate kasutada vue-notifications kogu teie rakenduses. Selle näide on aadressil /plugin näidisprojektis.

Nii et see lõpetab kataloogistruktuuri ülevaatuse. See võib tunduda palju õppivat, kuid kui arendate Vue rakendust, seadistate juba samasugust loogikat. Nuxt aitab seadistamise abstraktselt eemaldada ja aitab teil ehitamisele keskenduda.

Nuxt teeb arengus siiski enamat kui abi. See ülelaadimised oma komponentide jaoks, pakkudes lisafunktsionaalsust.

Nuxt'i ülelaaditud komponendid

Kui hakkasin esimest korda Nuxtit uurima, lugesin pidevalt, kuidas on lehe komponendid ülelaaditud . See kõlas suurepäraselt, kuid polnud kohe selge, mida see täpselt tähendas ja millist kasu see toob.

See tähendab, et kõigil lehe komponentidel on lisatud lisameetodid, mida Nuxt saab kasutada täiendava funktsionaalsuse pakkumiseks. Tegelikult oleme ühte sellist juba varem näinud, kui kasutasime validate meetod parameetrite kontrollimiseks ja kasutaja ümbersuunamiseks, kui need on valed.

Kaks peamist Nuxt'i projektis kasutatavat on asyncData ja fetch meetodid. Mõlemad on kontseptsioonilt väga sarnased, neid juhitakse asünkroonselt enne komponendi loomist ning neid saab kasutada komponendi ja poe andmete täitmiseks. Samuti võimaldavad need lehe serveris täielikult renderdada enne kliendile saatmist, isegi kui peame ootama mõnda andmebaasi või API kõnet.

Mis vahe on asyncData ja fetch?

• asyncData kasutatakse lehe komponendi andmete täitmiseks. Objekti tagastamisel ühendatakse see data väljundiga enne renderdamist.
• fetch kasutatakse Vuexi poe asustamiseks. Kui tagastate lubaduse, ootab Nuxt enne renderdamist, kuni see on lahendatud.

Nii et kasutagem neid hästi. Pidage meeles varem /products/view lehel oli meil probleem, kus meie võlts-API kõne tegemise ajal kuvati korraks poe esialgset olekut? Üks võimalus selle parandamiseks on komponentile või poodi salvestatud tõeväärtus, näiteks loading = true ja seejärel kuvatakse laadimiskomponent, kuni API kõne lõpeb. Pärast määraksime loading = false ja kuvada andmed.

Kasutame selle asemel fetch enne renderdamist poodi täitma. Muutkem uuel lehel nimega /products/view-async created meetod fetch; see peaks töötama, eks?

export default { fetch () { // Unfortunately the below line throws an error // because 'this.$store' is undefined... this.$store.dispatch('product/load') }, computed: {...} }

Siit saate teada: need 'ülelaadimisega' meetodid töötavad enne komponent on loodud, seega this ei osuta komponendile ja sellel pole midagi juurde pääseda. Kuidas me siin poodi pääseme?

Konteksti API

Muidugi on lahendus olemas. Kõigi Nuxt'i meetodite puhul antakse teile argument (tavaliselt esimene), mis sisaldab äärmiselt kasulikku objekti nimega Kontekst. See on kõik, millele peate kogu rakenduses viitama, see tähendab, et me ei pea ootama, kuni Vue need viited kõigepealt komponendile loob.

Ma soovitaksin tungivalt tutvuda Kontekstidokumendid et näha, mis on saadaval. Mõned käepärased on app, kus pääsete juurde kõigile oma pistikprogrammidele redirect, mida saab kasutada marsruutide muutmiseks, error vealehe kuvamiseks ja mõned iseenesestmõistetavad, näiteks route, query ja store.

Nii et poodi pääsemiseks saame konteksti ümber struktureerida ja poe sellest välja tõmmata. Samuti peame kindlasti tagastama lubaduse, et Nuxt saaks enne komponendi renderdamist oodata selle lahendamist, nii et peame ka oma poe toimingut pisut kohandama.

// Component export default { fetch ({ store }) { return store.dispatch('product/load') }, computed: {...} } // Store Action load ({ commit }) { return new Promise(resolve => { setTimeout(() => { commit('update', { _id: 1, title: 'Product', price: 99.99 }) resolve() }, 1000) }) }

Võite kasutada async / await või muid meetodeid, sõltuvalt teie kodeerimisstiilist, kuid kontseptsioon on sama - käskime Nuxtil veenduda, et API kõne oleks lõpule viidud ja pood oleks tulemusega värskendatud enne komponendi renderdamist proovides. Kui proovite navigeerida /products/view-async, siis ei näe te sisu välku seal, kus toode on algses olekus.

Võite ette kujutada, kui kasulik võib see olla mis tahes Vue rakenduses isegi ilma SSR-ta. Kontekst on saadaval ka kasutajale kõik keskseadmed kui ka teiste Nuxt-meetoditega nagu NuxtServerInit mis on spetsiaalne kaupluse toiming, mis käivitatakse enne poe initsialiseerimist (näide sellest on järgmises jaotises)

Kaalutlused SSR-i kasutamisel

Olen kindel, et paljud (kaasa arvatud mina), kes hakkavad kasutama sellist tehnoloogiat nagu Nuxt, koheldes seda nagu muud Vue projekti, põrkavad lõpuks vastu seina, kus miski, mida me teame, tavaliselt töötab, tundub Nuxtis võimatu. Kuna rohkem neist hoiatustest on dokumenteeritud, on sellest lihtsam üle saada, kuid silumist alustades tuleb arvestada põhiliselt sellega, et klient ja server on kaks eraldi üksust.

Kui algselt lehele juurde pääsete, saadetakse Nuxtile taotlus, server ehitab nii palju kui võimalik sellest lehest ja ülejäänud rakendusest ning seejärel saadab server selle teile. Siis on klient kohustatud jätkama navigeerimist ja laadima tükke vastavalt vajadusele.

Soovime, et server teeks kõigepealt nii palju kui võimalik, kuid mõnikord puudub tal juurdepääs vajalikule teabele, mille tulemusel tehakse tööd hoopis kliendipoolselt. Või veel hullem, kui kliendi esitatud lõplik sisu erineb sellest, mida server ootas, palutakse kliendil see nullist üles ehitada. See on suur viide sellele, et rakendusloogikaga on midagi valesti. Õnneks luuakse teie brauseri konsoolis (arendusrežiimis) viga, kui see juhtuma hakkab.

Võtame näite, kuidas lahendada levinud probleem, seansihaldus. Kujutage ette, et teil on Vue rakendus, kus saate kontole sisse logida, ja teie seanss salvestatakse märgi (näiteks JWT) abil, mille otsustate säilitada localStorage Esmalt saidile sisenemisel soovite selle luba autentida API-ga, mis tagastab kehtiva põhiteabe kasutaja kohta ja paneb selle teabe poodi.

Pärast Nuxt'i dokumentide lugemist näete, et on olemas mugav meetod nimega NuxtServerInit mis võimaldab teil poodi asünkroonselt asustada üks kord algsel laadimisel. See kõlab ideaalselt! Nii et loote oma kasutajamooduli poes ja lisate vastava toimingu kausta index.js fail poe kataloogis:

export const actions = { nuxtServerInit ({ dispatch }) { // localStorage should work, right? const token = localStorage.getItem('token') if (token) return dispatch('user/load', token) } }

Lehe värskendamisel kuvatakse tõrge localStorage is not defined. Mõeldes sellele, kus see juhtub, on see loogiline. Seda meetodit käitatakse serveris, tal pole aimugi, mida localStorage -sse salvestatakse kliendi peal; Tegelikult ei tea ta isegi, mis on “localStorage”! Nii et see pole valik.

Mis on lahendus? Neid on tegelikult vähe. Võite lasta kliendil selle asemel poe lähtestada, kuid kaotate lõpuks SSR-i eelised, sest klient teeb lõpuks kogu töö. Võite seadistada seansid serveris ja seejärel kasutada seda kasutaja autentimiseks, kuid see on seadistamiseks veel üks kiht. Mis on kõige sarnasem localStorage meetod kasutab selle asemel küpsiseid.

Nuxtil on juurdepääs küpsistele, kuna need saadetakse koos kliendi palvel serveriga päringuga. Nagu teiste Nuxt meetodite puhul, nuxtServerInit on juurdepääs kontekstile, seekord teise argumendina, kuna esimene on reserveeritud poele. Kontekstis pääseme juurde req objekt, kuhu salvestatakse kõik päised ja muu teave kliendi päringust. (See on eriti tuttav, kui olete kasutanud Node.js.)

Niisiis, pärast märgi salvestamist küpsisesse (mida käesoleval juhul nimetatakse märgiks), pääseme sellele juurde serveris.

import Cookie from 'cookie' export const actions = { nuxtServerInit ({ dispatch }, { req }) '' if (token) return dispatch('user/load', token) }

Lihtne lahendus, kuid see ei pruugi kohe silma paista. Mõelda, kus toimuvad teatud toimingud (klient, server või mõlemad) ja millele neil on juurdepääs, võtab aega, kuid eelised on seda väärt.

Juurutamine

Nuxtiga juurutamine on äärmiselt lihtne. Sama koodibaasi abil saate luua SSR-rakenduse, ühelehelise rakenduse või staatilise lehe.

Serveripoolne renderdatud rakendus (SSR-rakendus)

Tõenäoliselt püüdsite seda Nuxtit kasutades. Siin on juurutamise põhikontseptsioon käivitada build töödelda mis tahes valitud platvormil ja määrata mõned konfiguratsioonid. Ma kasutan Heroku näidet dokumendid :

Kõigepealt seadistage Heroku jaoks skriptid package.json:

'scripts': { 'dev': 'nuxt', 'build': 'nuxt build', 'start': 'nuxt start', 'heroku-postbuild': 'npm run build' }

Seejärel seadistage Heroku keskkond, kasutades heroku-cli ( seadistamisjuhised siin :

# set Heroku variables heroku config:set NPM_CONFIG_PRODUCTION=false heroku config:set HOST=0.0.0.0 heroku config:set NODE_ENV=production # deploy git push heroku master

See on kõik. Nüüd on teie SSR Vue rakendus reaalajas maailmale vaatamiseks valmis. Teistel platvormidel on erinevad seadistused, kuid protsess on sarnane. Praegu on loetletud ametlikud juurutusmeetodid:

• Nüüd
• Dokku (digitaalne ookean)
• Nginx

Üheleheline rakendus (SPA)

Kui soovite ära kasutada mõnda Nuxt'i pakutavat lisavõimalust, kuid väldite serveri proovimist lehekülgi renderdada, saate selle juurutada hoopis SPA-na.

Esiteks on kõige parem testida oma rakendust ilma SSR-ta, nagu vaikimisi npm run dev töötab koos SSR-iga. Selle muutmiseks muutke nuxt.config.js fail ja lisage järgmine valik:

mode: 'spa',

Nüüd, kui käivitate npm run dev, lülitatakse SSR välja ja rakendus töötab testimiseks SPA-na. See seade tagab ka, et ükski tulevane järk ei sisalda SSR-i.

Kui kõik tundub korras, siis on juurutamine täpselt sama mis SSR-i rakendusel. Pidage meeles, et peate määrama mode: 'spa' kõigepealt andke ehitusprotsessile teada, et soovite SPA-d.

Staatilised lehed

Kui te ei soovi serveriga üldse tegeleda ja soovite selle asemel luua staatiliste hostimisteenustega nagu Surge või Netlify kasutatavad lehed, siis on see valikuvõimalus. Pidage lihtsalt meeles, et ilma serverita ei pääse te juurde req ja res kontekstis, nii et kui teie kood sellele tugineb, siis kindlasti mahutage see. Näiteks näidisprojekti genereerimisel on nuxtServerInit Funktsioon viskab vea, kuna see üritab päringu päistes olevatest küpsistest luba tuua. Selles projektis pole see oluline, kuna neid andmeid ei kasutata kusagil, kuid reaalses rakenduses peaks nendele andmetele juurdepääsemiseks olema alternatiivne viis.

Kui see on sorteeritud, on juurutamine lihtne. Üks asi, mida peate kõigepealt muutma, on valiku lisamine, nii et nuxt generate käsk loob ka varukoopia. See fail palub hostimisteenusel lasta Nuxtil marsruutimist hallata, mitte hostimisteenust, visates 404 vea. Selleks lisage rida nuxt.config.js järgmine rida:

generate: { fallback: true },

Siin on näide Netlify kasutamisest, mida praegu Nuxt'i dokumentides pole. Pidage lihtsalt meeles, et kui kasutate esimest korda netlify-cli, siis palutakse teil autentida:

# install netlify-cli globally npm install netlify-cli -g # generate the application (outputs to dist/ folder) npm run generate # deploy netlify deploy dist

See on nii lihtne! Nagu artikli alguses mainitud, on selle projekti versioon olemas siin . Allpool on olemas ka ametlik juurutusdokumentatsioon järgmiste teenuste jaoks:

• Tekib
• GitHubi lehed

Lisateave

Nuxt uueneb kiiresti ja see on ainult väike valik pakutavatest funktsioonidest. Loodan, et see artikkel julgustab teid proovima ja vaatama, kas see võib aidata teie Vue-rakenduste võimalusi parandada, võimaldades teil kiiremini areneda ja kasutada selle võimsaid funktsioone.

Kui otsite lisateavet, otsige Nuxt'i ametlikke linke:

• Dokumentatsioon
• Mänguväljak
• GitHub
• KKK

Kas otsite oma JavaScripti mängu üles? Proovige lugeda Põhjalik juhend JavaScripti kujundusmustrite kohta autor ApeeScapeer Marko Mišura.

Põhitõdesid mõistes

Mis on Vue.js?

Vue.js (või lihtsalt Vue) on JavaScripti raamistik, mis on loodud kergeks ja hõlpsasti õpitavaks, kuid samas piisavalt võimsaks suurte rakenduste haldamiseks. See võimaldab teil arendada rikkalikult interaktiivseid veebirakendusi, mis võivad pakkuda paremat kasutuskogemust.

Mis on Nuxt?

Nuxt on raamistik universaalsete Vue-rakenduste loomiseks. See tähendab, et see pakub teie projektile struktuuri, haldab teie jaoks keerulisemat serveri konfiguratsiooni ja võimaldab sama koodibaasi juurutada erinevates keskkondades.

Kas Vue ja Nuxt on avatud lähtekoodiga?

Jah, nende mõlemad koodibaasid on GitHubis avalikult vaadatavad ja neid arendatakse pidevalt. Mõlemal on põhimeeskonnad ja nende kogukonnad toetavad neid. Seal jälgitakse probleeme ja kõik on teretulnud soovitama parandusi või esitama tõmbetaotluse.

Mida tähendab kliendipool ja serveripool?

Kliendipool viitab seadmele, mida kasutatakse veebisaidi sirvimisel veebisaidi taotlemiseks ja lõpuks kuvamiseks, nt teie arvuti / tahvelarvuti / telefoni brauseriks. Serveripoolne viitab serverile, kes võtab vastu veebilehe taotluse ja saadab selle kuvamiseks sobivad failid.

Mis on serveripoolse renderdamise eelised?

SSR pakub paremat SEO-d, kiiremat esialgset laadimist ja võimalust vahemällu salvestada, kuid üldiselt tähendab see rohkem serveripäringuid ja lehtede täislaadimist. SSR-i kombineerimine kliendipoolse raamistiku (näiteks Vue) eelistega pakub rikkalikku kasutajatevahelist suhtlust ja ka DOM-i kohapealseid värskendusi, mis teeb Nuxtist suurepärase lahenduse.

Mida tähendab virtuaalne DOM?

Sellised raamistikud nagu Vue.js võimaldavad osaliselt värskendada veebilehe dokumendiobjekti mudelit (DOM). Otsesed DOM-i värskendused on siiski ajakulukad, seega selle asemel, et Vue.js 2.0, hoitakse DOM-i virtuaalset koopiat mälus, tehakse seal kõigepealt muudatusi ja tõhus värskendus lisab need muudatused perioodiliselt tegelikule DOM-ile.