Next.js の SSR ページ ルーティングと比較したアプリ ルーティングの新機能

はじめに

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 (
    <div>
      {data.map((item) => (
        <div key="{item.id}">
          <h3 id="item-title">{item.title}</h3>
          <p>{item.content}</p>
        </div>
      ))}
    </div>
  );
}

// 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 (
    <div>
      {(blogs || []).map((blog) => (
        <div key="{blog._id}">
          <h3 id="blog-name">{blog.name}</h3>
          <p>{blog.content}</p>
        </div>
      ))}
    </div>
  );
}

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

などの個別の API ルートや関数が必要なくなります。

サーバー アクションの力
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 (
    <button onclick="{()"> alert('Button clicked!')}>Click Me</button>
  );
}

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

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

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

Parent Components as Server Components:

The parent components (usually the higher-level components or entire page components) are typically Server Components. They run on the server and handle things like data fetching, rendering static HTML, and passing that data down to child components.
Since these are server-rendered, they do not include any JavaScript on the client-side, and they are not interactive.

Client Components for Interactivity:

Child components, which handle interactivity (like buttons, forms, etc.), are Client Components. These components can use React hooks (useState, useEffect, etc.) and are hydrated on the client-side.
Server Components pass data to these Client Components via props.
Once the HTML is loaded in the browser, Next.js hydrates the Client Components, attaching the necessary event listeners and making the page interactive.

// 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 (
    <div>
      <h1 id="This-is-Server-Side-Rendered">This is Server-Side Rendered</h1>
      <clientcomponent data="{data}"></clientcomponent>
    </div>
  );
}

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

import { useState } from 'react';

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

  return (
    <div>
      <p>Data from server: {JSON.stringify(data)}</p>
      <p>Client-side counter: {count}</p>
      <button onclick="{()"> setCount(count + 1)}>Increment</button>
    </div>
  );
}

Conclusion

Next.js 14 makes Server-Side Rendering (SSR) easier and more powerful with the introduction of server actions in the App Router. By allowing developers to fetch data directly inside component files, this new system streamlines server-side logic, simplifies codebases, and reduces the need for separate API routes. Coupled with selective hydration, SSR in Next.js 14 is now faster and more efficient, helping you build highly dynamic and SEO-friendly applications with ease.

By leveraging these server actions, you can improve your app’s performance while keeping your code clean and maintainable. The shift from Page Routing to App Routing with Server and Client Components represents a major leap forward in building scalable web applications.

以上がNext.js の SSR ページ ルーティングと比較したアプリ ルーティングの新機能の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。