From 195e7f8eb426dc8f47e132e68689809b8c3baeaa Mon Sep 17 00:00:00 2001
From: Jiyeon Baek <58380158+100Gyeon@users.noreply.github.com>
Date: Sat, 30 Nov 2024 20:34:35 +0900
Subject: [PATCH 1/5] =?UTF-8?q?docs:=20=EC=B1=95=ED=84=B0=2012=20=EC=B6=94?=
=?UTF-8?q?=EA=B0=80?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
---
.../\353\260\261\354\247\200\354\227\260.md" | 290 ++++++++++++++++++
1 file changed, 290 insertions(+)
create mode 100644 "\354\261\225\355\204\260_12/\353\260\261\354\247\200\354\227\260.md"
diff --git "a/\354\261\225\355\204\260_12/\353\260\261\354\247\200\354\227\260.md" "b/\354\261\225\355\204\260_12/\353\260\261\354\247\200\354\227\260.md"
new file mode 100644
index 0000000..4f87ac0
--- /dev/null
+++ "b/\354\261\225\355\204\260_12/\353\260\261\354\247\200\354\227\260.md"
@@ -0,0 +1,290 @@
+# CHAPTER 12 리액트 디자인 패턴
+
+## 리액트에서 널리 사용되는 디자인 패턴
+
+- [고차 컴포넌트 패턴](#고차-컴포넌트-패턴)
+- [렌더링 Props 패턴](#렌더링-props-패턴)
+- [Hooks 패턴](#hooks-패턴)
+- [정적 가져오기](#정적-가져오기)
+- [동적 가져오기](#동적-가져오기)
+- [코드 스플리팅](#코드-스플리팅)
+- [PRPL 패턴](#PRPL-패턴)
+- [로딩 우선순위](#로딩-우선순위)
+
+## 고차 컴포넌트 패턴
+
+고차 컴포넌트는 **컴포넌트를 인자로 받아 새로운 컴포넌트를 반환**하는 컴포넌트
+즉, 인자로 받은 컴포넌트에 추가 기능을 적용한 컴포넌트를 반환
+
+```javascript
+// 컴포넌트를 인자로 받음
+function withStyles(Component) {
+ return (props) => {
+ const style = { padding: '0.2rem', margin: '1rem' };
+ return <Component style={style} {...props} />; // 새로운 컴포넌트 반환
+ };
+}
+
+const Button = () => <button>Click me!</button>;
+const Text = () => <p>Hello World!</p>;
+
+const StyledButton = withStyles(Button);
+const StyledText = withStyles(Text);
+```
+
+### 목적
+
+여러 컴포넌트에 동일한 로직을 사용하고 싶을 때 사용
+
+### 활용 예시
+
+특정 스타일 적용, 인증 요구, 전역 상태 추가
+
+### 장점
+
+- 로직을 한 곳에 집중시켜 중복 제거
+- 효과적으로 관심사 분리
+
+### 단점
+
+고차 컴포넌트가 대상 컴포넌트에 전달하는 prop의 이름이 일으키는 충돌 → 디버깅과 애플리케이션 확장에 어려움 발생
+
+## 렌더링 Props 패턴
+
+자신의 렌더링 로직을 구현하는 대신, 렌더링 prop을 호출
+렌더링 prop의 이름이 `render`일 필요는 없고, JSX를 렌더링하면 렌더링 prop으로 간주
+
+```javascript
+<Component render={() => <h1>I am a render prop!</h1>} />
+
+<Component render={data => <ChildComponent data={data} />} />
+```
+
+### 장점
+
+고차 컴포넌트 패턴에서 발생할 수 있는 **이름 충돌 문제를 해결** → 어떤 props가 어디에서 오는지 정확하게 파악 가능
+
+### 단점
+
+- 대부분의 경우 렌더링 Props 패턴을 Hooks 패턴으로 대체 가능
+- 라이프사이클 관련 메서드를 추가할 수 없음 → 데이터를 변경하지 않는 렌더링에 치중한 컴포넌트에만 사용 가능
+
+### 상태 끌어올리기
+
+A 컴포넌트와 B 컴포넌트가 상태를 공유하기 위해 **가장 가까운 공통 조상 컴포넌트**로 상태를 끌어올리는 것
+작은 규모의 애플리케이션에서는 전역 상태 관리 라이브러리 대신 이 패턴 사용하는 것만으로도 충분
+하지만 큰 규모라면 상태 끌어올리기가 복잡해지며, 리렌더링으로 인해 성능에 악영향 줄 수 있음
+이때 렌더링 Props 패턴을 사용하면 좋음
+
+```javascript
+function Input(props) {
+ const [value, setValue] = useState('');
+ return (
+ <>
+ <input type="text" value={value} onChange={(e) => setValue(e.target.value)} />
+ // 여기
+ {props.render(value)}
+ </>
+ );
+}
+
+export default function App() {
+ return (
+ <div className="App">
+ <h1>Temperature Converter</h1>
+ <Input
+ // 여기
+ render={(value) => (
+ <>
+ <Kelvin value={value} />
+ <Fahrenheit value={value} />
+ </>
+ )}
+ />
+ </div>
+ );
+}
+```
+
+### 컴포넌트의 자식으로 함수 전달하기
+
+렌더링 Prop으로 전달하는 대신 **컴포넌트의 자식**으로 함수 전달 가능
+
+```javascript
+function Input(props) {
+ const [value, setValue] = useState('');
+ return (
+ <>
+ <input type="text" value={value} onChange={(e) => setValue(e.target.value)} />
+ // 여기
+ {props.children(value)}
+ </>
+ );
+}
+
+export default function App() {
+ return (
+ <div className="App">
+ <h1>Temperature Converter</h1>
+ <Input>
+ // 여기
+ {(value) => (
+ <>
+ <Kelvin value={value} />
+ <Fahrenheit value={value} />
+ </>
+ )}
+ </Input>
+ </div>
+ );
+}
+```
+
+## Hooks 패턴
+
+Hooks를 사용하면 **클래스 컴포넌트를 사용하지 않고도 상태와 라이프사이클 메서드 활용 가능**
+
+### 장점
+
+- 간결한 코드
+- 복잡한 컴포넌트의 단순화
+- 상태 관련 로직 재사용
+- UI에서 분리된 로직 공유
+
+## 정적 가져오기
+
+`import 모듈 from '모듈'`을 사용해 가져오는 모듈은 모두 정적으로 가져온 것
+
+컴포넌트를 정적으로 가져오면 웹팩은 모듈을 초기 번들에 포함시킴
+애플리케이션을 빌드한 후에는 웹팩이 생성한 번들 확인 가능
+
+## 동적 가져오기
+
+모듈이 초기 번들에 불필요하게 포함되어 로딩 시간이 증가하는 문제를 해결하기 위해 컴포넌트를 동적으로 가져올 수 있음
+컴포넌트를 정적으로 가져오는 대신 실제로 필요한 시점에 맞춰 불러오는 것
+리액트의 `Suspense` 컴포넌트로 동적으로 로드할 컴포넌트를 감싸면 된다.
+리액트 18부터 SSR 환경에서도 `Suspense` 사용 가능
+
+### 상호작용 시 가져오기
+
+ex. 채팅 애플리케이션에서 사용자가 이모지를 클릭하면 EmojiPicker 컴포넌트를 동적으로 가져오는 상황
+
+### 화면에 보이는 순간 가져오기
+
+IntersectionObserver API를 사용해 컴포넌트가 화면에 보이는지 확인
+ex. 사용자가 스크롤해야 화면에 나타나는 컴포넌트
+
+## 코드 스플리팅
+
+복잡한 애플리케이션에서는 적절한 시기에 정적/동적 임포트가 가능하도록 코드를 최적으로 스플리팅하고 번들링해야 함
+
+### 경로 기반 분할
+
+때로는 특정 페이지(경로)에서만 필요한 리소스가 있음
+이런 경우 경로별로 컴포넌트를 지연 로딩하면, 현재 경로에 필요한 코드가 포함된 번들만 요청 가능
+
+### 번들 분할
+
+거대한 번들 하나를 요청하는 대신, 여러 개의 작은 번들로 분할하는 방법
+
+#### 장점
+
+- 첫 번째 콘텐츠가 사용자 화면에 표시되는 시간(`FCP`) 단축
+- 가장 큰 콘텐츠가 화면에 렌더링되는 시간(`LCP`) 개선
+- 모든 콘텐츠가 화면에 표시되고 인터랙티브해지는 데 걸리는 시간(`TTI`) 개선
+
+## PRPL 패턴
+
+저사양 기기나 인터넷 연결이 불안정한 지역에서도 애플리케이션이 원활하게 작동해야 함
+어떤 환경에서도 애플리케이션이 최대한 효율적으로 로드될 수 있도록 PRPL 패턴 사용
+
+4가지 핵심 성능 고려사항에 중점
+
+- `Push` : 중요한 리소스를 효율적으로 푸시해 서버 왕복 횟수를 최소화하고 로딩 시간 단축
+- `Render` : 초기 경로를 최대한 빠르게 렌더링해 UX 개선
+- `Pre-cache` : 자주 방문하는 경로의 에셋을 백그라운드에서 미리 캐싱해 서버 요청 횟수 줄이고 더 나은 오프라인 경험 제공
+- `Lazy-load` : 자주 요청되지 않는 경로나 에셋은 지연 로딩
+
+>
+
+## 로딩 우선순위
+
+`preload`는 브라우저의 최적화 기능으로, **중요한 리소스를 더 일찍 요청** 가능
+로딩 순서를 지정하면 Core Web Vitals의 로딩 성능 및 지표에 긍정적인 영향 미침
+
+`TTI` 또는 `FID`를 최적화할 때 유용
+상호작용에 필요한 리소스를 먼저 로딩하다가
+`FCP`, `LCP`에 필요한 리소스(ex. 폰트, 히어로 이미지)의 로딩이 지연되지 않도록 주의해야 함
+
+자바스크립트 자체의 로딩을 최적화하려면, `<body>` 태그보다는 `<head>` 태그 안에서 `<script defer>`를 사용하는 게 좋음
+
+### SPA의 Preload
+
+#### `prefetching`
+
+- 앞으로 사용될 가능성이 높은 리소스를 미리 가져와 캐시에 저장하는 방식
+- 브라우저가 인터넷 연결 상태와 대역폭을 고려해 어떤 리소스 미리 가져올지 결정
+
+#### `preload`
+
+- **즉시** 사용해야 하는 리소스 (ex. 초기 렌더링에 사용되는 특정 폰트나 접속 시 바로 보이는 히어로 이미지 등)
+- **어떤 상황에서든 무조건 미리 로드**
+- 초기 렌더링 후 약 1초 이내에 표시되어야 하는 리소스만 선별해 미리 로드하는 것이 좋음
+
+### Preload + async 기법
+
+브라우저가 스크립트를 높은 우선순위로 다운로드하면서도, 스크립트를 기다리는 동안 파싱이 멈추지 않도록 하기 위한 기법
+
+```html
+<link rel="preload" href="emoji-picker.js" as="script" />
+<script src="emoji-picker.js" async></script>
+```
+
+### 크롬 95+ 버전에서의 Preload
+
+크롬 95+ 버전에서는 preload의 queue-jumping 동작이 개선되어 preload 기능이 더 안전해짐
+
+> queue-jumping이란?
+> 브라우저는 리소스를 요청할 때 queue에 쌓아서 순차적으로 처리합니다.
+> 기본적으로 브라우저는 HTML 파일을 읽고, 필요한 스크립트나 스타일시트를 순서대로 로드합니다.
+> 하지만 preload를 사용하면, 중요한 리소스를 우선적으로 로드하도록 **큐에서 뛰어넘을 수 있습니다**.
+
+## 리스트 가상화
+
+대규모 데이터 리스트의 렌더링 성능을 향상시키는 기술
+현재 화면에 보이는 행만 동적으로 렌더링
+`react-virtualized` 같은 라이브러리를 사용하여 구현
+스크롤되는 뷰포트 내에서 현재 보이는 항목만 렌더링하므로, 한 번에 수천 개의 행 데이터를 렌더링하는 데 드는 리소스를 절약
+
+### 윈도잉/가상화의 작동 방식
+
+`react-virtualized`에서의 작동 방식
+
+https://github.com/user-attachments/assets/c4afb058-8c99-4adb-8a04-1a99cc89949f
+
+윈도잉이 동작하기 위해 필요한 요소
+
+- 스크롤을 위한 큰 DOM 요소
+- `position： relative`를 가지는 작은 컨테이너 DQM 요소 (영상에서 ul에 해당)
+- 컨테이너 내부에 위치하고 `position： absolute`이며 `top`, `left`, `width`, `height` 등을 설정한 자식 요소들
+
+[react-window](https://github.com/bvaughn/react-window)는 [react-virtualized](https://github.com/bvaughn/react-virtualized) 개발자 Brian Vaughn이 다시 만든 라이브러리
+smaller, faster, more tree-shakeable, beginner-friendly
+
+> 두 라이브러리가 어떻게 다른지 개발자가 직접 설명한 [글](https://github.com/bvaughn/react-window#how-is-react-window-different-from-react-virtualized)이 있네요 (둘 중에는 react-window를 사용하라고 권장하고 있습니다)
+>
+> 토스증권에서는 `react-virtuoso`, `@tanstack/react-virtual`을 상황에 맞게 사용 중이라고 해요
+> `react-virtuoso`는 선언적이고, `@tanstack/react-virtual`은 headless라서 커스텀 하기 좋다고 합니다
+>
+> https://npmtrends.com/@tanstack/react-virtual-vs-react-virtualized-vs-react-virtuoso-vs-react-window
+> 4가지를 같이 비교해 보니, 확실히 `react-virtuoso`, `@tanstack/react-virtual`이 가볍긴 하네요
+> 
+
+### 웹 플랫폼의 발전
+
+`content-visibility: auto`를 설정하면 화면 밖 콘텐츠의 렌더링과 페인팅을 필요한 시점까지 지연할 수 있음
+렌더링 비용이 큰 HTML 문서에 적용하면 좋음
+동적인 콘텐츠 목록을 렌더링하는 경우에는 `react-window` 같은 라이브러리 사용하는 게 좋음
+
+> https://developer.mozilla.org/en-US/docs/Web/CSS/content-visibility
+> [(번역) CSS content-visibility를 이용해 렌더링 성능 향상 시키기](https://velog.io/@superlipbalm/improving-rendering-performance-with-css-content-visibility)
From fc97aaed217dbd086e9ef0f6572df8288df3d89b Mon Sep 17 00:00:00 2001
From: Jiyeon Baek <58380158+100Gyeon@users.noreply.github.com>
Date: Sat, 30 Nov 2024 20:40:52 +0900
Subject: [PATCH 2/5] =?UTF-8?q?chore:=20=EB=B6=88=ED=95=84=EC=9A=94?=
=?UTF-8?q?=ED=95=9C=20=EB=9D=BC=EC=9D=B8=20=EC=A0=9C=EA=B1=B0?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
---
.../\353\260\261\354\247\200\354\227\260.md" | 2 --
1 file changed, 2 deletions(-)
diff --git "a/\354\261\225\355\204\260_12/\353\260\261\354\247\200\354\227\260.md" "b/\354\261\225\355\204\260_12/\353\260\261\354\247\200\354\227\260.md"
index 4f87ac0..655a30b 100644
--- "a/\354\261\225\355\204\260_12/\353\260\261\354\247\200\354\227\260.md"
+++ "b/\354\261\225\355\204\260_12/\353\260\261\354\247\200\354\227\260.md"
@@ -205,8 +205,6 @@ ex. 사용자가 스크롤해야 화면에 나타나는 컴포넌트
- `Pre-cache` : 자주 방문하는 경로의 에셋을 백그라운드에서 미리 캐싱해 서버 요청 횟수 줄이고 더 나은 오프라인 경험 제공
- `Lazy-load` : 자주 요청되지 않는 경로나 에셋은 지연 로딩
->
-
## 로딩 우선순위
`preload`는 브라우저의 최적화 기능으로, **중요한 리소스를 더 일찍 요청** 가능
From e545ca401a2fae34948db9b248a152c82f62e7e5 Mon Sep 17 00:00:00 2001
From: Jiyeon Baek <58380158+100Gyeon@users.noreply.github.com>
Date: Sun, 1 Dec 2024 17:26:34 +0900
Subject: [PATCH 3/5] =?UTF-8?q?=08docs:=20=EC=B1=95=ED=84=B0=2013=20?=
=?UTF-8?q?=EC=B6=94=EA=B0=80?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
---
.../\353\260\261\354\247\200\354\227\260.md" | 147 ++++++++++++++++++
1 file changed, 147 insertions(+)
create mode 100644 "\354\261\225\355\204\260_13/\353\260\261\354\247\200\354\227\260.md"
diff --git "a/\354\261\225\355\204\260_13/\353\260\261\354\247\200\354\227\260.md" "b/\354\261\225\355\204\260_13/\353\260\261\354\247\200\354\227\260.md"
new file mode 100644
index 0000000..02c86cc
--- /dev/null
+++ "b/\354\261\225\355\204\260_13/\353\260\261\354\247\200\354\227\260.md"
@@ -0,0 +1,147 @@
+# CHAPTER 13 렌더링 패턴
+
+## 렌더링 패턴의 중요성
+
+크롬 팀은 페이지 전체를 하이드레이션 하는 방식보다 정적 렌더링 또는 SSR 사용을 권장
+
+## 클라이언트 사이드 렌더링(CSR)
+
+거의 모든 UI가 클라이언트에서 생성되고, 처음 요청 시에 전체 웹 애플리케이션 모두 로드
+페이지의 복잡성이 증가하면 페이지 렌더링에 필요한 자바스크립트 코드의 복잡성과 크기도 증가
+크롤러가 색인하기 전에 의미 있는 콘텐츠가 시간에 맞춰 렌더링되지 않을 수 있어 SEO에 불리
+
+## 서버 사이드 렌더링(SSR)
+
+모든 요청마다 HTML 생성
+데이터 fetching을 위한 추가적인 왕복 시간을 줄일 수 있음
+HTML을 서버에서 렌더링하고 클라이언트에서 다시 하이드레이션하는 데 필요한 자바스크립트를 함께 제공하는 것이 핵심
+하이드레이션에는 비용이 따르기 때문에 SSR은 하이드레이션 과정을 최적화하려고 함
+
+### 적합한 경우
+
+- 사용자 쿠키 정보나 요청 데이터를 기반으로 하는 등 **개인 맞춤형 데이터를 포함하는 페이지**
+- 인증 상태에 따라 렌더링 여부를 결정해야 하는 페이지
+- 개인화된 대시보드
+
+## 정적 렌더링
+
+전체 페이지의 HTML을 빌드 시점에 미리 생성해 다음 빌드 때까지 변경되지 않는 것
+정적인 HTML 콘텐츠는 CDN이나 엣지 네트워크에 쉽게 캐싱됨
+
+### 적합한 경우
+
+- **자주 변경되지 않고, 누가 요청하든 동일한 데이터를 표시하는 페이지**
+- 회사 소개, 문의하기, 블로그 페이지
+- 전자상거래 애플리케이션의 상품 페이지
+
+### Next.js도 정적 생성을 지원하는 프레임워크 중 하나
+
+#### 리스트 페이지 정적 생성
+
+- Pages Router : `getStaticProps()`
+- App Router : `fetch`의 `cache` 옵션
+
+#### 동적 경로를 사용한 상세 페이지 정적 생성
+
+- Pages Router : `getStaticPaths()`
+- App Router : `generateStaticParams()`
+
+#### 클라이언트 사이드 데이터 fetching을 통한 정적 렌더링 (항상 최신 목록을 표시해야 하는 동적인 리스트 페이지)
+
+웹사이트의 UI를 Skeleton 컴포넌트와 함께 정적으로 렌더링
+동적 목록 데이터를 배치할 위치를 미리 지정
+페이지가 로드된 후 SWR`/`Tanstack Query를 사용해 데이터를 가져옴
+
+### 점진적 정적 생성(ISR)
+
+**SSR + 정적 렌더링 = ISR**
+
+특정 정적 페이지만 미리 렌더링하고, 동적 페이지는 사용자 요청 시에 on-demand 방식으로 렌더링 → 빌드 시간 단축
+**특정 간격마다 캐시를 자동으로 무효화하고 페이지 다시 생성**
+`Stale-While-Revalidate` 전략을 사용해 백그라운드에서 재검증하는 동안 사용자는 캐시된 버전을 봄
+
+### On-demand ISR
+
+|일반 ISR|On-demand ISR|
+|:-:|:-:|
+|정해진 시간 간격마다 페이지 재생성|특정 이벤트 발생 시에 페이지 재생성|
+|요청을 처리한 엣지 네트워크 노드에만 업데이트된 페이지 캐시|엣지 네트워크 전체에 페이지 재생성, 재분배(모든 사용자가 최신 버전 확인)|
+
+### 정적 렌더링 요약
+
+- 순수 정적 렌더링 : **동적인 데이터가 없는** 페이지에 적합
+- 클라이언트 사이드 데이터 fetching을 통한 정적 렌더링 : **로드 시마다 데이터가 새로고침**되어야 하고, **placeholder**를 가진 페이지에 적합
+- 점진적 정적 생성(ISR): **특정 간격** 또는 필요에 따라 재생성되어야 하는 페이지에 적합
+- On-demand ISR : **특정 이벤트 발생** 시 재생성되어야 하는 페이지에 적합
+
+## 스트리밍 SSR
+
+SSR이나 정적 렌더링을 사용하는 것보다 **TTI, FCP 단축 가능**
+현재 페이지에 필요한 마크업을 모두 담은 HTML 하나를 생성하는 대신, **chunk로 나눠서 전송**
+리액트에 내장된 `renderToNodeStream` 함수를 사용하면 애플리케이션을 작은 조각으로 나눠서 전송 가능
+클라이언트는 **데이터를 받는 동시에 UI를 그리기 시작**할 수 있어 **매우 빠른 초기 로딩 경험 제공**
+이렇게 수신된 DOM 노드에 `hydrate` 메서드를 호출하면, 이벤트 핸들러가 연결되어 상호작용 가능
+
+## 엣지 SSR
+
+CDN의 모든 지역에서 서버 렌더링 가능, 거의 0에 가까운 콜드 부트 시간(함수가 처음 실행될 때 발생하는 지연 시간)
+
+### 활용 사례
+
+ex. 지역 특화 리스트 페이지
+리스트만 외부 요청, 페이지 대부분은 정적 데이터로 구성
+리스트 컴포넌트만 서버 사이드 렌더링, 나머지는 엣지 사이드에서 렌더링
+
+## 하이브리드 렌더링
+
+어떤 상황에서든 최적의 결과를 제공하기 위해 여러 가지 렌더링 방식 결합
+Next.js는 리액트 서버 컴포넌트와 App Router를 결합해 하이브리드 렌더링 지원
+
+## 점진적 하이드레이션
+
+**각 노드를 시간에 따라 개별적으로 하이드레이션하여 필요한 최소한의 JS만 요청하는 방식**
+페이지에서 덜 중요한 부분의 하이드레이션을 지연시켜 JS 양을 줄이고, 사용자에게 필요한 노드만 하이드레이션
+서버에서 렌더링된 DOM 트리가 파괴되고 즉시 다시 생성되는 SSR의 문제 방지할 수 있음
+애플리케이션을 여러 조각으로 나누어 뛰어난 성능을 제공하는 것을 목표로 함
+
+### 완전한 점진적 하이드레이션을 위한 요구사항
+
+- 모든 컴포넌트에 SSR 사용 가능
+- 개별 컴포넌트 또는 조각 단위로 코드 스플리팅 지원
+- 개발자가 정의한 순서대로 클라이언트 사이드에서 각 조각 별 하이드레이션 지원
+- 이미 하이드레이션된 조각에서 사용자 입력 가능 상태 유지
+- 지연된 하이드레이션이 적용되는 조각에 로딩 중임을 표시 가능
+
+리액트의 동시성 모드(concurrent mode) 기능 덕분에 요구사항 충족
+동시성 모드 = 여러 작업을 동시에 처리하면서도, 우선순위에 따라 작업 전환 가능
+
+## 아일랜드 아키텍처
+
+정적인 HTML 위에 독립적으로 전달될 수 있는 상호작용 아일랜드를 통해 JS 전송량을 줄이는 패러다임
+컴포넌트 기반 아키텍처
+정적/동적 아일랜드로 구분된 페이지 뷰 제안
+정적 콘텐츠로 이루어진 페이지의 SSR 지원
+
+|점진적 하이드레이션|아일랜드 아키텍처|
+|:-:|:-:|
+|하향식 하이드레이션 구조|각 컴포넌트가 자체적으로 하이드레이션 스크립트 가짐|
+|페이지가 개별 컴포넌트의 스케줄링 및 하이드레이션 제어|하이드레이션 스크립트는 페이지의 다른 스크립트와 독립적으로 비동기 실행|
+
+### 장점
+
+- 성능 : JS 코드의 양이 감소해 페이지 로드 속도 빨라짐
+- SEO : 모든 정적 콘텐츠가 서버에서 렌더링되므로 SEO에 유리
+- 중요 콘텐츠 우선순위
+- 접근성
+- 컴포넌트 기반
+
+### 단점
+
+- 아직 초기 단계라서 사용 가능한 프레임워크가 적고, 직접 아키텍처 개발해야 함
+- 소셜 미디어 애플리케이션처럼 상호작용을 위주로 한 페이지에는 적합하지 않음 (수천 개의 아일랜드가 필요할 수 있음)
+
+## 리액트 서버 컴포넌트
+
+서버에서 실행되도록 설계된 컴포넌트로, 상태를 가지지 않음
+RSC는 번들 크기를 0으로 줄임 → 결과적으로 클라이언트 사이드 JS 번들 크기 감소
+서버 컴포넌트와 클라이언트 컴포넌트 사이의 매끄러운 코드 전환 경험(knitting) 가능
From 668460289915d50a3893c66663b328d7f41c233f Mon Sep 17 00:00:00 2001
From: Jiyeon Baek <58380158+100Gyeon@users.noreply.github.com>
Date: Mon, 2 Dec 2024 00:29:35 +0900
Subject: [PATCH 4/5] =?UTF-8?q?chore:=20=EB=82=B4=EC=9A=A9=20=EC=88=98?=
=?UTF-8?q?=EC=A0=95?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
---
.../\353\260\261\354\247\200\354\227\260.md" | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git "a/\354\261\225\355\204\260_13/\353\260\261\354\247\200\354\227\260.md" "b/\354\261\225\355\204\260_13/\353\260\261\354\247\200\354\227\260.md"
index 02c86cc..7ad9d9b 100644
--- "a/\354\261\225\355\204\260_13/\353\260\261\354\247\200\354\227\260.md"
+++ "b/\354\261\225\355\204\260_13/\353\260\261\354\247\200\354\227\260.md"
@@ -50,7 +50,7 @@ HTML을 서버에서 렌더링하고 클라이언트에서 다시 하이드레
웹사이트의 UI를 Skeleton 컴포넌트와 함께 정적으로 렌더링
동적 목록 데이터를 배치할 위치를 미리 지정
-페이지가 로드된 후 SWR`/`Tanstack Query를 사용해 데이터를 가져옴
+페이지가 로드된 후 SWR/Tanstack Query를 사용해 데이터를 가져옴
### 점진적 정적 생성(ISR)
@@ -81,6 +81,9 @@ SSR이나 정적 렌더링을 사용하는 것보다 **TTI, FCP 단축 가능**
리액트에 내장된 `renderToNodeStream` 함수를 사용하면 애플리케이션을 작은 조각으로 나눠서 전송 가능
클라이언트는 **데이터를 받는 동시에 UI를 그리기 시작**할 수 있어 **매우 빠른 초기 로딩 경험 제공**
이렇게 수신된 DOM 노드에 `hydrate` 메서드를 호출하면, 이벤트 핸들러가 연결되어 상호작용 가능
+
+> 당근 테크 밋업에서 스트리밍 SSR을 다룬 [세션](https://youtu.be/4UD4EB00AME?si=Z4GeG2fkOuv0obqB&t=905)이 있었어요👍
+> 제가 정리한 [글](https://blog.100jiyeon.xyz/posts/daangn-tech-meetup-2024#%EC%A7%81%EC%A0%91-%EA%B5%AC%EC%B6%95%ED%95%9C-ssr-webapp)과 같이 공유해 봅니다
## 엣지 SSR
From f873de2f7b3d38becc80dd70deba7592d6bd2ace Mon Sep 17 00:00:00 2001
From: Jiyeon Baek <58380158+100Gyeon@users.noreply.github.com>
Date: Mon, 2 Dec 2024 00:41:22 +0900
Subject: [PATCH 5/5] =?UTF-8?q?fix:=20ISR=20=EB=82=B4=EC=9A=A9=20=EC=88=98?=
=?UTF-8?q?=EC=A0=95=20=EB=B0=8F=20=EB=B3=B4=EC=99=84?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
---
.../\353\260\261\354\247\200\354\227\260.md" | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git "a/\354\261\225\355\204\260_13/\353\260\261\354\247\200\354\227\260.md" "b/\354\261\225\355\204\260_13/\353\260\261\354\247\200\354\227\260.md"
index 7ad9d9b..81e0465 100644
--- "a/\354\261\225\355\204\260_13/\353\260\261\354\247\200\354\227\260.md"
+++ "b/\354\261\225\355\204\260_13/\353\260\261\354\247\200\354\227\260.md"
@@ -54,7 +54,23 @@ HTML을 서버에서 렌더링하고 클라이언트에서 다시 하이드레
### 점진적 정적 생성(ISR)
-**SSR + 정적 렌더링 = ISR**
+**SSG + revalidate = ISR**
+
+```javascript
+// getStaticProps 함수에서 revalidate 옵션을 설정하여 ISR을 통해 페이지 재생성 주기를 지정합니다.
+// 이 주기 동안은 캐시된 페이지가 제공되며, 이후에만 새로운 데이터로 재생성됩니다.
+export async function getStaticProps() {
+ // 데이터 가져오기
+ const data = ...;
+
+ return {
+ props: {
+ data,
+ },
+ revalidate: 60, // ISR을 통한 재생성 주기 (초 단위)
+ };
+}
+```
특정 정적 페이지만 미리 렌더링하고, 동적 페이지는 사용자 요청 시에 on-demand 방식으로 렌더링 → 빌드 시간 단축
**특정 간격마다 캐시를 자동으로 무효화하고 페이지 다시 생성**