[한경xToss] 12-13주차 요약(2) : Next.JS

 

개인의 학습 내용 기록 중, 극히 일부의 내용만 작성되었습니다.

 

 

React VS Next

리액트 : CSR (클라이언트 사이드 렌더링) - 번들

유저 pc에서 js와 html을 그려줌

1. 검색엔진(SEO)에 안걸림
2. 첫 로딩시 지연 발생

넥스트 : SSR (서버사이드 렌더링) - 리액트 제작하고, html을 내려줌

1. 검색엔진에 나옴
2. 지연이 발생되지 않음
3. fetch 함수 최적화, 모든 기능 최적화 제공
4. 별도의 라우터 설정이 필요 없고, 파일시스템 기반 라우팅 제공

SSR 장점 : 보안성, 호환성, SEO 최적화

단점 : 더 많은 자원 소모, 많은 부하, 유지보수 비용 증가, 페이지 요청 시간 증가, 브라우저 전용 API 사용 시 명시적 지정 필요

 

 

📌 예시

서버 컴포넌트 (app/page.tsx)

// 기본적으로 서버 컴포넌트
export default async function Home() {
  const data = await fetch('<https://api.example.com/data>')
  const result = await data.json()

  return <div>{result.title}</div>
}

 

클라이언트 컴포넌트 (components/Button.tsx)

'use client'

import { useState } from 'react'

export default function Button() {
  const [count, setCount] = useState(0)

  return <button onClick={() => setCount(count + 1)}>클릭 {count}</button>
}

 

 

---

Next.js 프로젝트 팁

 

1. 하단 네비 버튼 없애기 : globals.css 에서

nextjs-portal { display: none; }

 

2. Next.js에서 폴더 이름을 대괄호([])로 감싸면 동적 라우팅(dynamic routing)이 적용

예를 들어,

pages/products/[id].js

파일이 있다면,

이건 /products/123, /products/abc 같은 경로를 동적으로 처리할 수 있다는 뜻

---

next js 에러 페이지 / 로딩 페이지

 

만들기만 하면 알아서 적용된다.

 

자동으로 적용되는 이유 ⇒ Next.js의 파일 시스템 기반 라우팅과 자동 오류 처리 및 로딩 상태 관리 때문

1. app/ 디렉토리 내에 error.tsx 파일을 추가하면, Next.js는 앱의 모든 페이지에서 발생한 오류를 자동으로 처리
   1. 자동 적용: 이 파일이 있는 디렉토리에서 발생한 예외나 오류를 자동으로 캐치하고, 사용자가 정의한 에러 UI를 렌더링함.
2. app/ 디렉토리 내에 loading.tsx 파일을 추가하면, Next.js는 해당 디렉토리에서 컴포넌트가 로딩 중일 때 자동으로 로딩 UI를 표시
   1. 자동 적용: 이 파일은 페이지나 컴포넌트가 비동기적으로 로드될 때 로딩 상태를 자동으로 표시

 

원리: React Suspense + 서버 사이드 렌더링(SSR)

Next.js는 React의 Suspense 기능을 사용하여 비동기 데이터를 처리하고, 서버 사이드 렌더링(SSR)을 통해 컴포넌트를 서버에서 미리 렌더링하여 페이지를 빠르게 로드함

• loading.tsx는 React Suspense가 데이터를 로딩하는 동안 표시되는 컴포넌트
• error.tsx는 try-catch나 오류 발생 시 React의 오류 경계를 활용하여 에러가 발생한 부분을 캡처하고 대체 UI를 제공

---

Next.js의 fetch 캐싱 전략

1. 기본 동작:
   • fetch는 기본적으로 force-cache로 동작 → 같은 요청이면 캐시 재사용 (빌드 시/런타임 모두).
   • 클라이언트 사이드도 캐싱되지만, 갱신하려면 설정 필요.
2. cache 옵션:
   • force-cache: 캐시된 데이터 사용 (기본값).
   • no-store: 항상 새 데이터 요청 (실시간 데이터에 적합).
3. 재검증 (ISR):
   • next: { revalidate: 초 } → 주기적으로 캐시 갱신.
4. 동적 데이터:
   • 동적 URL도 각각 캐싱됨.
   • 실시간성 필요하면 no-store 사용.
5. 클라이언트 사이드:
   • useSWR 등 라이브러리로 캐싱/갱신 세밀 제어 가능.
6. 주의사항:
   • GET만 캐싱됨, dev 모드에서는 캐싱 X.
   • URL/헤더/쿼리 같아야 캐시 재사용.