Next.js 14 (Page Router 방식)

쿼리스트링 사용방법

import { useRouter } from "next/router";

export default function Page() {

  const router = useRouter(); // router 객체가 이 변수에 저장됨

  return <>search</>;

}

/a/b/c/d/e/f 하려면 (...id).tsx 하면 됨: catch all segment 여러개의 경우 router.query 의 id가 배열로 저장됨 ((...id)).tsx 시에는 ~/ 도 대응함 (index) : optinal catch all segment

찾을수 없거나 없는 페이지 안내멘트는 /pages/404.tsx 를 만들면 된다.

네비게이팅

TAG: CSR 방식으로 페이지를 이동하는 방식이 아닌, 일반적인 SSR 방식으로 페이지 이동, 그러므로 페이지 이동이 느림

스타일링

• inline style 입력 가능
• css 파일을 import 하여 사용 가능
  • App Component 가 아닌경우 css 불러오기를 제한함 (클래스 네임 충돌을 방지하기 위함)
• Next.js가 기본적으로 CSS Module
  • 기존의 CSS 파일을 모듈처럼 사용할 수 있도록 함
  • className이 충돌되지 않도록 unique 이름으로 변환 (파일마다)
  • index.module.css 파일 생성
  • 사용방법

  • import style from "./index.module.css"
    
    export default function Page() {
    return <h1 className={style.h1}>index</h1>
    

페이지별 레이아웃 설정방법

// _app.tsx
import GlobalLayout from "@/components/global-layout";
import "@/styles/globals.css";
import type { AppProps } from "next/app";
import { ReactNode } from "react";
import { NextPage } from "next";

type NextPageWithLayout = NextPage & {
  getLayout?: (page: ReactNode) => ReactNode; // optional type으로 설정
};

export default function App({ Component, pageProps }: AppProps & { Component: NextPageWithLayout }) {
  // getLayout 메소드가 없는 경우에는 page를 반환
  const getLayout = Component.getLayout ?? ((page: ReactNode) => page);
  return <GlobalLayout>{getLayout(<Component {...pageProps} />)}</GlobalLayout>;

}

// index.tsx
import { ReactNode } from "react";
import SearchableLayout from "@/components/searchableLayout";

export default function Home() {
  return <>abcdefg</>
}

Home.getLayout = (page: ReactNode) => {
  return <SearchableLayout>{page}</SearchLayout>
}

interface <= 객체타입을 정의하기 위한 TypeScript의 문법임

.className::before {} <= 가상요소

프로그래매틱한 페이지 이동

(사용자가 클릭했을때 페이지를 이동하는 방식이 아닌, 특정 버튼을 눌렀을때 함수가 발생, 혹은 어떠한 이벤트가 발생)

• 예시로, 버튼에 이벤트를 주어 페이지 이동처리함
  • 페이지 이동에는 useRouter(next/router) 사용
  • useRouter
    • replace : history 에 추가하지 않고 페이지 이동 (이전페이지 이력이 없으므로 뒤로가기 불가능)
    • push : history 에 추가 후 페이지 이동 (페이지 뒤로가기 했을때 이전 페이지의 이력이 남음)
    • prefetch : 클라이언트 전화를 빠르게 하기 위해 페이지를 미리 가져옴
    • back : history.back() 과 동일한 기능 (뒤로가기)
    • beforePopState : popState를 감지 후 라우터가 처리 전 수행하기 위한 이벤트
    • reload : 새로고침
    • events : router 내에서 발생하는 다양한 이벤트 감지 기능

프리페칭(prefetch)

• pre: 사전에 미리

• fetching: 불러온다

• next.js에서 초기 접속시 모든 js 번들을 전달하는 것이 아닌, /index인경우 /index에 필요한 번들만 전달, /search 등의 페이지의 번들은 전달하지 않음

• 모든 js 번들을 전달하게 되면 한번의 전달되는 파일의 크기가 커지기 때문에, 다운로드 받는 속도도 브라우저는 느려지기 때문

• pre-fetching 시, 초기접속이 완료 된 후 페이지 이동 전 미리 js 번들을 받아둠 (pre-fetching)

• 기본적으로 Link 컴포넌트로 명시되지 않은경우 pre-fetch가 안되는데,

  useEffect(() => {
    router.prefetch("/test");
  }, []);

위와 같이 작성시 페이지를 모두 렌더링 후 작성된 페이지를 미리 pre-fetching 함

• 만약 next/link 링크컴포넌트로 작성 후 prefetch를 하지 않고 싶은경우 <Link href={'/link'} prefetch={false} />

API Routes

Next.js에서 API를 구축할 수 있게 해주는 기능

경로

/api/[..path]

React App 에서의 데이터 페칭 (마운트 후 렌더링)

export default function Page() {
  const [state, setState] = useState(); // 1. 불러온 데이터를 보관할 State를 생성
  
  const fetchData = async () => { // 2. 데이터 페칭 함수 생성
    const response = await fetch("...");
    const data = await response.json();
    
    setState(data);
  }
  
  useEffect(() => { // 3. 컴포넌트 마운트 시점에 fetchData 호출
    fetchData();
  }, [])
  
  if(!state) return "Loading..."; // 4. 데이터 로딩중일때의 예외처리
  
  return <div>...</div>;
}

• 컴포넌트 마운트 이후에 발생함

• 데이터 요청 시점이 느려지게 되는 단점 발생

Next.js의 데이터 페칭 (사전 렌더링)

• 사전 렌더링중 발생함 (컴포넌트 마운트 이후에도 발생 가능)

• 데이터 요청 시점이 매우 빨라지는 장점이 있음

• 사전 렌더링이 오래걸릴것 같은 경우 빌드타임을 미리 맞춰두도록 함

• 서버 사이드 렌더링 (SSR: Server Side Rendering)

  • 가장 기본적인 사전 렌더링 방식
  • 요청이 들어올 때 마다 사전 렌더링을 진행함

• 정적 사이트 생성 (SSG: Static Site Generation)

  • SSR의 단점을 해결하는 사전 렌더링 방식
  • 빌드 타임에 미리 페이지를 사전 렌더링 해둠
  • 단점: 빌드타임 이후에는 최신데이터 반영은 어려움 (똑같은 페이지만 응답)

• 증분 정적 재생성 (ISR)

  • 향후에 다룰 사전 렌더링 방식

SSR (서버사이드 렌더링)

export const getServerSideProps = () => {
  // 컴포넌트보다 먼저 실행, 컴포넌트에 필요한 데이터 불러오는 함수
  // 오직 한번만 실행되는 함수이므로, 처음 렌더링 당시에만 서버에서 실행함.
  
  console.log("서버사이드 Props"); // 이 로그는 브라우저(Client)에서 나오지 않고, 서버측 콘솔에만 보임
  
  // window.location; <= javascript의 window 객체는 클라이언트의 객체를 의미함, client 문법은 오류가 발생함.
  
  const data = "hello";
  
  return {
    props: { // 반드시 props 구조가 있어야 함
     data
    }
  }
}

export default function Home({ data }: any) {
  // 이 컴포넌트 또한 서버에서 1회 실행 후, 브라우저에서 실행됨
  // 첫번째는 사전렌더링을 위해 서버측에서 1회 실행, 브라우저 측
  return <>{data}</>
}

• getServerSideProps 의 역할

  • 브라우저에서 해당 페이지로 접속시, page컴포넌트 보다 먼저 실행되어서 해당 컴포넌트에 필요한 데이터를 다른 백엔드 서버에서 불러오는 함수
  • 절차
    1. localhost:3000/index 접속
    2. ➡️ index.tsx의 getServerSideProps 실행
    3. ➡️ 최종 페이지 컴포넌트 실행

• 서버컴포넌트 (페이지 컴포넌트) 인경우에는 클라이언트 객체 사용안됨.

• 단, useEffect(() => {}, []) 를 통해 클라이언트 객체를 사용할 수 있음.

• InferGetServerSidePropsType 타입: getServerSideProps 함수의 반환값 타입을 자동으로 추론해줌. 을 포함하면 자동으로 추론해줌

병렬로 Promise 처리방법

export const getServerSideProps = async () => {

/**
  * 기존의 경우 직렬방식, allbooks가 끝나야 recobooks
  * const allBooks = await fetchBooks();
  * const recoBooks = await fetchRandomBooks();
*/

    // 병렬방식으로 변경
    const [allBooks, recoBooks] = await Promise.all([fetchBooks(), fetchRandomBooks()]);

  

  return { props: { allBooks, recoBooks } };

};

GetServerSideProps에서 쿼리스트링 받는법

export const getServerSideProps = async (context: GetServerSidePropsContext) => {

  return { props: {} };

};

GetStatic 방식으로 페이지 생성하는법 (SSG)

// 기본적으로 getServerSideProps와 동일
export const getStaticProps = async () => {


  // const q = context.query.q;
  // 빌드타임에는 쿼리스트링을 알 수 없음.
  
  const [allBooks, recoBooks] = await Promise.all([fetchBooks(), fetchRandomBooks()]);

  return { props: { allBooks, recoBooks } };

};

export default function Home({ allBooks, recoBooks }: InferGetStaticPropsType<typeof getStaticProps>) {
});

