<h2 id="he16b7b12c8">⚡️無限スクロールはCSR</h2><p>ユーザーのアクション（今回はスクロール）でデータ取得を行い、ページを表示させるCSR。</p><p><code>useState</code> と <code>useEffect</code> を使って無限スクロールを実装したけど、記事一覧ページから個別記事に移動して、また一覧ページに戻ると、<strong>すでに取得済みの11件目以降の記事が再度取得されてしまう</strong>。</p><p>これはNext.jsの仕様で、ページを離れるとコンポーネントの状態（<code>useState</code>など）はリセットされるため、戻ってきた時には再初期化されてしまうことが原因。</p><p>一度無限スクロールで取得したデータを取り直さないようにするには、<strong><span class="text-large">クライアントサイドで状態を保持する仕組み</span></strong>を導入する。</p><h2 id="hcd1318e753">✅ 解決方法：<code>zustand</code>や<code>Recoil</code>、<code>Redux</code>などの状態管理ライブラリを使う</h2><p>状態管理ライブラリを使用することで、ブログ一覧ページを離れて詳細ページに行っても、戻ってきたら<strong><span class="highlight">読み込んだブログ一覧は維持されたままにできる。</span></strong></p><h2 id="h3ec8ddcdcc">🧠 <code>zustand</code>の導入 &amp; 実装ステップ</h2><h3 id="hd7ea8c0b9d">1. <code>zustand</code> をインストール</h3><pre><code>npm install zustand</code></pre><h3 id="ha18b429992">2. ストアを作成（例：<code>src/store/useBlogStore.js</code>）</h3><p>⚠️Zustandの初期状態を設定する際の注意点：<br>ビルドした時、getStaticPropsですでに10件分の記事は取得されている状態。<br>Zustandの初期状態を設定する際、初期データをそのまま追加してしまうとZustandの初期状態を設定するuseEffectが走った際に、元あるデータ＋初期データが追加されてデータが重複してしまう。</p><p>そのため、取得するデータの状態を「初期時」と「追加時」と「初期化」の3つの状態を用意する。</p><p>❌状態を分けないと…<br>ビルド時にデータを10件取得<br>↓<br>useEffectでZustandの初期状態を設定（ビルド時に取得したデータをそのまま入れる）<br>↓<br>20件の重複データが表示される</p><pre><code class="language-javascript">import { create } from &quot;zustand&quot;;

const useBlogStore = create((set) =&gt; ({
  blogs: [],
  offset: 0,
  isEnd: false,
  initialized: false, 

  // 初回取得時に実行する（SSGデータセット）
  initBlogs: (initialBlogs) =&gt;
    set({
      blogs: initialBlogs,
      offset: initialBlogs.length,
      isEnd: initialBlogs.length === 0,
      initialized: true, // ← 初期化フラグを立てる
    }),

  // 無限スクロール時に実行する（新しい記事を追加）
  addBlogs: (newBlogs) =&gt;
    set((state) =&gt; ({
      blogs: [...state.blogs, ...newBlogs],
      offset: state.offset + newBlogs.length,
      isEnd: newBlogs.length === 0,
    })),
}));

export default useBlogStore;</code></pre><h3 id="h8c7ef6f8be">3.一覧ページ<code>blogs/index.jsx</code>で<code>useBlogStore.js</code>を使う</h3><pre><code class="language-javascript">import useBlogStore from &quot;src/store/useBlogStore&quot;;

