Strategier for datahenting i NextJS

Og disse er..:

• Gjengivelse på klientsiden: CSR,
• Rendering på serversiden: SSR,
• Statisk gjengivelse av nettsteder: SSG,
• Inkrementell statisk regenerering: ISR.

NextJS, i motsetning til den vanlige React-appen, tilbyr en funksjon som kalles pre-rendering. Dette betyr at forhåndsrendert HTML vises under den første innlastingen. I tradisjonelle React-applikasjoner lastes hele appen inn og gjengis på klientens side. Deretter, etter at JS kode er lastet inn, blir applikasjonen interaktiv.

Statisk generering

I SSG genereres HTML-filen i build-tiden og gjenbrukes for hver forespørsel. Etter at en produksjonsversjon er opprettet, vil hver forespørsel gjenbruke den statisk genererte HTML-filen.

Det finnes også to typer statisk generering: med og uten data.

I det første tilfellet genereres HTML-filen etter at dataene er hentet ved å løse løftet. I dette tilfellet kan vi bruke metoden getStaticProps for å hente data ... men bare hvis du bruker Next.js 9.3 eller nyere. Hvis ikke, bør du tenke på å oppgradere den, fordi den eldre getInitialProps-metoden ikke lenger anbefales og vil bli utdatert. Denne metoden kalles også i hver klientside-navigasjon, så den er ikke effektiv hvis du ikke ønsker å hente data på hver forespørsel.

export async function getStaticProps() {
  const res = await fetch("https://jsonplaceholder.typicode.com/posts");
  const posts = await res.json();
  return {
    props: { posts },
  };
} 

Det virkelig kule er en nylig lansert funksjon kalt ISR (Incremental Static Regeneration), som er en mellomting mellom SSG og SSR. Den lar deg (ved hjelp av en spesifikk nøkkel som heter revalidate) gjøre at siden regenereres trinnvis. Det betyr at du med denne nøkkelen ikke trenger å gjenoppbygge appen hver gang du ønsker å få en oppdatering av dataene som hentes fra serveren. Bare legg til revalidate-nøkkelen med revalideringsperioden i sekunder.

export async function getStaticProps() {
  const res = await fetch("https://jsonplaceholder.typicode.com/posts");
  const posts = await res.json();
  return {
    props: {
      posts,
    },
    revalidate: 30,
  };
}

Det betyr at hvis det kommer forespørsler etter denne perioden, vil den hente dataene fra serveren på nytt.

En annen situasjon er når du bruker en dynamisk side, og stien avhenger av eksterne data. I så fall kan vi bruke metoden getStaticPaths til å fortelle hvilke dynamiske ruter som skal forhåndslastes:

export async const getStaticProps = ({ params }) => {
  const res = await fetch(`https://jsonplaceholder.typicode.com/posts/${params.id}`);
  const post = await res.json();
  return {
    props: { post },
  };
}

export 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,
  };
}

Det finnes en fin måte å sjekke hvilke dynamiske ruter som er opprettet. Du kan kjøre neste build og neste eksport, og etter det vil du ha en statisk versjon av appen din i den nyopprettede out-katalogen.

La oss nå begrense pre-build-stiene:

export async function getStaticPaths() {
  return {
    paths: [{ { params: { id: "1" } } }, { params: { id: "2" } }],
    fallback: false,
  };
}

Etter å ha kjørt den neste eksporten, ser vi at det i begge tilfeller (med og uten et begrenset antall stier) er forskjellig antall innlegg som finnes i my-appoutposts.

La oss nå se nærmere på den viktige og påkrevde fallback-parameteren. Den sier hva som skal gjøres hvis siden ikke var forhåndsrendert ved build-tidspunktet. Hvis den er satt til true, kjøres getStaticProps og genererer den siden. Hvis false, får vi 404 etter å ha prøvd å laste inn den spesifikke banen. En annen ting: Sider med fallback som er aktivert i getStaticPaths, kan ikke eksporteres.

Nedenfor ser du resultatene av å prøve å laste inn den samme dynamiske siden i begge tilfeller:

Første tilfelle (uten begrensede stier)

Andre tilfelle (med begrensede stier og fallback satt til false)

Andre tilfelle (med begrensede stier og fallback satt til true)

Rendering på serversiden

Hovedforskjellen med SSG er at det genereres ny HTML ved hver forespørsel. Det brukes mest når vi henter eksterne data. I dette tilfellet er det ikke nødvendig å bygge appen på nytt hver gang vi ønsker å oppdatere dataene fra serveren.

export async function getServerSideProps() {
  const res = await fetch("https://jsonplaceholder.typicode.com/posts");
  const posts = await res.json();
  return {
    props: {
      posts,
    },
  };
}

Metoden getServerSideProps ligner veldig på getStaticProps. Forskjellen er at getServerSideProps kjøres ved hver forespørsel, mens getStaticProps kjøres én gang i build-tiden.

Gjengivelse på klientsiden

Med gjengivelse på klientsiden er den første innlastingen av siden litt treg. Kommunikasjonen med serveren skjer i kjøretiden. Du kan gjøre det på en mer tradisjonell måte:

const Blog = () => {


 const [posts, setPosts] = useState([]);
  useEffect(() => {
    const fetchData = async () => {
      const res = await fetch(
     "https://jsonplaceholder.typicode.com/posts");
      const posts = await res.json();
      setPosts(innlegg);
    };
    fetchData();
  }, []);

Vi kan også bruke en annen løsning, 'swr' - React Hooks-biblioteket for datahenting av Vercel *, som anbefales på det sterkeste av NextJS-skaperne. SWR står for State While Revalidate.

^* Datakilde: SWR av Vercel

import useSWR fra "swr";


const Blog = () => {
 const fetcher = (url) => fetch(url).then((r) => r.json());
 const { data: innlegg = [], feil } = useSWR(
    "https://jsonplaceholder.typicode.com/posts", fetcher);
 if (feil) return <div>Kunne ikke laste inn innlegg</div>;
 if (!posts.length) return <div>laster...</div>;
 returnere (
    <>
      {posts.map((post) =&gt; (
            {innlegg.tittel}
        ))}
    </>
}

Sammendrag

NextJS gir oss i tillegg muligheten til å velge hvilken av datahentingsstrategiene vi vil bruke på hver side. Vi trenger ikke å følge bare én løsning for hele applikasjonen.

Snarvei

• getServerSideProps - når du trenger å forhåndsrendere appen ved hver forespørsel med hentede data
• getStaticProps - når dataene kan hentes én gang ved bygging og brukes ved hver forespørsel uten oppdatering
• getInitialProps - anbefales ikke, vil bli utfaset
• getStaticPaths - for forhåndsrendering av dynamiske stier

Les mer om dette:

Rails API og CORS. Et snev av bevissthet

Hvorfor bør du (sannsynligvis) bruke Typescript?

Høyeste kvalitetskode i SaaS-prosjektet ditt. Hvorfor bør du som (ikke-teknisk) grunnlegger bry deg om det?