På det seneste er NextJS blevet mere og mere populært som en måde at bygge React-applikationer på. En stor del af forklaringen er helt sikkert, at NextJS tilbyder flere forskellige datahentningsstrategier.
Og det er disse:
Rendering på klientsiden: CSR,
Rendering på serversiden: SSR,
Rendering af statiske sider: SSG,
Inkrementel statisk regenerering: ISR.
NextJS tilbyder i modsætning til den almindelige React-app en funktion, der kaldes pre-rendering. Det betyder, at pre-renderet HTML vises under den første indlæsning. I traditionelle React-applikationer indlæses og renderes hele appen på klientens side. Derefter, efter at JS Kode er indlæst, bliver applikationen interaktiv.
Statisk generering
I SSG genereres HTML'en i build-tiden og genbruges for hver anmodning. Når et produktionsbuild er oprettet, vil alle anmodninger genbruge den statisk genererede HTML-fil.
Der findes også to typer statisk generering: med og uden data.
I det første tilfælde vil HTML'en blive genereret efter at have hentet dataene ved at løse løftet. I dette tilfælde kan vi bruge dataindhentningsmetoden getStaticProps ... men kun hvis du bruger Next.js 9.3 eller nyere. Hvis ikke, bør du overveje at opgradere den, fordi den ældre getInitialProps-metode ikke længere anbefales og vil blive forældet. Denne metode kaldes også i hver eneste navigation på klientsiden, så den er ikke effektiv, hvis du ikke ønsker at hente data ved hver eneste anmodning.
Den virkelig seje ting er en nyligt udgivet funktion kaldet ISR (Incremental Static Regeneration), som er en mellemting mellem SSG og SSR. Den giver dig mulighed for (ved at bruge en bestemt nøgle kaldet revalidate) at gøre siden trinvist regenereret. Det betyder, at du med denne nøgle ikke behøver at genopbygge appen, hver gang du ønsker at få en opdatering af de data, der hentes fra serveren. Du skal bare tilføje revalidate-nøglen med revalideringsperioden i sekunder.
Det betyder, at hvis der kommer anmodninger efter denne periode, vil den hente dataene fra serveren igen.
En anden situation er, når du bruger en dynamisk side, og stien afhænger af nogle eksterne data. I det tilfælde kan vi bruge metoden getStaticPaths til at fortælle, hvilke dynamiske ruter der skal forudindlæses:
export async const getStaticProps = ({ params }) => {
const res = await fetch(`https://jsonplaceholder.typicode.com/posts/${params.id}`);
const post = await res.json();
return {
props: { post },
};
}
Der er en god måde at tjekke, hvilke dynamiske ruter der er blevet oprettet. Du kan køre den næste build og den næste export, og derefter vil du have en statisk version af din app i det nyoprettede out directory.
Når vi har kørt den næste eksport, kan vi i begge tilfælde (med og uden et begrænset antal stier) se et forskelligt antal indlæg i my-appoutposts.
Lad os nu se nærmere på den vigtige og nødvendige fallback-parameter. Den siger, hvad der skal gøres, hvis siden ikke var pre-renderet på build-tidspunktet. Hvis den er sat til true, kører getStaticProps og genererer den pågældende side. Hvis den er false, får vi 404 efter at have forsøgt at indlæse den specifikke sti. En anden ting: Sider med fallback, der er aktiveret i getStaticPaths, kan ikke eksporteres.
Nedenfor kan du se resultaterne af forsøget på at indlæse den samme dynamiske side i begge tilfælde:
Første tilfælde (uden begrænsede stier)
Andet tilfælde (med begrænsede stier og fallback sat til false)
Andet tilfælde (med begrænsede stier og fallback sat til true)
Rendering på serversiden
Den største forskel med SSG er, at der genereres ny HTML ved hver anmodning. Det bruges mest, når vi henter nogle eksterne data. I dette tilfælde er det ikke nødvendigt at genopbygge appen, hver gang vi ønsker at opdatere data fra serveren.
Metoden getServerSideProps ligner meget metoden getStaticProps. Forskellen er, at getServerSideProps kører ved hver forespørgsel, mens getStaticProps kører én gang i build-tiden.
Rendering på klientsiden
Med rendering på klientsiden er den første indlæsning af siden lidt langsom. Kommunikationen med serveren sker i run-time. Du kan gøre det på en mere traditionel måde:
Vi kan også bruge en anden løsning, 'swr' - React Hooks library for data fetching by Vercel*, som anbefales kraftigt af NextJS-skaberne. SWR står for State While Revalidate.
NextJS giver os yderligere mulighed for at vælge, hvilken af datahentningsstrategierne vi vil bruge på hver side. Vi behøver ikke kun at følge én løsning for hele applikationen.
Genvej
getServerSideProps - når du har brug for at pre-rendere appen ved hver anmodning med hentede data
getStaticProps - når dataene kan hentes én gang på build-tidspunktet og bruges ved hver anmodning uden opdatering
getInitialProps - anbefales ikke, vil blive forældet
getStaticPaths - til pre-rendering af dynamiske stier