Next.js13で導入されたApp Routerを使用して、MicroCMSからデータを取得する

公開日：2023/11/12

Next.jsのver13が正式に発表され、pages Routerからapp Routerへ変更となりました。
今回はNext.jsのver13についても触れながら、Next.jsを使用してのMicroCMSからデータの取得方法をお伝えします。

app routerとは

Next.js ver13から採用されたルーティング方法です！
今までのpages Routerとは違い、/pages ではなく /app をトップレベルのディレクトリとして扱ったり、Nested Layoutなどを使用できるようになったので、それらを解説していきます。

appディレクトリ

以前まではpagesディレクトリでルーティング設定を行なっていましたが、ver13からはappディレクトリでルーティングの設定を行う事になりました。
pages routerだとpagesフォルダ直下はページコンポーネントとして扱われていましたが、app routerではappフォルダ配下の page.tsx や route.tsxなど特定のファイルのみがルーティングの対象なので、それ以外のファイル名ならルーティングに影響を与えずに配置することができます。
また、フォルダに_をつけることでプライベートフォルダとして認識され、そのフォルダとすべてのサブフォルダがルーティングから除外されます。

画像引用元
https://nextjs.org/docs/app/building-your-application/routing#colocation

layout.tsx

layout.tsx は名前の通りレイアウトに関するファイルです。
pagesルーターでは_app.tsxおよび_document.tsxを使用していましたが、app Router では app ディレクトリ直下に保存された layoutx.tsx ファイルがすべてのpage.tsx に適用され、複数のページ間でレイアウトおよび内部状態を共有することができます。

import type { Metadata } from 'next'
import './globals.css'


export const metadata: Metadata = {
    title: 'Create Next App',
    description: 'Generated by create next app',
}


export default function RootLayout({
    children,
    }: {
      children: React.ReactNode
    }) {
    return (
      <html lang="en">
        <body>{children}</body>
      </html>
    )
}

ネストレイアウト

特定のレイアウトを適用させたい場合は、特定のディレクトリ内にもlayout.tsxを配置する事で、それらのセグメントがアクティブなときにレンダリングされます。

画像引用元
https://nextjs.org/docs/app/building-your-application/routing/pages-and-layouts#nesting-layouts

サーバーコンポーネント

appディレクトリ内はデフォルトでサーバー側でレンダリングされます。
クライアントサイドのレンダリングを行う場合は"use client"をコードの先頭に追加します。

データフェッチ

asyncサーバーコンポーネントと拡張feachAPIにより、コンポーネントレベルのフェッチが可能になりました。

pages Routerでは、getServerSideProps や getStaticProps といった関数を使ってページのレンダリング方法を指定していましたが、app Router ではこれらの関数は廃止されています。
かわりに fetchメソッドの第二引数のオプション等で設定することができます。

第一引数にapi名、第二引数にSSGやSSRの設定を書きます。
もし第二引数がない場合はcache:”force-cache”（SSG）がデフォルト値となります。

// fetch関数
export const getData = async () => {
    const ssgRespons = await fetch(`URL` , {cache:"force-cache"}) // SSG　デフォルト
    const ssrRespons = await fetch(`URL` , {cache:"no-store"}) // SSR
    const isrRespons = await fetch(`URL` , { next: { revalidate: 10 } }) // ISR
}

プリレンダリング、SSG、SSR、ISR

・プリレンダリング

reactがページを表示させる仕組みを、CSR（クライアントサイドレンダリング）といい、ブラウザ側でレンダリングをします。
それに対してNext.jsではプリレンダリングという手法を用いており、サーバーサイド側でHTMLが事前にレンダリングされているものを返します。
そのプリレンダリングの手法にSSG、SSR、ISRがあります。

・SSG（Static Site Generator）

デプロイする前にbuildを行い、事前にHTMLをレンダリングしCDNにキャッシュさせます。
APIからデータを取得している場合は、データを所得した上でレンダリングします。
そのためユーザーがリクエストを投げた時に、レンダリング済のHTMLを返すだけなので、読み込みスピードが早いのが特徴です。
SSGは、変更の少ないページドキュメントや記事詳細などに対して使用します。

・SSR（server side rendering）

SSGだとbuild時でしかレンダリングをしないのに対し、SSRはユーザーがサーバーにリクエストをする時にhtmlをレンダリングして返します。
そのためSSRは、更新頻度が高いSNSのタイムラインやブログのプレビューなどで使用します。

・ISR（Incremental Staic Regeneration）

SSGとSSRの中間のような役割です。
ユーザ側がサーバーにリクエストした際にCDNにキャッシュを生成します。
そして生成したキャッシュを返します。
また、リバリデートというものがあり、更新の秒数を指定する事ができ、指定した秒数を超えた時にキャッシュを更新します。
キャッシュを使用し、時間を指定してSSGされるイメージです。
また、SSG、SSR、ISRはコンポーネントやページ単位で決める事ができます。

例)
page1:SSG
page2SSR
page3:SSG…

MicroCMSからデータを取得する

microcmsio/microcms-js-sdkv2.5.0で、customRequestInitとしてfetchへリクエストオプションを追加できるようになり、Next.jsのApp Routerで利用されるfetchのcacheオプションを付与することが可能になっています。

import { createClient } from "microcms-js-sdk";


export const client = createClient({
   serviceDomain: process.env.SERVICE_DOMAIN,
   apiKey: process.env.API_KEY,
});


export const getData = async () => {
    const response = await client.getList({
    customRequestInit: {       
        cache: "no-store",
    },
    endpoint: "data",
    });
    return response;
};

参考URL
https://blog.microcms.io/microcms-js-sdk-2_5_0/