導入

Next.js は、サーバーでレンダリングされる React アプリケーションを構築するための選択肢として長い間人気がありました。サーバーサイド レンダリング (SSR) のサポートが組み込まれているため、開発者は動的で SEO に優しいアプリケーションを作成できます。ただし、Next.js 13 での App Router の導入と Next.js 14 での改良により、SSR は大幅に簡素化および強化されました。

このブログ投稿では、従来のページ ルーティング システムと新しいアプリ ルーティング システムの間の SSR の違いを調査し、SSR の仕組みと、新しいルーティング パラダイムで SSR がどのように変更されるかを強調します。

ページ ルーティングの SSR (Pre-Next.js 13)

App Router が導入される前は、SSR は getServerSideProps などの特定の関数を使用してページ ルーティング システムで処理されていました。この関数はリクエストごとに呼び出され、開発者がページをレンダリングする前にサーバー側でデータを取得できるようになりました。

getServerSideProps を使用したページ ルーティングの SSR の例:

export default function Blogs({ data }) {
  // Render the fetched data
  return (
    

      {data.map((item) => (
        

          
{item.title}
          
{item.content}
        
      ))}
    
  );
}

// This function runs on every request
export async function getServerSideProps() {
  // Fetch data from an external API
  const res = await fetch('https://api.example.com/blogs');
  const data = await res.json();

  // Pass the data as props to the page component
  return { props: { data } };
}

ここで、getServerSideProps はページ ルーティング システムの SSR へのキーです。これにより、リクエストごとに API (またはその他のデータ ソース) からデータを取得し、それを props としてページ コンポーネントに渡すことができます。このパターンは強力ですが、多くのサーバー側ロジックやさまざまなルートを処理する場合、コードベースが複雑になる可能性があります。

Next.js 14 のアプリのルーティングと SSR

Next.js 14 では、SSR がより合理化され、アプリ ルーティング システムに統合されました。この新しいシステムではサーバー コンポーネントとクライアント コンポーネントが導入されており、SSR はより直感的に使用できます。

アプリ ルーティングでは、getServerSideProps などの特別な関数を必要とせずに、コンポーネント内のデータを直接フェッチできるようになりました。これは、サーバー アクションを使用することで実現できます。これにより、コードがシンプルになり、保守が容易になります。

サーバー コンポーネントを使用したアプリ ルーティングの SSR の例:

"use server";

export async function getBlogs() {
  try {
    const response = await fetch('https://api.example.com/posts');
    return response.json();
  } catch (error) {
    return { error: error.message };
  }
}

// This component runs on the server and fetches data
export default async function Blog() {
  const blogs = await getBlogs();

  return (
    

      {(blogs || []).map((blog) => (
        

          
{blog.name}
          
{blog.content}
        
      ))}
    
  );
}

このアプリ ルーティングの例では、サーバー コンポーネントを使用して、サーバーを使用してコンポーネント ファイル内でデータを直接フェッチしています。これにより、getServerSideProps.

サーバー アクションの力
Next.js 14 では、サーバー アクションを導入することでプロセスを簡素化しています。これらのアクションにより、コンポーネント ファイル内のデータを直接フェッチして処理できるため、複雑さが軽減され、コードベースがより保守しやすくなります。

サーバー アクションの主な利点:

クリーンなコード: サーバー側のロジックを個別のファイルや関数に分散させる代わりに、すべてを 1 か所に保管できます。
保守性の向上: 可動部分が減れば管理するコードも減り、アプリケーションの保守が容易になります。
パフォーマンスの向上: インテリジェントなキャッシュ メカニズムを使用すると、サーバー側のロジックを微調整してパフォーマンスを最適化できます。

Next.js でのハイドレーション

Next.js とサーバーサイド レンダリング (SSR) のコンテキストでは、ハイドレーションとは、静的にレンダリングされた HTML ページ (サーバーから送信) がブラウザー内で完全にインタラクティブな React アプリケーションに変換されるプロセスを指します。 React のクライアント側 JavaScript で静的 HTML を「ハイドレート」して、ページをインタラクティブにします。

アプリルーティングとページルーティングのハイドレーション

ページ ルーティングでは、ページ上のすべてのコンポーネントにハイドレーションが必要であり、クライアント側でインタラクティブになります。これは、対話に必要なすべての JavaScript がクライアントに送信されることを意味し、アプリケーションがスケールするにつれてパフォーマンスのボトルネックが発生する可能性があります。

アプリ ルーティングでは、サーバー コンポーネントを使用すると、クライアント コンポーネント (対話性を処理するコンポーネント) のみがハイドレートされます。この選択的なハイドレーションにより、クライアントに送信される JavaScript の量が削減され、パフォーマンスが向上します。

アプリ ルーティングのクライアント コンポーネントの例:

'use client';  // Mark this as a client component

export default function Button() {
  return (
     alert('Button clicked!')}>Click Me
  );
}

ここでは、Button コンポーネントは「クライアントを使用する」というクライアント コンポーネントとしてマークされています。これにより対話型が可能になり、クライアント側で実行されますが、他の非対話型コンポーネントはサーバー コンポーネントとして残り、パフォーマンスが向上します。

アプリルーティングにおけるハイドレーションの詳細

仕組みは次のとおりです:

サーバーコンポーネントとしての親コンポーネント:

親コンポーネント (通常は上位レベルのコンポーネントまたはページ コンポーネント全体) は通常、サーバー コンポーネントです。これらはサーバー上で実行され、データの取得、静的 HTML のレンダリング、そのデータの子コンポーネントへの受け渡しなどを処理します。
これらはサーバーでレンダリングされるため、クライアント側に JavaScript は含まれず、インタラクティブではありません。

インタラクティブ性のためのクライアント コンポーネント:

対話性 (ボタン、フォームなど) を処理する子コンポーネントは、クライアント コンポーネントです。これらのコンポーネントは React フック (useState、useEffect など) を使用でき、クライアント側でハイドレートされます。
サーバー コンポーネントは、props.
を介してこれらのクライアント コンポーネントにデータを渡します。 HTML がブラウザーに読み込まれると、Next.js がクライアント コンポーネントをハイドレートし、必要なイベント リスナーをアタッチしてページをインタラクティブにします。

// Server Component (Parent Component)
export default async function ParentComponent() {
  // Fetch data on the server
  const data = await fetch('https://api.example.com/data').then(res => res.json());

  return (
    

      
This is Server-Side Rendered
      
  );
}

// Client Component (Child Component)
'use client';

import { useState } from 'react';

function ClientComponent({ data }) {
  const [count, setCount] = useState(0);

  return (
    

      
Data from server: {JSON.stringify(data)}
      
Client-side counter: {count}
       setCount(count   1)}>Increment
    
  );
}

結論

Next.js 14 では、App Router にサーバー アクションが導入され、サーバーサイド レンダリング (SSR) がより簡単かつ強力になりました。この新しいシステムは、開発者がコンポーネント ファイル内でデータを直接フェッチできるようにすることで、サーバー側のロジックを合理化し、コードベースを簡素化し、個別の API ルートの必要性を減らします。選択的ハイドレーションと組み合わせることで、Next.js 14 の SSR はより高速かつ効率的になり、非常に動的で SEO に優しいアプリケーションを簡単に構築できるようになりました。

これらのサーバー アクションを活用すると、コードをクリーンで保守しやすく保ちながら、アプリのパフォーマンスを向上させることができます。ページ ルーティングからサーバー コンポーネントとクライアント コンポーネントを使用したアプリ ルーティングへの移行は、スケーラブルな Web アプリケーションの構築における大きな進歩を表しています。