○ (Static) prerendered as static content => SSG와 동일한 정적 페이지, 기본값으로 설정된 페이지 ● (SSG) prerendered as static HTML (uses getStaticProps) ƒ (Dynamic) server-rendered on demand => SSR

SSG 사전 렌더링 사이트 생성

Dynamic한 경로의 경우 getStaticPaths가 필요함

빌드타임(Build Time) [id].tsx 사전렌더링

1. 경로 설정이 필요
   1. id: 1
   2. id: 2
   3. id: 3

export const getStaticPaths = () => {
  return {
    paths: [
      { params: { id: "1" } },
      { params: { id: "2" } },
      { params: { id: "3" } }
    ], 
    fallback: false // 없는페이지에 대한 대비책
  };

};

fallback 옵션 (없는 경로로 요청시)

• false: 404 Not Found로 반환
• blocking: 즉시 생성 (Like SSR)
• true: 즉시 생성 + 페이지만 미리 반환 (먼저 레이아웃만 반환 후 데이터를 반환 함)

1. 사전 렌더링
   1. 결과: 3개의 페이지 렌더링
      1. book/1.html
      2. book/2.html
      3. book/3.html

ISR 증분 정적 재생성 (Incremental Static Regeneration)

단순히 SSG 방식으로 생성된 정적 페이지를 일정 시간을 주기로 다시 생성하는 기술

