next.js from scratch

About this offer

프로젝트 생성 node.js 프로젝트 생성 -> npx create-next-app@latest 프로젝트이름 프로젝트 셋팅 (공부용) TypeScript → Yes ESLint → Yes Tailwind → Yes src/ → No App Router → Yes 권장 설정을 체크했다. Need to install the following packages: create-next-app@16.3.8 Ok to proceed? (y) y √ Would you like to use the recommended Next.js defaults? » Yes, use recommended defaults TypeScript 타입 안정성 ESLint is not Formatter ESLint ≠ 포매터라는 것. Prettier → 코드 모양을 예쁘게 정리 ESLint → 코드가 올바른가? → 문제 있는 패턴인가? - 이 변수 안 쓰고 있는데? - React에서는 더 중요 -> Hook을 잘못 사용하는 패턴이나 의존성 문제 등을 검사 프론트엔드 스타일링 방식 특징 이번 프로젝트에서 일반 CSS .css 파일에 스타일 작성 가능하지만 파일을 오가야 함 CSS Modules 컴포넌트별 CSS 파일 + 클래스 이름 충돌 방지 깔끔하지만 파일이 늘어남 styled-components JS/TS 안에서 CSS 작성 동적 스타일에 좋지만 별도 라이브러리 Tailwind className 에 유틸리티 조합 이번 학습 프로젝트에 적합 처음 배우는 프로젝트에서 이것들을 여러 개 섞으면 학습 포인트가 흐려지니까 하나를 골라서 쓰는 게 좋다 -> Tailwind CSS만 사용 프론트엔드 스타일링 │ ├─ CSS를 직접 작성하는 계열 │ ├─ CSS / CSS Modules │ └─ Sass(SCSS) │ ├─ 유틸리티 CSS 계열 ("스타일을 내가 조립한다.") │ ├─ Tailwind CSS │ └─ UnoCSS │ └─ UI 컴포넌트 ("React UI 컴포넌트를 가져다 쓴다.") / CSS 프레임워크 계열 ("미리 만들어진 CSS 스타일을 가져다 쓴다.") ├─ Bootstrap ├─ Chakra UI ├─ MUI ├─ Ant Design └─ Mantine /src 폴더 사용 안함. 작은 학습 프로젝트 → src 없어도 됨 src는 코드를 한 단계 안쪽으로 넣어서 정리하는 폴더일 뿐 -> 왜 src를 쓰나? 큰 프로젝트의 경우 디렉토리 구조 project/ ├── app/ ├── components/ ├── hooks/ ├── lib/ ├── public/ ├── tests/ ├── scripts/ ├── config/ ├── package.json └── ... project/ ├── src/ ---> 복잡해지니까 실제 애플리케이션 코드를 한단계 안쪽으로 정리 │ ├── app/ │ ├── components/ │ ├── hooks/ │ └── lib/ ├── public/ ├── tests/ ├── package.json └── ... Pages Router vs App Router Pages Router App Router 기준 디렉터리 pages/ app/ 등장 시기 기존 방식 최신 방식 서버 컴포넌트 기본 지원 X 기본 지원 Layout 직접 구성하는 경우가 많음 layout.tsx 로 자연스럽게 구성 데이터 처리 기존 Next.js 방식 Server Component 중심 현재 신규 프로젝트 유지보수에는 많이 존재 신규 프로젝트에서 주로 사용 2016 ~ 2022 │ │ Pages Router 시대 │ pages/가 사실상 기본 │ ├── Next.js 13 (2022.10) │ app/ 등장 │ → 아직 Beta │ ├── Next.js 13.4 (2023.05) │ ⭐ App Router Stable │ → 신규 프로젝트에 App Router 권장 │ 2023 ~ 현재 │ │ App Router가 새로운 기본 방향 │ Pages Router도 계속 지원 │ └── 2026 현재 → 새 프로젝트: App Router 권장 → 기존 프로젝트: Pages Router도 정상적으로 사용 Pages Router pages/ ├── index.tsx ├── products.tsx └── products/ └── [id].tsx / → index.tsx /products → products.tsx /products/1 → [id].tsx App Router : Pages Router와 URL 구조는 비슷하지만 컴포넌트와 서버 기능을 결합해서 설계하기 편함 app/ ├── page.tsx ├── products/ │ ├── page.tsx │ └── [id]/ │ └── page.tsx └── layout.tsx 예를 들어 MES가 있다고 하자. ┌─────────────────────────────┐ │ 회사 로고 사용자 정보 │ ├─────────┬───────────────────┤ │ 메뉴 │ │ │ 생산관리 │ 화면 내용 │ │ 재고관리 │ │ │ 출고관리 │ │ └─────────┴───────────────────┘ 왼쪽 메뉴와 위쪽 헤더는 모든 페이지에서 계속 유지를 원함. App Router에서는 이걸 아주 자연스럽게 표현: app/ ├── layout.tsx ← 전체 공통 ├── page.tsx ← / │ └── mes/ ├── layout.tsx ← MES 공통 ├── production/ │ └── page.tsx └── inventory/ └── page.tsx layout │ ├── 생산관리 페이지 │ └── 재고관리 페이지 이런 페이지 구조 자체를 폴더 구조로 표현 가능하다. Pages Router에도 공통 레이아웃을 만들 수 있 지만 구조적으로 App Router만큼 자연스럽지는 않았다. 예를 들어 예전에는 _app.tsx를 사용해서 전체 페이지를 감싸는 구조를 만들었다. export default function App({ Component, pageProps }) { return ( <Layout> <Component {...pageProps} /> </Layout> ); } 전체 사이트 공통 Layout 은 만들기 쉬운데, MES 공통 Layout ├── 생산관리 ├── 재고관리 관리자 공통 Layout ├── 사용자 관리 └── 권한 관리 처럼 여러 단계의 레이아웃을 자연스럽게 중첩하는 구조는 불편했다. Next.js가 App Router를 만든 중요한 이유 중 하나 현재 App Router를 배우는 가장 중요한 이유 App Router에서는 기본적으로 컴포넌트가 Server Component이다. // app/products/page.tsx export default async function ProductsPage() { const products = await getProducts(); return ( <div> ... </div> ); } // 서버에서 데이터를 가져와서 화면을 만들어 보낼 수 있다. 버튼 클릭이나 useState 같은 브라우저에서 동작해야 하는 것은 따로 지정 : "use client"; // Client Component import { useState } from "react"; 즉 App Router는 단순히 "pages를 app으로 바꾼 것"이 아니라, React Server Components를 중심으로 Next.js의 구조 자체를 새로 만든 것이다. 실행 확인 cd 프로젝트 npm run dev