Next.js의 SSR 페이지 라우팅과 비교한 앱 라우팅의 새로운 기능

소개

Next.js는 오랫동안 서버 렌더링 React 애플리케이션 구축에 널리 사용되어 왔습니다. 서버 측 렌더링(SSR)에 대한 기본 지원을 통해 개발자는 동적이고 SEO 친화적인 애플리케이션을 만들 수 있습니다. 그러나 Next.js 13의 App Router 도입과 Next.js 14의 개선으로 SSR이 크게 단순화되고 향상되었습니다.

이 블로그 게시물에서는 기존 페이지 라우팅 시스템과 최신 앱 라우팅 시스템 간의 SSR 차이점을 살펴보고 SSR 작동 방식과 새로운 라우팅 패러다임에 따라 어떻게 변경되는지 강조하겠습니다.

페이지 라우팅의 SSR(Pre-Next.js 13)

앱 라우터가 도입되기 전에는 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는 서버 작업을 도입하여 프로세스를 단순화합니다. 이러한 작업을 통해 구성 요소 파일 내에서 데이터를 직접 가져오고 처리할 수 있으므로 복잡성이 줄어들고 코드베이스의 유지 관리가 더욱 쉬워집니다.

서버 작업의 주요 이점:

클리너 코드: 서버 측 로직을 별도의 파일이나 함수에 분산시키는 대신 모든 것을 한 곳에 보관할 수 있습니다.
향상된 유지 관리성: 움직이는 부품이 적다는 것은 관리해야 할 코드가 적다는 것을 의미하므로 애플리케이션을 더 쉽게 유지 관리할 수 있습니다.
더 나은 성능: 지능형 캐싱 메커니즘을 사용하면 최적의 성능을 위해 서버측 로직을 미세 조정할 수 있습니다.

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 구성 요소는 'use client'로 클라이언트 구성 요소로 표시됩니다. 이는 상호작용을 허용하고 클라이언트 측에서 실행되는 반면, 기타 비대화형 구성요소는 서버 구성요소로 유지되어 성능을 향상시킵니다.

앱 라우팅의 수분 공급에 대한 자세한 내용

작동 방식은 다음과 같습니다.

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 중국어 웹사이트의 기타 관련 기사를 참조하세요!