• SSG의 특성으로 한번 생성된 데이터는 새롭게 업데이트가 되더라도 해당 페이지가 업데이트 되지는 않음
• SSG와 SSR의 장점을 결합한 방식임
• 단 설정된 유통기한의 시간이 종료되기 전까지는 기존 내용이 보여지고, 해당 유통기한 시간이 지나면 새롭게 업데이트 됨.

export const getStaticProps = async () => {

  const [allBooks, recoBooks] = await Promise.all([fetchBooks(), fetchRandomBooks()]);

  return { props: { allBooks, recoBooks }, revalidate: 3 };

};

• revalidate 3초 간격으로 재 생성

• 시간 기반의 ISR을 적용하기 어려운 페이지도 존재함

• 시간과 관계없이 사용자의 행동에 따라 데이터가 업데이트 되는 페이지

  • 게시글 수정: 페이지 데이터를 업데이트 해야 함
  • 게시글 삭제: 페이지를 제거해야 함
  • 요청을 받을 때마다 페이지를 다시 생성하는 (On-Demand ISR)
    • 수정/삭제시 revalidate 요청

SEO 설정

import Head from "next/head";

import Head from "next/document" // 이 모듈은 _document.tsx 에서 사용됨

const Home = () => {
  return (
    <>
      <Head>
        <title>한입북스</title>
        <meta property="og:image" content="/thumbnail.png" />
        <meta property="og:title" content="한입북스" />
        <meta property="og:description" content="한입 북스에 등록된 도서들을 만나보세요." />
      </Head>
    </>
  );
}

• og의 경우 opengraph의 약자
• og:image: 카카오톡, 페이스북 등 각종 SNS 에서 미리 보여질 섬네일 이미지
• og:title: 카카오톡, 페이스북 등 각종 SNS 에서 미리 보여질 페이지 제목
• og:description: 카카오톡, 페이스북 등 각종 SNS 에서 미리 보여질 페이지 설명

배포

• 배포방법은 vercel 로 배포하는 방법이 있음

# sudo npm i -g vercel (windows의 경우 powersheel, cmd를 관리자 권한)
# vercel login
# vercel --prod (바로 production 모드로 컴파일됨)

Page Router 단점

1. 페이지별 레이아웃 설정이 번거롭다.
   1. Page.getLayout 설정의 문제
2. 데이터 페칭이 페이지 컴포넌트에 집중된다.
   1. getServerSideProps, ... 등 페이지 컴포넌트에 항상 Props로 전달해야하는 문제
3. 불 필요한 컴포넌트들도 JS Bundle에 포함된다.
   1. FCP 시점 이후 하이드레이션을 위해 JS Bundle로 전달하는 과정에 불필요한 컴포넌트도 전달하는 문제
   2. 상호작용이 필요없는 컴포넌트 조차도 하이드레이션이 이루어지는 문제