Strategien zum Abrufen von Daten in NextJS

Pawel Rybczynski

Software Engineer

In letzter Zeit erfreut sich NextJS immer größerer Beliebtheit als Methode zur Erstellung von React-Anwendungen. Ein wichtiger Grund dafür ist sicherlich die Tatsache, dass NextJS verschiedene Strategien zum Abrufen von Daten bietet.

Und das sind:

Client-seitiges Rendering: CSR,
Server-seitiges Rendering: SSR,
Rendering statischer Websites: SSG,
Inkrementelle statische Regeneration: ISR.

NextJS bietet, anders als die einfache React-App, eine Funktion namens Pre-Rendering. Das bedeutet, dass vorgerendertes HTML beim ersten Laden angezeigt wird. Bei herkömmlichen React-Anwendungen wird die gesamte Anwendung auf der Client-Seite geladen und gerendert. Dann, nachdem die JS Code geladen wird, wird die Anwendung interaktiv.

Statische Erzeugung

In SSG wird das HTML während der Build-Zeit generiert und für jede Anfrage wiederverwendet. Nachdem ein Produktions-Build erstellt wurde, wird jede Anfrage diese statisch generierte HTML-Datei wiederverwenden.

Es gibt auch zwei Arten der statischen Generierung: mit und ohne Daten.

Im ersten Fall wird das HTML generiert, nachdem die Daten durch Auflösen des Versprechens abgerufen wurden. In diesem Fall können wir die Datenabrufmethode getStaticProps verwenden... aber nur, wenn Sie Next.js 9.3 oder neuer verwenden. Wenn nicht, sollten Sie über ein Upgrade nachdenken, denn die ältere getInitialProps-Methode wird nicht mehr empfohlen und ist veraltet. Diese Methode wird auch bei jeder clientseitigen Navigation aufgerufen, so dass sie nicht effizient ist, wenn Sie nicht bei jeder Anfrage Daten abrufen wollen.

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

Die wirklich coole Sache ist eine neu veröffentlichte Funktion namens ISR (Incremental Static Regeneration), die etwas zwischen SSG und SSR ist. Sie ermöglicht es Ihnen (durch Verwendung eines bestimmten Schlüssels namens revalidate), die Seite inkrementell zu erneuern. Das bedeutet, dass Sie mit diesem Schlüssel die Anwendung nicht jedes Mal neu erstellen müssen, wenn Sie eine Aktualisierung der vom Server abgerufenen Daten erhalten möchten. Fügen Sie einfach den Schlüssel revalidate mit der Überprüfungsdauer in Sekunden hinzu.

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

Das heißt, wenn nach diesem Zeitraum Anfragen kommen, werden die Daten erneut vom Server geholt.

Eine andere Situation ist, wenn Sie eine dynamische Seite verwenden und der Pfad von einigen externen Daten abhängt. In diesem Fall können wir die Methode getStaticPaths verwenden, die angibt, welche dynamischen Routen vorgeladen werden sollen:

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 {
    Pfade,
    fallback: false,
  };
}

Es gibt eine gute Möglichkeit zu überprüfen, welche dynamischen Routen erstellt wurden. Sie können den nächsten Build und den nächsten Export ausführen und danach haben Sie eine statische Version Ihrer App im neu erstellten out-Verzeichnis.

Schränken wir nun die Pfade für die Vorerstellung ein:

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

Nach der Ausführung des nächsten Exports können wir in beiden Fällen (mit und ohne eine begrenzte Anzahl von Pfaden) eine unterschiedliche Anzahl von Beiträgen in my-appoutposts feststellen.

Schauen wir uns nun den entscheidenden und erforderlichen Fallback-Parameter genauer an. Er gibt an, was zu tun ist, wenn die Seite zum Zeitpunkt der Erstellung nicht vorgerendert wurde. Wenn er auf true gesetzt ist, wird getStaticProps ausgeführt und die Seite generiert. Wenn er auf false gesetzt ist, erhalten wir 404, nachdem wir versucht haben, diesen speziellen Pfad zu laden. Eine weitere Sache: Seiten mit Fallback, die in getStaticPaths aktiviert sind, können nicht exportiert werden.

Nachfolgend finden Sie die Ergebnisse des Versuchs, die gleiche dynamische Seite in beiden Fällen zu laden:

Erster Fall (ohne begrenzte Pfade)

Zweiter Fall (mit begrenzten Pfaden und Fallback auf false gesetzt)

Zweiter Fall (mit eingeschränkten Pfaden und Fallback auf true gesetzt)

Server-seitiges Rendering

Der Hauptunterschied zu SSG: Bei jeder Anfrage wird neues HTML generiert. Es wird meist verwendet, wenn wir externe Daten abrufen. In diesem Fall muss die Anwendung nicht jedes Mal neu aufgebaut werden, wenn wir die Daten vom Server aktualisieren wollen.

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

Die getServerSideProps-Methode sieht der getStaticProps-Methode sehr ähnlich. Der Unterschied besteht darin, dass getServerSideProps bei jeder Anforderung ausgeführt wird, während getStaticProps einmal zur Erstellungszeit ausgeführt wird.

Client-seitiges Rendering

Beim clientseitigen Rendering ist das anfängliche Laden der Seite etwas langsam. Die Kommunikation mit dem Server erfolgt während der Laufzeit. Sie können dies auf herkömmliche Weise tun:

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

Wir können auch eine andere Lösung verwenden, 'swr' - React Hooks-Bibliothek für Datenabrufe von Vercel*, die von den NextJS-Entwicklern dringend empfohlen wird. Die Abkürzung SWR steht für State While Revalidate.

^* Datenquelle: SWR von Vercel

import useSWR von "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 (Fehler) return <div>Beiträge konnten nicht geladen werden</div>;
 if (!posts.length) return <div>Laden...</div>;
 zurück (
    <>
      {posts.map((post) =&gt; (
            {post.title}
        ))}
    </>
}

Zusammenfassung

NextJS gibt uns die zusätzliche Möglichkeit zu wählen, welche der Datenbeschaffungsstrategien wir auf jeder Seite verwenden wollen. Wir müssen nicht nur eine Lösung für die gesamte Anwendung verwenden.

Abkürzung

getServerSideProps - wenn Sie die Anwendung bei jeder Anfrage mit abgerufenen Daten vorbereiten müssen
getStaticProps - wenn die Daten einmal zum Zeitpunkt der Erstellung abgerufen und bei jeder Anfrage ohne Aktualisierung verwendet werden können
getInitialProps - nicht empfohlen, wird veraltet sein
getStaticPaths - für die Vorberechnung von dynamischen Pfaden