Tiedonhakustrategiat NextJS:ssä

Ja nämä ovat:

• Asiakaspuolen renderöinti: CSR,
• Palvelinpuolen renderöinti: SSR,
• Staattisen sivuston renderöinti: SSG,
• Inkrementaalinen staattinen regenerointi: ISR.

Toisin kuin tavallinen React-sovellus, NextJS tarjoaa ominaisuuden nimeltä esirenderöinti. Tämä tarkoittaa, että esirenderöity HTML näytetään alkulatauksen aikana. Perinteisissä React-sovelluksissa koko sovellus ladataan ja renderöidään asiakkaan puolella. Sitten, kun JS koodi ladataan, sovellus muuttuu interaktiiviseksi.

Staattinen sukupolvi

SSG:ssä HTML luodaan rakennusaikana ja sitä käytetään uudelleen jokaista pyyntöä varten. Kun tuotantokehitys on luotu, jokainen pyyntö käyttää uudelleen tätä staattisesti luotua HTML-tiedostoa.

On myös olemassa kahdenlaista staattista sukupolvea: tietojen kanssa ja ilman tietoja.

Ensimmäisessä tapauksessa HTML-tiedosto luodaan sen jälkeen, kun tiedot on haettu lupauksen ratkaisemisen avulla. Tässä tapauksessa voimme käyttää getStaticProps-tiedonhakumenetelmää... mutta vain jos käytät Next.js 9.3:a tai uudempaa. Jos et, harkitse päivittämistä, koska vanhempaa getInitialProps-metodia ei enää suositella ja se on vanhentunut. Tätä metodia kutsutaan myös jokaisessa asiakaspuolen navigoinnissa, joten se ei ole tehokas, jos et halua noutaa tietoja jokaisella pyynnöllä.

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

Todella hieno juttu on äskettäin julkaistu ominaisuus nimeltä ISR (Incremental Static Regeneration), joka on jotain SSG:n ja SSR:n väliltä. Sen avulla voit (käyttämällä tiettyä avainta nimeltä revalidate) tehdä sivun inkrementaalisesti regeneroitavaksi. Se tarkoittaa, että tämän avaimen avulla sinun ei tarvitse rakentaa sovellusta uudelleen joka kerta, kun haluat päivittää palvelimelta haetut tiedot. Lisää vain revalidate-avain, jossa on sekunneissa ilmaistu voimassaoloaika.

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

Se tarkoittaa, että jos pyyntöjä tulee tämän ajanjakson jälkeen, se hakee tiedot palvelimelta uudelleen.

Toinen tilanne on, kun käytät dynaamista sivua ja polku riippuu jostain ulkoisesta tiedosta. Tällöin voimme käyttää getStaticPaths-metodia, joka kertoo, mitkä dynaamiset reitit on ladattava valmiiksi:

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

On olemassa mukava tapa tarkistaa, mitkä dynaamiset reitit on luotu. Voit suorittaa seuraavan buildin ja seuraavan exportin, ja sen jälkeen sinulla on sovelluksesi staattinen versio juuri luotuun out-hakemistoon.

Rajoitetaan nyt esivalmistuspolkuja:

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

Kun seuraava vienti on suoritettu, voimme huomata, että molemmissa tapauksissa (rajoitetun polkumäärän kanssa ja ilman sitä) my-appoutposts-palvelusta löytyi eri määrä viestejä.

Tarkastellaan nyt tarkemmin ratkaisevaa ja vaadittua varaparametria. Se kertoo, mitä tehdään, jos sivua ei ole esirenderöity rakennusaikana. Jos sen arvoksi asetetaan true, getStaticProps suoritetaan ja luodaan kyseinen sivu. Jos se on false, saamme tuloksen 404, kun yritämme ladata kyseistä polkua. Toinen asia: sivuja, joissa on fallback ja jotka on otettu käyttöön getStaticPathsissa, ei voi viedä.

Alla on tulokset, jotka saat, kun yrität ladata samaa dynaamista sivua molemmissa tapauksissa:

Ensimmäinen tapaus (ilman rajoitettuja polkuja)

Toinen tapaus (rajoitetut polut ja fallback-asetus false).

Toinen tapaus (rajoitetut polut ja fallback-asetus true).

Palvelinpuolen renderöinti

Tärkein ero SSG:hen verrattuna on se, että uusi HTML luodaan jokaisen pyynnön yhteydessä. Sitä käytetään lähinnä silloin, kun haetaan ulkoista dataa. Tällöin sovellusta ei tarvitse rakentaa uudelleen joka kerta, kun haluamme päivittää tietoja palvelimelta.

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

GetServerSideProps-menetelmä näyttää hyvin samanlaiselta kuin getStaticProps. Erona on, että getServerSideProps suoritetaan jokaisen pyynnön yhteydessä, kun taas getStaticProps suoritetaan kerran rakennusaikana.

Asiakaspuolen renderöinti

Asiakaspuolen renderöinnissä sivun alkulataus on hieman hidas. Kommunikointi palvelimen kanssa tapahtuu ajon aikana. Voit tehdä sen perinteisemmällä tavalla:

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

Voimme myös käyttää toista ratkaisua, 'swr' - React Hooks -kirjastoa Vercel*:n tietojen hakemiseen, jota NextJS:n luovat suosittelevat voimakkaasti. SWR tarkoittaa State While Revalidate.

^* Tietolähde: Vercelin SWR

import useSWR from "swr";


const Blog = () => {
 const fetcher = (url) => fetch(url).then((r) => r.json());
 const { data: posts = [], error } = useSWR(
    "https://jsonplaceholder.typicode.com/posts", fetcher);
 if (virhe) return <div>Viestien lataaminen epäonnistui</div>;
 if (!posts.length) return <div>lastaus...</div>;
 return (
    <>
      {posts.map((post) =&gt; (
            {post.title}
        ))}
    </>
}

Yhteenveto

NextJS antaa meille lisämahdollisuuden valita, mitä tiedonhakustrategioita haluamme käyttää kullakin sivulla. Meidän ei tarvitse noudattaa vain yhtä ratkaisua koko sovelluksessa.

Shortcut

• getServerSideProps - kun sinun täytyy esirenderöidä sovellus jokaisen pyynnön yhteydessä noudettujen tietojen kanssa.
• getStaticProps - kun tiedot voidaan noutaa kerran rakennusaikana ja käyttää jokaisessa pyynnössä ilman päivitystä.
• getInitialProps - ei suositella, poistetaan käytöstä.
• getStaticPaths - dynaamisten polkujen esirenderöintiä varten

Lue lisää:

Rails API ja CORS. Ripaus tietoisuutta

Miksi sinun pitäisi (luultavasti) käyttää Typescriptiä?

Laadukkain koodi SaaS-projektissasi. Miksi sinun (ei-teknisen) perustajan pitäisi välittää siitä?