| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | ||||
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 | 31 |
- 희망
- 파이썬 장고
- Python Class
- Kotlin Class
- Kotlin If
- Kotlin 클래스
- Python
- 넥스트js
- 장고 가상환경
- 클래스 속성
- Kotlin 클래스 속성정의
- 파이썬
- Kotlin 조건문
- github
- 강제 타입변환
- 다중조건문
- python Django
- 자바 기본타입
- 파이썬 클래스
- django virtualenv
- 파이썬 반복문
- 도전
- activate 오류
- 파이썬 제어문
- Kotlin else if
- 좋은글
- 성공
- NextJs
- Variable declaration
- git
- Today
- Total
목록분류 전체보기 (141)
키모스토리
0) 프로젝트 생성 pnpm create next-app@latest member-demo --ts --src-dir --tailwind --eslint --appcd member-demo 프로젝트 폴더구조src/ app/ members/ page.tsx // 회원목록 (Server Component) actions.ts // 서버액션모음 (등록/수정/삭제) register/ page.tsx // 회원가입 페이지 SignupForm.tsx // 회원가입 폼 (Client Component) [id]/ edit/ page.ts..
폼 제출 2가지 방식 비교: form action(Server Actions) vs onSubmit(Client Handler)1) 핵심 차이: “어디서 처리하나?”Server Actions ()폼 제출이 곧바로 서버 함수 실행으로 연결됩니다.DB 처리/권한 체크/캐시 무효화까지 서버에서 끝냅니다.Client Handler ()제출을 JS로 가로채서(preventDefault) 클라이언트에서 fetch/axios로 API를 호출합니다.UI 제어(로딩/검증/토스트/optimistic)가 매우 자유롭습니다.2) Server Actions 방식이 유리한 경우장점코드가 단순: API 라우트 없이도 CRUD 구현 가능보안에 유리: DB/비밀키를 브라우저로 내보낼 필요 없음캐시/ISR 연동이 자연스러움: updat..
Next.js 16(App Router) + Prisma v7 + SQLite 기준으로설치 → DB 생성(migrate) → seed 목록/상세 CRUD UI → 캐시/ISR(revalidate) 전략 + Data Fetching 패턴 비교까지 한 번에 들어있는 예제입니다.Prisma v7 변경점: schema.prisma의 datasource.url 제거 + prisma.config.ts로 이동.Next 16 변경점: revalidateTag(tag, profile) 형태로 2번째 인자가 필요Server Action에서는 즉시 반영용 updateTag 권장Next.js+4Prisma+4Prisma+40) 전제Node 런타임에서 Prisma를 사용합니다(Edge 런타임 X).패키지 매니저는 pnpm 기..
Data Fetching Pattern 정리Sequential Data Fetching vs Parallel Data Fetching (Server Component 기준)Next.js(App Router)의 Server Component 환경에서는 fetch()를 서버에서 실행할 수 있고, 그 결과를 JSX로 바로 렌더링할 수 있습니다.이때 “여러 데이터를 가져오는 방식”은 크게 두 가지 패턴으로 설명할 수 있습니다.Sequential Data Fetching(순차 요청): A를 받은 후 B를 요청Parallel Data Fetching(병렬 요청): A/B/C를 동시에 요청 후 결과를 모아서 렌더링아래는 jsonplaceholder API를 활용한 실습 예제를 기준으로 각각을 설명합니다.1) Sequ..
Next.js(App Router) 렌더링 완전 정리 (RSC 중심) — Static/Dynamic/Streaming/컴포지션 패턴까지 (v16 기준)이 글은 Next.js App Router(최신 v16 계열) 기준으로, “왜 이 페이지는 즉시 뜨지?”, “어떤 순간에 동적 렌더링이 되지?”, “RSC에서 Client/Server 컴포넌트는 어떻게 섞어야 하지?” 같은 렌더링 관련 핵심을 한 번에 정리한 포스팅입니다.1) RSC(React Server Components) 관점에서 “렌더링”을 다시 보기App Router에서 page / layout은 기본이 Server Component입니다. 즉, “일단 서버에서 렌더링 가능한 건 서버에서” 처리하고, 필요한 부분만 클라이언트로 내려보내는 구조가 기..
Interleaving Server and Client Components (Next.js App Router)App Router에서는 page.tsx, layout.tsx가 기본적으로 Server Component입니다.브라우저 상호작용(상태, 이벤트, 브라우저 API)이 필요할 때만 파일 상단에 'use client'를 붙여 Client Component 경계(boundary) 를 만듭니다.핵심 규칙은 2줄로 요약됩니다.Server Component는 Server/Client를 모두 import 가능Client Component는 Client만 import 가능 (Server import 불가)이 규칙을 바탕으로, 요청하신 4가지 케이스를 정리합니다.1) Client Component 내에서 다른 C..
아래 내용은 Next.js App Router(v15~v16) 기준으로, react-slick 같은 서드파티 UI 패키지를 “클라이언트 라우트(=Client Component 영역)”와 “서버 라우트(=Server Component/Route Handler 영역)”에서 안전하게 쓰는 패턴 + Context Providers까지 한 번에 정리한 글입니다.1) “서드파티 UI 패키지”는 어디에서 써야 하나?App Router에서 page.tsx / layout.tsx는 기본이 Server Component입니다. 서버 컴포넌트는 DB 접근/시크릿 사용/JS 번들 감소/스트리밍에 유리하고, 브라우저 API나 상호작용이 필요하면 Client Component를 섞어서 씁니다. Next.js따라서 서드파티 패키지..
1) Streaming이란?기본 SSR은 “데이터 다 받고 → HTML 만들고 → 내려보내고 → Hydration”이 순차(블로킹) 로 진행돼서, 느린 데이터 하나가 있으면 페이지 전체가 늦어질 수 있습니다. Next.js의 Streaming은 HTML을 작은 청크로 나눠 준비되는 부분부터 점진적으로 전송해, 사용자가 더 빨리 화면을 보기 시작하도록 만드는 방식입니다. Next.jsStreaming은 React의 와 결합되어 “fallback UI를 먼저 보여주고 → 준비되면 교체”하는 흐름으로 동작합니다. Next.js+1또한 App Router에서 페이지/레이아웃은 기본적으로 Server Component이며, 서버에서 렌더링된 결과를 (필요하면 캐시하고) 클라이언트로 스트리밍할 수 있습니다. Ne..
generateStaticParams / dynamicParams 정리 (App Router)1) 언제 필요한가요?App Router에서 폴더명을 대괄호로 감싸면 동적 세그먼트(Dynamic Segment)를 만들 수 있습니다.app/blog/[slug]/page.tsx → /blog/a, /blog/b 처럼 slug가 바뀌는 라우트app/shop/[...slug]/page.tsx → /shop/a/b/c 처럼 catch-all 라우트 (slug는 배열)app/shop/[[...slug]]/page.tsx → /shop도 매칭되는 optional catch-all (slug가 undefined 가능) Next.js문제는 “가능한 slug가 몇 개인지 / 언제 알 수 있는지”입니다.이때 등장하는 것이 ge..
RSC 렌더링과 Static/Dynamic Rendering 정리 (App Router)1) 먼저 용어부터: “RSC”와 “Static/Dynamic”은 다른 축입니다RSC(React Server Components)컴포넌트를 서버에서 실행/렌더링할 수 있게 해주는 React의 컴포넌트 모델입니다. Next.js App Router에서는 page/layout이 기본적으로 Server Component입니다. Next.js+1Static Rendering / Dynamic Rendering“서버에서 렌더링을 언제 하느냐 + 그 결과를 캐시하느냐”의 문제입니다.즉, RSC를 쓰더라도 어떤 라우트는 **정적(빌드/재검증 시점)**으로, 어떤 라우트는 **동적(요청 시점)**으로 동작합니다. Next.js+12..
Next.js v16(App Router 기준) Route definition파일 시스템 기반 라우팅: app/ 아래 폴더 = route segment, URL 경로로 매핑됩니다. Next.js+1해당 세그먼트를 실제로 공개 라우트로 만들려면 보통 그 폴더 안에 page.tsx가 필요합니다(= 그 경로가 “페이지”로 노출). Next.js+1기본 패턴 예:app/page.tsx → /app/profile/page.tsx → /profilePages and layoutspage.tsx: 해당 경로의 화면(페이지) 를 정의합니다. Next.jslayout.tsx: 하위 페이지/레이아웃을 감싸는 공통 UI 쉘입니다(헤더/푸터/사이드바). 네비게이션 시 상태를 유지하며 지속(persist) 됩니다. Next...
1) 개념: “Middleware”와 “Proxy”는 뭐가 다른가요?공통점(역할은 동일)둘 다 요청이 페이지/라우트 핸들러로 도착하기 전에 서버(주로 Edge)에서 먼저 실행되어,redirect / rewrite요청/응답 헤더 수정요청을 차단하고 직접 응답 반환같은 “문지기(게이트)” 역할을 합니다. Next.js차이점(Next.js 16에서 이름/컨벤션이 변경)Next.js 16부터 기존 middleware.ts 파일 컨벤션이 deprecated 되었고, proxy.ts로 이름이 변경되었습니다. (기능이 바뀐 게 아니라 “명명/컨벤션”이 바뀐 것) Next.js+2Next.js+2Next.js 16 블로그에서도 middleware.ts는 당장은 동작하지만 deprecated이며, 미래 버전에서 제거될 ..