Viimasel ajal kogub NextJS üha suuremat populaarsust React rakenduste loomise viisina. Kindlasti aitab sellele oluliselt kaasa asjaolu, et NextJS pakub mitmeid erinevaid andmehõivamisstrateegiaid.
Ja need on järgmised:
Kliendipoolne renderdamine: CSR,
Serveripoolne renderdamine: SSR,
Staatiline saidi kuvamine: SSG,
Inkrementaalne staatiline regenereerimine: ISR.
NextJS pakub erinevalt tavalisest React rakendusest funktsiooni, mida nimetatakse eelrenderdamiseks. See tähendab, et esialgse laadimise ajal kuvatakse eelrenderdatud HTML-i. Traditsioonilistes React rakendustes laaditakse ja renderdatakse kogu rakendus kliendi poolel. Seejärel, pärast JS kood laaditakse, muutub rakendus interaktiivseks.
Staatiline põlvkond
SSGs genereeritakse HTML vormingu koostamise ajal ja seda kasutatakse iga taotluse puhul uuesti. Pärast tootmiskoostu loomist kasutab iga taotlus seda staatiliselt genereeritud HTML-faili uuesti.
Samuti on olemas kahte tüüpi staatilist genereerimist: andmetega ja ilma andmeteta.
Esimesel juhul genereeritakse HTML pärast andmete kättesaamist lubaduse lahendamise teel. Sellisel juhul saame kasutada andmete kättesaamise meetodit getStaticProps... aga ainult siis, kui kasutate Next.js 9.3 või uuemat versiooni. Kui mitte, siis mõelge selle uuendamisele, sest vanem getInitialProps meetod ei ole enam soovitatav ja see kaotab kehtivuse. Seda meetodit kutsutakse ka igas kliendipoolses navigeerimises, nii et see ei ole tõhus, kui te ei soovi andmeid iga päringu puhul välja noppida.
eksport async function getStaticProps() {
const res = await fetch("https://jsonplaceholder.typicode.com/posts");
const posts = await res.json();
return {
props: { posts },
};
}
Tõeliselt lahe on äsja avaldatud funktsioon nimega ISR (Incremental Static Regeneration), mis on midagi SSG ja SSR vahelist. See võimaldab teil (kasutades spetsiaalset võtit nimega revalidate) teha lehte järk-järgult uuendada. See tähendab, et selle võtmega ei pea te rakenduse iga kord uuesti üles ehitama, kui soovite serverist hangitud andmeid uuendada. Lihtsalt lisage revalidate võti koos revalideerimisperioodiga sekundites.
eksport async function getStaticProps() {
const res = await fetch("https://jsonplaceholder.typicode.com/posts");
const posts = await res.json();
return {
props: {
posts,
},
revalidate: 30,
};
}
See tähendab, et kui päringud tulevad pärast seda ajavahemikku, siis hangib ta andmed uuesti serverist.
Teine olukord on, kui kasutate dünaamilist lehte ja tee sõltub mõnest välisest andmestikust. Sellisel juhul saame kasutada meetodit getStaticPaths, mis ütleb, milliseid dünaamilisi marsruute tuleks eelnevalt laadida:
eksport async const getStaticProps = ({ params }) => {
const res = await fetch(`https://jsonplaceholder.typicode.com/posts/${params.id}`);
const post = await res.json();
return {
props: { post },
};
}
eksport async function getStaticPaths() {
const res = await fetch("https://jsonplaceholder.typicode.com/posts");
const posts = await res.json();
const paths = posts.map(({ id }) => ({ params: { id: `${id}` } } }));
return {
paths,
fallback: false,
};
}
On hea võimalus kontrollida, millised dünaamilised marsruudid on loodud. Saate käivitada järgmise buildi ja järgmise ekspordi ning pärast seda on teie rakenduse staatiline versioon äsja loodud out-kataloogis.
Pärast järgmise ekspordi käivitamist võime täheldada mõlemal juhul (piiratud arvu teedega ja ilma) erinevat arvu postitusi, mis on leitud my-appoutposts'is.
Vaatleme nüüd lähemalt olulist ja vajalikku tagavaraparameetrit. See ütleb, mida teha, kui lehte ei ole build-time'i ajal eelnevalt renderdatud. Kui selle väärtuseks on seatud true, käivitub getStaticProps ja genereerib selle lehe. Kui false, siis saame pärast selle konkreetse tee laadimise katsetamist tulemuseks 404. Veel üks asi: lehed, mille fallback on getStaticPathsis lubatud, ei saa eksportida.
Allpool on esitatud tulemused, mis saadi, kui prooviti laadida sama dünaamilist lehte mõlemal juhul:
Esimene juhtum (ilma piiratud radadeta)
Teine juhtum (piiratud teekondadega ja tagasipöördumine, mille väärtuseks on seatud false)
Teine juhtum (piiratud teekondadega ja tagasipöördumine, mis on seatud tõeseks)
Serveri-poolne renderdamine
Peamine erinevus SSG-ga: iga taotluse korral genereeritakse uus HTML. Seda kasutatakse peamiselt siis, kui me hangime mingeid väliseid andmeid. Sellisel juhul ei ole vaja rakendust iga kord uuesti üles ehitada, kui tahame andmeid serverist uuendada.
eksport async function getServerSideProps() {
const res = await fetch("https://jsonplaceholder.typicode.com/posts");
const posts = await res.json();
return {
props: {
posts,
},
};
}
Meetod getServerSideProps näeb välja väga sarnane getStaticProps meetodiga. Erinevus seisneb selles, et getServerSideProps käivitub iga taotluse korral, samas kui getStaticProps käivitub üks kord koostamise ajal.
Kliendipoolne renderdamine
Kliendipoolse renderdamise puhul on lehe esialgne laadimine veidi aeglane. Sidepidamine serveriga toimub tööajal. Seda saab teha traditsioonilisemal viisil:
Samuti saame kasutada teist lahendust, "swr" - React Hooks raamatukogu andmete kättesaamiseks Vercel*, mida NextJS loojad tungivalt soovitavad. SWR tähistab State While Revalidate.
NextJS annab meile lisavõimaluse valida, millist andmehankestrateegiat me soovime igal lehel kasutada. Me ei pea järgima ainult ühte lahendust kogu rakenduse jaoks.
Otsetee
getServerSideProps - kui teil on vaja iga taotluse puhul eelnevalt renderdada rakendust koos hangitud andmetega.
getStaticProps - kui andmeid saab kätte üks kord ehitamise ajal ja neid saab kasutada iga taotluse korral ilma uuendusteta
getInitialProps - ei ole soovitatav, kaotab kehtivuse.