export default function Blog({ data, category }) {
const { blogs, offset, isEnd, initBlogs, addBlogs, initialized } = useBlogStore();
const [loading, setLoading] = useState(false);
const observerRef = useRef();</code></pre><h3 id="h6d0c35c5d5">4. ストアに初期データをセット(初回のみ)</h3><pre><code class="language-javascript">useEffect(() =&gt; {
    if (!initialized &amp;&amp; blogs.length === 0 &amp;&amp; data.length &gt; 0) {
      initBlogs(data);//← このdataはビルド時にgetStaticPropsで取得したデータ
    }
  }, [data, blogs.length, initBlogs]);</code></pre><h3 id="h04211d5294">5. 無限スクロールで新しく取得したデータをセット</h3><p>スクロールに合わせてデータを取得するfetchMore関数。ここで新しく取得したデータをnewBlogsに入れて、状態管理化にあるaddBlogs(newBlogs)に渡す。<br>useBlogStore.jsにあるaddBlogsがこのデータを受け取り、mergeして状態を更新する。</p><pre><code class="language-javascript">const fetchMore = useCallback(async () =&gt; {
    if (loading || isEnd) return;
    setLoading(true);

    try {
      const res = await fetch(`/api/blogs?offset=${offset}&amp;limit=10`);
      const newBlogs = await res.json();
      addBlogs(newBlogs);//← スクロールして取得したデータ
    } catch (error) {
      console.error(&quot;ブログの追加取得に失敗:&quot;, error);
    } finally {
      setLoading(false);
    }
  }, [offset, loading, isEnd, addBlogs]);

//... IntersectionObserverで無限スクロールの処理が続く</code></pre><h2 id="h3d98d76ffb">✅一覧ページから記事ページへ行き、戻るボタンで一覧に戻った際にデータを再取得しなくなった</h2><p>Zustandで状態を管理することで、一度取得したデータを保持しているため、無限スクロールの処理が走らなくなった。</p><p></p><h2 id="hda0fe6edde">⭐️次の課題は戻るボタンで一覧に戻った際に、元いた位置に戻ること</h2><p>無限スクロールで11件目以降の記事一覧を取得したけれども、記事を読んで戻るとスクロール位置はトップに戻ってしまう。<br>何かデータを探している時や、次は12件目の記事を読もうと思っていた時にTOPまで戻されてしまうのはとてもストレスを感じる。</p><p><a href="/blogs/howtoback-previous-scrollspot" target="_blank" rel="noopener noreferrer nofollow">Next.js｜ブラウザバックで元のスクロール位置に戻る方法</a></p><h2 id="h805544825f">❓ビルド時とスクロールで取得する時の処理を分ける必要があるのか？</h2><p>SSGで記事一覧ページ(10件分)を作成し、クライアント側のスクロールによってクライアント側でデータ取得と分けているから複雑に感じた。</p><p>はじめからクライアントサイドで、一覧ページにアクセスした際にapiルートでデータを取得して10件表示させる。<br>そこからスクロール値に合わせて、CSR無限スクロールにしたらシンプルな構成になるのではと思った。</p><h3 id="h4d6af5edd7">それぞれの構成とメリットデメリット</h3><p>chatGPTに聞いたところ下記返答が返ってくる。</p><table><tbody><tr><th colspan="1" rowspan="1"><p>構成</p></th><th colspan="1" rowspan="1"><p>メリット</p></th><th colspan="1" rowspan="1"><p>デメリット</p></th></tr><tr><td colspan="1" rowspan="1"><p>SSG + CSR無限スクロール</p></td><td colspan="1" rowspan="1"><p>初速が速く、SEOにも強い</p></td><td colspan="1" rowspan="1"><p>記事整合性が崩れる可能性あり（revalidate依存）</p></td></tr><tr><td colspan="1" rowspan="1"><p>SSR + CSR無限スクロール</p></td><td colspan="1" rowspan="1"><p>データ整合性がある程度保証される</p></td><td colspan="1" rowspan="1"><p>表示速度やキャッシュ性は落ちる</p></td></tr><tr><td colspan="1" rowspan="1"><p>CSR完全切替</p></td><td colspan="1" rowspan="1"><p>自由で柔軟</p></td><td colspan="1" rowspan="1"><p>SEOが効きづらい、初速が遅い</p></td></tr></tbody></table><p>CSR完全切替だとデータ取得時に時間がかかりストレスがかかるのかもしれない…。<br>データの量や画像があるなしでどう変化があり、メリットデメリットがどこまで響くのかが実際に使ってみないと分からないと感じた。</p>

ブログ一覧に無限スクロールを設置したけれどページを離れるたびに、一度取得済みのデータを取り直さないでほしい！

Next.js×microCMS｜zustandを使用して無限スクロールで取得済みデータの再取得をしないようにする

<h2 id="h58fdde1ddc">🌀無限スクロール便利だと思ったら、見落としていた不便さが</h2><p>無限スクロールで記事をたくさん一覧表示できるので、スムーズに知りたい情報に辿り着けそうと設置直後はワクワクしました。</p><p>しかし実際使ってみたところ、すごく不便な部分が発覚。</p><p>一覧ページから子ページ（記事詳細ページ）に飛んで、内容を確認してやっぱり違う記事を読もうと思いブラウザバックすると、記事一覧のトップページに出戻ってしまった…⚡️</p><p>これではスクロールで記事をたくさん探せても、読むたびに振り出しに戻る「無限スクロール地獄」になってしまう。</p><h2 id="h32bfc70864">✅スクロールY位置をセッション保存して解決</h2><p>目的は 「現在のページから子ページへ遷移 → 戻ってきたときのみスクロール位置を復元」 を実現すること。<br>まずはカスタムフックを作成していく(hooks/useScrollRestoration.jsx)。</p><h3 id="hdf44798eca">① <code>useRouter</code> で現在のページのルート情報を取得</h3><pre><code class="language-javascript">const router = useRouter();</code></pre><p>これにより、現在のパス（pathname）などの情報にアクセスでき、ルーティングイベントにも対応可能に。</p><h3 id="hdff25eeb0f">② 親ページでマウント時にスクロール位置を保存する処理を設置</h3><pre><code class="language-javascript">useEffect(() =&gt; {
  const handleRouteChangeStart = () =&gt; {
    const currentY = window.scrollY;
    sessionStorage.setItem(key, currentY);
  };

  router.events.on(&quot;routeChangeStart&quot;, handleRouteChangeStart);
  return () =&gt; {
    router.events.off(&quot;routeChangeStart&quot;, handleRouteChangeStart);
  };
}, [router, key]);</code></pre><ul><li>router.events.<span class="highlight">on</span><code>routeChangeStart</code> イベントでページ遷移直前に実行されるように設定。</li><li>router.events.<span class="highlight">off</span><code>routeChangeStart</code> イベントのクリーンアップ。</li><li><code>window.scrollY</code> で現在の縦スクロール位置を取得し、<code>sessionStorage</code> に保存。</li></ul><h3 id="h3100973a14">③ ページがマウントされたときにスクロール位置を復元</h3><pre><code class="language-javascript">useEffect(() =&gt; {
  if (!isReady) return;
  const savedY = sessionStorage.getItem(key);
  if (savedY !== null) {
    const y = parseInt(savedY, 10);
    if (!isNaN(y)) {
      window.scrollTo(0, y);
      sessionStorage.removeItem(key); // ✅ 一度復元したら消す
    }
  }
}, [key, isReady]);</code></pre><ul><li><code>sessionStorage</code> に保存されているスクロール位置を取得し、<code>window.scrollTo</code> で復元。</li><li>一度復元したら、値を即座に削除することで <strong>リロードや他のページ遷移で再度適用されるのを防ぐ</strong>。</li></ul><h3 id="ha5dc5f56d5">🎉 <strong>結果</strong></h3><ul><li><strong>「親ページ → 子ページ → 戻る」</strong>というルートでのみスクロール位置が復元される。</li><li><strong>「他ページに行く、リロードする、URL直打ちする」</strong> などでは復元されず、初期状態に。</li></ul><p>これで安心して記事を読んだら一覧ページに戻ってくることが可能に🙌</p><h2 id="hd337dd8605">⚡️元のスクロール値に戻った時に、「Loading」UIが一瞬見える…？</h2><p>一難去ってまた一難…予期せぬことばかり。</p><p>子ページから元のページに戻った時、一瞬「Roading」と表示されてその後に記事一覧が表示される。これはスクロール値に合わせてデータ取得させている「無限スクロール」の処理が再度走っているということ。</p><p>一瞬なのであまり気にならないかもしれないけれど、一度取得したデータをもう一度取得するのは手間に感じます。</p><p>対応する方法は次の記事に。</p><p><a href="/blogs/stop-rendering" target="_blank" rel="noopener noreferrer nofollow">zustandを使用して無限スクロールで取得済みデータの再取得をしないようにする</a></p>

記事一覧を無限スクロールにしたけれど、記事から一覧に戻ったらスクロールがTOPに戻るのを解決

Next.js×microCMS｜ブラウザバックや戻るボタンで元のスクロール位置に戻る方法

<h2 id="he89b711621">🔁 状況整理（/blogs 一覧ページ）</h2><p>Next.js×microCMSでブログ一覧ページを作成中。<br>アクセス時はSSGで、スクロールでデータを取得する時はCSRと分けている。</p><h3 id="hffddeb7e52"><span class="highlight"> 1. /blogs にアクセス</span></h3><p>ブログページにアクセスしたら、最初に表示される記事10件はSSG化されており、静的HTMLが返ってくる。</p><ul><li><code>getStaticProps</code> が実行され、リミット指定をした10件分のブログ記事が事前にビルドされる。（SSG）</li><li><code>revalidate: 30</code> により、30秒経過すると次のアクセス時にバックグラウンドで最新化される。（ISR）</li></ul><h3 id="h90c5266d30"><span class="highlight"> 2. スクロールで記事の追加読み込み(無限スクロール)</span></h3><p>初期記事10件以降の記事は、ユーザーのスクロールで新たに取得する。</p><ul><li><code>useEffect</code> や <code>IntersectionObserver</code> により、ユーザーのスクロールアクションで <code>/api/blogs?offset=10</code> にリクエストが飛ぶ。</li></ul><h2 id="h926d7ce789">⚡️疑問に思ったこと</h2><p><strong>❓疑問１｜/blogsページはSSG化されているのになぜユーザーアクションで表示できる？</strong><br>ユーザーアクションのスクロールでさらに10記事取得してるけれど、/blogsページはSSG化されているので、30秒経過しないと一覧は更新されないのでは？</p><p><strong>💡無限スクロールでの追加取得はクライアントで描画されているので表示できる</strong><br>無限スクロールで追加取得は、クライアント側でAPIを経由してリアルタイムに取得している（CSR）。そのため、ページのSSG化関係なく記事は取得され、表示される。</p><hr><p><strong>❓疑問２｜ユーザー側でデータ取得（一覧更新）ができるならISRは必要ないのでは？</strong><br>ユーザー側でAPI経由で記事一覧を更新できるなら、SSG化した/blogsページを<code>revalidate</code>で30秒ごとに最新化（ISR）は必要ないのではないだろうか。二重で更新しているように感じる。</p><p><strong>💡ISRは/blogsページ初回表示の鮮度を保つために必要！</strong><br><code>revalidate</code> は /blogsページ<strong><span class="highlight">初回表示のために必要。</span></strong><br>無限スクロールで2ページ目以降の記事を取得しても、初回の10件はSSG化された静的HTMLなので、次にアクセスしてもキャッシュからページを返す。記事が増えたとしても/blogsのアクセス時のページは古いまま。</p><p><code>revalidate</code> をつけておけば、静的にビルドされた初期データも定期的に更新される。<br></p><p><strong>補足：ISRの更新タイミング</strong><br>ISR は次のアクセス時にバックグラウンドで再生成される。指定秒経ったら即座に新しくされるわけではない。</p><ul><li>アクセスがない場合は再生成されない。</li><li>指定秒経過後の最初のアクセス時：再生成が始まる（古いまま表示される可能性あり）</li><li>次のアクセス時：再生成されたページが表示される</li></ul><hr><p><strong>❓疑問３｜</strong><code>revalidate</code><strong>をつけていても、revalidate設定時間より短い間に、1回目アクセスと2回目アクセスの間に記事が増えたら？</strong></p><p><strong>💡APIの結果の整合性（順番ズレ問題）は更新頻度次第</strong></p><p><span class="highlight">【ブログ更新頻度：低〜中（月数回〜週数回）】</span><br>通常ユーザーは一覧ページを見たら、他の記事に飛んで、読んだ後に戻ってきたりする。その間にタイミングよく新記事が投稿されて、「初期で取得した10件の記事」と「スクロールで取得した記事」との間で日付のずれが生じて困るといったことはあまり起こることではない。<br>revalidate: 30 ~ 300秒でも設定可。</p><p><span class="highlight">【 ブログ更新頻度：高い（1日複数回、あるいは自動投稿等）】</span><br>新着記事が頻繁に追加されるようなサイトでは、初期表示の10件（SSG）とその後にCSRで取得するデータの順序がずれてしまい、ユーザーに違和感を与える可能性がある。</p><p>📝このようなケースでは、次のような対策が有効：</p><p>- 初期10件もCSRで取得し、常に最新に保つ<br>- <code>revalidate</code> の時間を短くして、できるだけ新鮮な静的ページにする<br>- サーバーサイドで順番を制御した中間APIなどを用意する（上級者向け）</p><p><strong>最適な設計は、「更新頻度」「インフラコスト」「ユーザー体験」のバランスによって決めるのがベスト。</strong></p><h2 id="ha214098e44">まとめ</h2><p><strong>SSGは初回アクセスの高速化、CSRは実際の使い心地と分けて考える</strong></p><p>SSGは初回アクセスの高速化をしてパフォーマンスを上げてくれる。<br>そしてCSRは、実装したかった「無限スクロール」というユーザー（私）の使い心地を良くしてくれる。</p><table><tbody><tr><th colspan="1" rowspan="1"><p>処理</p></th><th colspan="1" rowspan="1"><p>手段</p></th><th colspan="1" rowspan="1"><p>データの鮮度</p></th></tr><tr><td colspan="1" rowspan="1"><p>初回10件表示</p></td><td colspan="1" rowspan="1"><p><code>getStaticProps</code> + <code>revalidate</code></p></td><td colspan="1" rowspan="1"><p>指定秒ごとにバックグラウンドで最新化（ISR）</p></td></tr><tr><td colspan="1" rowspan="1"><p>追加読み込み</p></td><td colspan="1" rowspan="1"><p>API + CSR<code>useEffect</code></p></td><td colspan="1" rowspan="1"><p>毎回リアルタイム取得</p></td></tr></tbody></table><p>しかし、SSGは初回表示を高速化をするために静的HTMLを返す。ビルド後にデータ更新されてもデータは古いままキャッシュから返される。<br>それを改善してくれるのがISRの設定。</p><p>そしてCSRは私たちの好みの使い方やデータ取得のタイミングを選べるけれど、API取得にはタイムラグが生じるときがある。</p><p>上記二つのメリット/デメリットを、ページの目的によって使い分けていく必要がある。</p><p>【 実際の使い方の例 】</p><p>🚀 <strong>getStaticProps</strong> は「とりあえず表示を爆速にしたい」<br>→ Topページ、記事一覧の最初の10件などに最適</p><p>🌀 <strong>CSR（useEffect や fetch）</strong> は「ユーザー操作に合わせて変化したい」<br>→ 無限スクロール、検索、絞り込み、ボタンクリックでの表示切替などに◎</p><table><tbody><tr><th colspan="1" rowspan="1"><p>項目</p></th><th colspan="1" rowspan="1"><p>getStaticProps（SSG/ISR）</p></th><th colspan="1" rowspan="1"><p>CSR（クライアントサイドレンダリング）</p></th></tr><tr><td colspan="1" rowspan="1"><p>目的</p></td><td colspan="1" rowspan="1"><p>ページの事前生成で高速表示</p></td><td colspan="1" rowspan="1"><p>ユーザー操作に応じた動的な処理・描画</p></td></tr><tr><td colspan="1" rowspan="1"><p>主な役割</p></td><td colspan="1" rowspan="1"><p>初回のHTMLを生成（SEO・速度◎）</p></td><td colspan="1" rowspan="1"><p>無限スクロール・動的フィルター・検索など</p></td></tr><tr><td colspan="1" rowspan="1"><p>タイミング</p></td><td colspan="1" rowspan="1"><p>ビルド時 or <code>revalidate</code>で再生成</p></td><td colspan="1" rowspan="1"><p>ページ表示後のブラウザ内で実行</p></td></tr><tr><td colspan="1" rowspan="1"><p>データの鮮度</p></td><td colspan="1" rowspan="1"><p>再生成タイミング次第</p></td><td colspan="1" rowspan="1"><p>基本リアルタイム（API呼び出し時）</p></td></tr></tbody></table><p>その他Next.jsのレンダリング方法は下記記事を参照。</p><p><a href="/blogs/nextjs-rendering" target="_blank" rel="noopener noreferrer nofollow">Next.js のレンダリング方式まとめ｜SSG・ISR・SSR・CSR の違いと使い分け</a></p>

一覧ページをSSG化後、ISR化やCSRでのデータ取得のメリット/デメリットがよく分からなくなったので、疑問に感じたことと併せてまとめてみた。

Next.js×microCMS｜ブログ記事一覧ページをSSG＋CSR(ユーザーアクション)の時のページ生成のまとめ

<h2 id="h5ab13b7315">⚡️新しく取得した記事にアクセスしたら404エラーに</h2><p>ブログ記事一覧ページに無限スクロールを設置。</p><p>最初のアクセス時、10件分はSSGで静的HTMLを生成して表示して、11件目以降はユーザーのスクロールで取得する機能を実装。</p><p><span class="highlight">しかし、11件目以降の記事にアクセスすると404が表示された。</span></p><h2 id="hdf9bc7d661">✅原因はfallbackの設定</h2><p>getStaticPathsの設定で<code>fallback: false</code>にしていたことが原因。<br>ビルド時getStaticPathsで取得したデータに存在しなかったページは作られず、アクセスしても404になるとのこと。</p><pre><code class="language-javascript">export const getStaticPaths = async () =&gt; {
  const data = await getBlogDetail();

  const paths = data.contents.map((content) =&gt; `/blogs/${content.id}`);

  return { paths, fallback: false};
};</code></pre><p>ビルド後に動的ページにアクセスしたいなら<strong><span class="highlight">fallbackの設定が重要</span></strong>。</p><p>fallbackは、まだ生成されていないページにアクセスされたときの挙動を決めるオプション。</p><h2 id="hede87d6ba4">fallbackの設定を変えて解決🎉</h2><p><code>fallback: false</code>→<code>fallback: &quot;blocking&quot;</code>に変更すると初回アクセスでも表示された。</p><p><u>🔵blockingの挙動</u><br>ユーザーがアクセスするとサーバーがアクセスしたページをSSG化してくれる。<br>SSG化している間画面には何も表示されず、完了しだい該当ページが表示される。</p><pre><code class="language-javascript">export const getStaticPaths = async () =&gt; {
  const data = await getBlogDetail();

  const paths = data.contents.map((content) =&gt; `/blogs/${content.id}`);

  return { paths, fallback: &quot;blocking&quot; };
};</code></pre><h2 id="h4d13ded214">🔁fallback の3つの設定</h2><p>fallbackには下記3つの設定があり、それぞれの挙動が異なる。</p><table><tbody><tr><th colspan="1" rowspan="1"><p style="text-align: center">設定</p></th><th colspan="1" rowspan="1"><p style="text-align: center">挙動</p></th><th colspan="1" rowspan="1"><p style="text-align: center">特徴</p></th><th colspan="1" rowspan="1"><p style="text-align: center">注意点</p></th></tr><tr><td colspan="1" rowspan="1"><p>false</p></td><td colspan="1" rowspan="1"><p>ビルド時に定義されたパスのみSSG化。存在しないページは<strong>404</strong></p></td><td colspan="1" rowspan="1"><p>最もシンプル</p></td><td colspan="1" rowspan="1"><p>ページ追加時に再ビルドが必要。</p></td></tr><tr><td colspan="1" rowspan="1"><p>true</p></td><td colspan="1" rowspan="1"><p><strong>ユーザーがアクセスした時に初めてSSG化</strong>。ローディングUIが必要</p></td><td colspan="1" rowspan="1"><p>初回アクセス時に動的に生成</p></td><td colspan="1" rowspan="1"><p><code>useRouter().isFallback</code> による分岐が必要</p></td></tr><tr><td colspan="1" rowspan="1"><p>blocking</p></td><td colspan="1" rowspan="1"><p>アクセス時にサーバーでSSG化。完了するまで<strong>何も表示されない</strong></p></td><td colspan="1" rowspan="1"><p>SSRのような挙動。ローディング不要</p></td><td colspan="1" rowspan="1"><p>初回アクセスがやや遅い可能性あり</p></td></tr></tbody></table><p>blockingの設定にした場合、もし取得するデータ量が多いと表示までにタイムラグがある。<br>表示されるまで画面は真っ白な状態になってしまうため、その場合は「ローディング中です」などのローディングUIを準備すると良い💡</p><h2 id="h7b7bf1c3af">⭐️fallback:trueにしてローディングUIを作る場合</h2><p><code>useRouter</code> の <code>router.isFallback</code> を使ってローディングUIを表示させる。</p><p>fallback: true のときは、まだ静的に生成されていないページにアクセスされると、<strong>最初はpropsが渡ってこない</strong>状態でページが表示され始める。</p><p style="text-align: start">その間は router.isFallback が true になるので、それを使って「ローディング中」のUIを表示させる仕組み。</p><pre><code class="language-javascript">const CommentID = (props) =&gt; {
  const { fallback } = props;
  const router = useRouter();

  if (router.isFallback) {
    return &lt;div&gt;ローディング中&lt;/div&gt;;
  }</code></pre><h2 id="h1635ddce6f">⚠️Static Generationのfallbackは開発環境と本番環境で挙動が異なる</h2><p><strong>開発環境 (</strong><code>npm run dev</code>) では、getStaticPropsは常に再実行されるとのこと⚡️<br>そのため、新たに記事を投稿すると即座に一覧ページに表示される。</p><p>しかし本番環境では、初回ビルド時に取得したデータしか表示されない。</p><table><tbody><tr><th colspan="1" rowspan="1"><p>状態</p></th><th colspan="1" rowspan="1"><p>実行タイミング</p></th><th colspan="1" rowspan="1"><p>新記事が表示されるか</p></th></tr><tr><td colspan="1" rowspan="1"><p>本番（<code>next build &amp;&amp; next start</code>）</p></td><td colspan="1" rowspan="1"><p>getStaticPropsは<strong>ビルド時のみ1回</strong></p></td><td colspan="1" rowspan="1"><p>❌ 表示されない（revalidateなしなら）</p></td></tr><tr><td colspan="1" rowspan="1"><p>開発環境（<code>npm run dev</code>）</p></td><td colspan="1" rowspan="1"><p>毎回getStaticPropsが走る</p></td><td colspan="1" rowspan="1"><p>✅ 表示される</p></td></tr></tbody></table><h3 style="text-align: start" id="h02e6fe86c8">✅ ISR（Incremental Static Regeneration）の設定をしてSSG記事一覧が古くなるのを防ぐ</h3><p style="text-align: start"><code>revalidate</code> オプションを使うことで、一定時間ごとに静的HTMLを再生成可能にしてくれる。<br>設定した時間経過後、最初のアクセス時に<strong>バックグラウンドで再生成</strong>が走る。</p><pre><code class="language-javascript">return {
  props: {
    articles: data.contents,
  },
  revalidate: 60, // ← 60秒ごとに再生成OK
};</code></pre><p style="text-align: start">これで、ビルド後も定期的に「自動更新」されるようになった🎉</p><p style="text-align: start"></p><p style="text-align: start"></p>

CSRで新しく取得した記事が404になる原因とその解決方法。fallbackの設定で解決！

microCMS

Next.js×microCMS｜zustandを使用して無限スクロールで取得済みデータの再取得をしないようにする

Next.js×microCMS｜ブラウザバックや戻るボタンで元のスクロール位置に戻る方法

Next.js×microCMS｜ブログ記事一覧ページをSSG＋CSR(ユーザーアクション)の時のページ生成のまとめ

Next.js × microCMS｜SSGで記事を10件のみ生成。ユーザーアクションで取得した11件目へのアクセスは404になる原因と解決方法