Strategie di recupero dei dati in NextJS

Pawel Rybczynski

Software Engineer

Recentemente, NextJS sta guadagnando sempre più popolarità come metodo per costruire applicazioni React. Sicuramente un contributo importante è dato dal fatto che NextJS offre diverse strategie di recupero dei dati.

E questi sono:

Rendering lato client: CSR,
Rendering lato server: SSR,
Rendering statico del sito: SSG,
Rigenerazione statica incrementale: PVR.

NextJS, a differenza della semplice applicazione React, offre una funzione chiamata pre-rendering. Ciò significa che l'HTML prerenderizzato viene visualizzato durante il caricamento iniziale. Nelle applicazioni React tradizionali, l'intera applicazione viene caricata e renderizzata sul lato client. Poi, dopo che il JS codice viene caricata, l'applicazione diventa interattiva.

Generazione statica

In SSG, l'HTML viene generato in fase di compilazione e riutilizzato per ogni richiesta. Dopo la creazione di una build di produzione, ogni richiesta riutilizzerà il file HTML generato staticamente.

Esistono anche due tipi di generazione statica: con e senza dati.

Nel primo caso, l'HTML sarà generato dopo aver recuperato i dati risolvendo la promise. In questo caso, possiamo usare il metodo di recupero dei dati getStaticProps... ma solo se si utilizza Next.js 9.3 o più recente. In caso contrario, si deve pensare di aggiornarlo, perché il vecchio metodo getInitialProps non è più consigliato e sarà deprecato. Questo metodo viene inoltre richiamato in ogni navigazione lato client, quindi non è efficiente se non si vuole recuperare i dati a ogni richiesta.

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

La cosa davvero interessante è una funzione appena rilasciata chiamata ISR (Incremental Static Regeneration), che è una via di mezzo tra SSG e SSR. Consente (utilizzando una chiave specifica chiamata revalidate) di rigenerare la pagina in modo incrementale. Ciò significa che con questa chiave non è necessario ricostruire l'applicazione ogni volta che si vuole ottenere un aggiornamento dei dati prelevati dal server. Basta aggiungere la chiave revalidate con il periodo di rivalidazione in secondi.

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

Significa che se le richieste arrivano dopo questo periodo, i dati verranno recuperati di nuovo dal server.

Un'altra situazione è quella in cui si utilizza una pagina dinamica e il percorso dipende da alcuni dati esterni. In questo caso, si può usare il metodo getStaticPaths, che indica quali percorsi dinamici devono essere precaricati:

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

esportare la funzione async getStaticPaths() {
  const res = await fetch("https://jsonplaceholder.typicode.com/posts");
  const posts = await res.json();
  const paths = posts.map(({ id }) => ({ params: { id: `${id}` } }));
  restituire {
    percorsi,
    fallback: false,
  };
}

C'è un bel modo per verificare quali rotte dinamiche sono state create. È possibile eseguire la prossima compilazione e la prossima esportazione, dopodiché si avrà una versione statica dell'applicazione nella nuova cartella out.

Limitiamo ora i percorsi di pre-costruzione:

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

Dopo aver eseguito l'esportazione successiva, possiamo notare in entrambi i casi (con e senza un numero limitato di percorsi) un numero diverso di post trovati in my-appoutposts.

Diamo ora un'occhiata più da vicino al parametro di fallback, cruciale e necessario. Dice cosa fare se la pagina non è stata prerenderizzata al momento della creazione. Se è impostato a true, getStaticProps viene eseguito e genera la pagina. Se è false, si otterrà 404 dopo aver tentato di caricare quel percorso specifico. Un'altra cosa: le pagine con fallback abilitate in getStaticPaths non possono essere esportate.

Di seguito sono riportati i risultati del tentativo di caricare la stessa pagina dinamica in entrambi i casi:

Primo caso (senza percorsi limitati)

Secondo caso (con percorsi limitati e fallback impostato su false)

Secondo caso (con percorsi limitati e fallback impostato su true)

Rendering lato server

La differenza principale con SSG è che viene generato nuovo HTML a ogni richiesta. Si usa soprattutto quando si recuperano dati esterni. In questo caso, non è necessario ricostruire l'applicazione ogni volta che si desidera aggiornare i dati dal server.

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

Il metodo getServerSideProps è molto simile a getStaticProps. La differenza è che getServerSideProps viene eseguito a ogni richiesta, mentre getStaticProps viene eseguito una volta in fase di compilazione.

Rendering lato client

Con il rendering lato client, il caricamento iniziale della pagina è un po' lento. La comunicazione con il server avviene in fase di esecuzione. È possibile farlo in modo più tradizionale:

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(posts);
    };
    fetchData();
  }, []);

Inoltre, possiamo usare un'altra soluzione, 'swr' - libreria React Hooks per il recupero dei dati da Vercel*, fortemente raccomandata dai creatori di NextJS. SWR sta per State While Revalidate.

^* Fonte dei dati: SWR di Vercel

importare useSWR da "swr";


const Blog = () =&gt; {
 const fetcher = (url) =&gt; fetch(url).then((r) =&gt; r.json());
 const { data: posts = [], error } = useSWR(
    "https://jsonplaceholder.typicode.com/posts", fetcher);
 if (errore) return <div>Impossibile caricare i messaggi</div>;
 if (!posts.length) return <div>caricamento...</div>;
 ritorno (
    <>
      {posts.map((post) =&gt; (
            {post.title}
        ))}
    </>
}

Sintesi

NextJS ci offre l'ulteriore possibilità di scegliere quale strategia di recupero dei dati vogliamo utilizzare per ogni pagina. Non è necessario seguire un'unica soluzione per l'intera applicazione.

Scorciatoia

getServerSideProps: quando è necessario pre-renderizzare l'applicazione a ogni richiesta con i dati recuperati.
getStaticProps - quando i dati possono essere recuperati una volta al momento della compilazione e utilizzati per ogni richiesta senza aggiornamenti.
getInitialProps - non consigliato, sarà deprecato
getStaticPaths - per il pre-rendering dei percorsi dinamici