Stratégies de récupération des données dans NextJS

Les voici :

• Rendu côté client : CSR,
• Rendu côté serveur : SSR,
• Rendu de site statique : SSG,
• Régénération statique incrémentale : ISR.

NextJS, contrairement à l'application React, offre une fonctionnalité appelée "pre-rendering". Cela signifie que le HTML pré-rendu est affiché lors du chargement initial. Dans les applications React traditionnelles, l'ensemble de l'application est chargé et rendu du côté du client. Ensuite, une fois que le JS code est chargé, l'application devient interactive.

Génération statique

Dans SSG, le HTML est généré au moment de la construction et réutilisé pour chaque demande. Après la création d'une version de production, chaque requête réutilisera ce fichier HTML généré de manière statique.

Il existe également deux types de génération statique : avec et sans données.

Dans le premier cas, le HTML sera généré après avoir récupéré les données en résolvant la promesse. Dans ce cas, nous pouvons utiliser la méthode de récupération de données getStaticProps... mais seulement si vous utilisez Next.js 9.3 ou plus récent. Si ce n'est pas le cas, pensez à le mettre à jour, car l'ancienne méthode getInitialProps n'est plus recommandée et sera dépréciée. Cette méthode est également appelée dans chaque navigation côté client, elle n'est donc pas efficace si vous ne voulez pas récupérer les données à chaque requête.

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

Ce qui est vraiment intéressant, c'est une nouvelle fonctionnalité appelée ISR (Incremental Static Regeneration), qui se situe entre SSG et SSR. Elle vous permet (en utilisant une clé spécifique appelée revalidate) de régénérer la page de manière incrémentale. Cela signifie qu'avec cette clé, vous n'avez pas besoin de reconstruire l'application à chaque fois que vous souhaitez obtenir une mise à jour des données récupérées sur le serveur. Il suffit d'ajouter la clé revalidate avec la période de revalidation en secondes.

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

Cela signifie que si des demandes arrivent après cette période, il récupérera à nouveau les données du serveur.

Une autre situation se présente lorsque vous utilisez une page dynamique et que le chemin d'accès dépend de données externes. Dans ce cas, nous pouvons utiliser la méthode getStaticPaths pour déterminer les itinéraires dynamiques qui doivent être préchargés :

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

Il existe une bonne façon de vérifier quelles routes dynamiques ont été créées. Vous pouvez lancer le prochain build et le prochain export et après cela vous aurez une version statique de votre application dans le répertoire out nouvellement créé.

Limitons maintenant les chemins de pré-construction :

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

Après avoir exécuté l'exportation suivante, nous pouvons remarquer dans les deux cas (avec et sans un nombre limité de chemins) un nombre différent de messages trouvés dans my-appoutposts.

Examinons maintenant de plus près le paramètre fallback, crucial et obligatoire. Il indique ce qu'il faut faire si la page n'a pas été pré-rendue au moment de la construction. S'il vaut true, le getStaticProps s'exécute et génère cette page. S'il est à false, nous obtiendrons 404 après avoir essayé de charger ce chemin spécifique. Autre chose : les pages avec fallback qui sont activées dans getStaticPaths ne peuvent pas être exportées.

Vous trouverez ci-dessous les résultats de la tentative de chargement de la même page dynamique dans les deux cas :

Premier cas (sans chemins limités)

Deuxième cas (avec des chemins d'accès limités et la valeur "fallback" fixée à "false")

Deuxième cas (avec des chemins d'accès limités et la valeur "fallback" fixée à "true")

Rendu côté serveur

La principale différence avec SSG : un nouveau code HTML est généré à chaque requête. Cette méthode est surtout utilisée lorsque nous récupérons des données externes. Dans ce cas, il n'est pas nécessaire de reconstruire l'application à chaque fois que nous voulons mettre à jour les données du serveur.

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

La méthode getServerSideProps ressemble beaucoup à la méthode getStaticProps. La différence est que getServerSideProps s'exécute à chaque requête, alors que getStaticProps s'exécute une fois au moment de la construction.

Rendu côté client

Avec le rendu côté client, le chargement initial de la page est un peu lent. La communication avec le serveur se fait pendant l'exécution. Vous pouvez le faire de manière plus traditionnelle :

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

Nous pouvons également utiliser une autre solution, 'swr' - React Hooks library for data fetch by Vercel*, qui est fortement recommandée par les créateurs de NextJS. Le SWR est l'abréviation de State While Revalidate.

^* Source des données : TOS par Vercel

import useSWR de "swr" ;


const Blog = () => {
 const fetcher = (url) => fetch(url).then((r) => r.json()) ;
 const { data : posts = [], error } = useSWR(
    "https://jsonplaceholder.typicode.com/posts", fetcher) ;
 if (error) return <div>Échec du chargement des messages</div>;
 if (!posts.length) return <div>chargement...</div>;
 retour (
    <>
      {posts.map((post) =&gt; (
            {post.title}
        ))}
    </>
}

Résumé

NextJS nous donne la possibilité supplémentaire de choisir la stratégie de récupération des données que nous voulons utiliser sur chaque page. Nous n'avons pas besoin de suivre une seule solution pour l'ensemble de l'application.

Raccourci

• getServerSideProps - lorsque vous avez besoin d'un pré-rendu de l'application à chaque requête avec des données récupérées.
• getStaticProps - lorsque les données peuvent être récupérées une fois au moment de la construction et utilisées à chaque demande sans mise à jour.
• getInitialProps - non recommandé, sera déprécié
• getStaticPaths - pour le pré-rendu des chemins dynamiques

En savoir plus :

API Rails et CORS. Un soupçon de conscience

Pourquoi devriez-vous (probablement) utiliser Typescript ?

Un code de la plus haute qualité dans votre projet SaaS. Pourquoi devriez-vous vous en préoccuper en tant que fondateur (non technique) ?