Skip to content

Commit da2f317

Browse files
hyesungohhyesungoh
authored
[오혜성] 챕터 12, 13 (#103)
* 12 정리 * 일단 추가
1 parent 0101e98 commit da2f317

File tree

2 files changed

+226
-0
lines changed

2 files changed

+226
-0
lines changed

‎챕터_12/오혜성.md‎

Lines changed: 179 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,179 @@
1+
# 리액트 디자인 패턴
2+
3+
## 리액트 소개
4+
5+
제곧내
6+
7+
## 고차 컴포넌트
8+
9+
- 장점
10+
- 재사용하고자 하는 로직을 한 곳에 모아 관리
11+
- 관심사
12+
- 단점
13+
- props에 대한 핸들링 (블랙박스)
14+
- 파악하기 어려워짐
15+
16+
> hook이나 후술하는 렌더링 프롭 등 대체 가능한 패턴이 많다고 생각됨
17+
> 고차 컴포넌트가 핏한 해결 방법인 경험이 없음
18+
19+
## 렌더링 Props 패턴
20+
21+
```js
22+
function Compo() {
23+
return (
24+
<RenderPropCompo>
25+
{value => <div>{value}</div>}
26+
</RenderPropCompo>
27+
);
28+
}
29+
```
30+
31+
- 장점
32+
- 여러 컴포넌트 사이에서 로직과 데이터를 쉽게 공유 (재사용성)
33+
- 단점
34+
- hook으로 대체 가능
35+
> 코드의 추상화 수준이 좀 높아질 수 있다? 단점은 아니겠지만 ..
36+
37+
## Hooks
38+
39+
알잘딱
40+
41+
## 동적 가져오기
42+
43+
### 로더블 컴포넌트
44+
45+
서버 사이드의 Suspense의 대안
46+
https://www.npmjs.com/package/@loadable/component
47+
48+
> 생각보다 다운로드 수가 높네용
49+
50+
> 18 이후부터 서버 사이드에서도 Suspense 동작
51+
> > 그럼에도 클라이언트에서만 하고 싶다면 https://suspensive.org/ko/docs/react/Suspense#%EC%84%9C%EB%B2%84%EC%82%AC%EC%9D%B4%EB%93%9C-%EB%A0%8C%EB%8D%94%EB%A7%81%EC%9D%84-%ED%94%BC%ED%95%98%EA%B8%B0-clientonly
52+
53+
## PRPL 패턴
54+
55+
- Push Render Pre-cache Lazy-load
56+
57+
- Push
58+
- 중요한 리소스를 효율적으로 푸시, 서버 왕복 횟수를 최소화해 로딩 시간을 단축
59+
- Render
60+
- 초기 경로를 최대한 빠르게 렌더링
61+
- Pre-cache
62+
- 자주 방문하는 경로의 에셋을 백그라운드에서 미리 캐싱
63+
- Lazy-load
64+
- 자주 요청되지 않는 것은 지연 로딩
65+
66+
### HTTP
67+
68+
- HTTP/1.1은 keep-alive 헤더를 통해 새로운 요청 전송 전까지 클라이언트와 서버 간의 TCP 연결을 유지하는 등 1.0에 비해 많은 개선점을 도입
69+
70+
- HTTP/1.1은 클라이언트와 서버 간 최대 6개의 TCP 연결만 가능했음
71+
- 그래서 마지막 요청이 오래 걸리면, 다른 요청을 전송할 수 없어 HOL Blocking이 발생해 로딩 시간을 증가시킬 수 있음
72+
- Head-of-line Blocking
73+
74+
- HTTP/2는 양방향 스트림을 사용
75+
- 단일 TCP 연결을 통해 여러 개의 양방향 스트림을 만들어 클라이언트와 서버 간에 여러 개의 요청 및 응답 프레임을 동시에 전달할 수 있음
76+
77+
- HTTP/2는 서버 푸시라는 데이터 가져오기 방식을 도입
78+
- 매번 명시적으로 리소스를 요청하지 않고, 이런 리소스를 푸시하여 자동으로 추가 리소스를 전송할 수 있게 됨
79+
> 이게 먼소리여
80+
81+
```md
82+
HTTP/1.1 (기존 방식)
83+
84+
1. 피자를 주문합니다
85+
2. 피자가 도착합니다
86+
3. 피자를 보니 콜라가 필요해서 다시 주문합니다
87+
4. 콜라가 도착합니다
88+
5. 그러다 치킨 윙이 먹고 싶어서 또 주문합니다
89+
6. 치킨 윙이 도착합니다
90+
91+
이렇게 매번 필요한 것이 생길 때마다 새로운 주문을 해야 했습니다.
92+
93+
HTTP/2 서버 푸시 (새로운 방식)
94+
95+
1. 피자를 주문합니다
96+
2. 가게에서는 "아! 손님들이 보통 피자랑 콜라랑 치킨 윙을 같이 시키시더라"라고 생각하고
97+
3. 피자와 함께 콜라와 치킨 윙도 미리 보내줍니다
98+
99+
즉, 서버 푸시는 웹사이트가 "이 사용자가 곧 필요할 것 같은 파일들"을 미리 보내주는 똑똑한 시스템입니다. 예를 들어:
100+
101+
- 웹페이지를 요청하면
102+
- HTML 파일과 함께
103+
- 곧 필요할 CSS, 이미지, JavaScript 파일들도 자동으로 보내줍니다
104+
105+
이렇게 하면 사용자가 일일이 요청하지 않아도 되니까 웹사이트 로딩이 더 빨라지죠! 🚀
106+
107+
> 이해 완
108+
```
109+
110+
- 서버 푸시는 HTTP 캐시를 인지하지 못함
111+
- 그래서 웹사이트 재방문 시에는 사용할 수 없음
112+
- 이를 위해 초기 로드 이후에 서비스 워커를 사용하여 해당 리소스를 캐시함으로써 클라이언트가 불필요한 요청을 하지 않도록 함
113+
114+
```md
115+
116+
1. HTTP 캐시와 서버 푸시의 관계
117+
118+
중학생 철수가 문방구에서 장난감을 사는 상황으로 비유해볼게요:
119+
첫 방문 시:
120+
철수: "로봇 장난감 하나 주세요!"
121+
문방구 아저씨: "여기 로봇이요! 아, 그리고 보통 애들이 건전지랑 스티커도 같이 사니까 이것도 드릴게요!" (서버 푸시)
122+
123+
재방문 시:
124+
철수: "어제 산 로봇이랑 똑같은 거 주세요!"
125+
문방구 아저씨: "어! 철수야, 너 이미 건전지랑 스티커 있을 텐데... 근데 난 그걸 모르니까 또 줘버렸네..."
126+
127+
2. 왜 서비스 워커가 필요할까?
128+
129+
서비스 워커는 마치 철수의 '장난감 노트'같은 거예요:
130+
📝 철수의 장난감 노트 (서비스 워커)
131+
- 로봇 장난감 ✅
132+
- 건전지 ✅
133+
- 스티커 ✅
134+
135+
이제 철수가 다시 문방구에 갈 때:
136+
137+
노트를 먼저 확인해서 "아, 이미 있는 거네!"
138+
필요한 것만 달라고 할 수 있어요
139+
140+
정리하면:
141+
HTTP 서버 푸시는 사용자의 브라우저에 뭐가 있는지 모르고 무조건 다 보내요 (비효율적)
142+
서비스 워커는 브라우저에 뭐가 있는지 기록해두고, 필요한 것만 요청할 수 있게 해줘요 (효율적)
143+
이렇게 서비스 워커가 똑똑한 메모장 역할을 해서, 불필요한 데이터를 또 받지 않아도 되는 거예요! 🎯
144+
145+
> 개쩐다
146+
```
147+
148+
> 저자가 브라우저 개발자라 그런지 이런건 빠삭한 느낌..?
149+
150+
## 로딩 우선순위
151+
152+
- 에셋은 `rel='preload'`
153+
- 자바스크립트 자체의 로딩을 최적화 -> `<head>` 안에 `<script defer>`
154+
155+
### SPA의 Preload
156+
157+
- 웹팩의 경우 특수 주석을 추가해 모듈을 프리로드 해야 함을 알릴 수 있음
158+
159+
```js
160+
const Foo = import(/* webpackPreload: true */ './Foo');
161+
```
162+
163+
- 초기 렌더링 이후 1초 이내에 표시되어야 하는 리소스만 선별해 미리 로드하는게 좋다
164+
165+
### 크롬 95+ 에서의 Preload
166+
167+
- 큐 점핑 동작이 개선되어 프리로드가 더 안전해짐
168+
> 대충 폰트, 모듈, 이미지 프리로드를 알잘딱 한다는건가
169+
170+
## 리스트 가상화
171+
172+
- 보이는 것만 렌더링해 성능 저하를 막음
173+
174+
- react-window
175+
- react-virtualized 개발자가 더 작고 빠르게, 트리쉐이킹에 더 적합하게 다시 만든 라이브러리
176+
177+
- content-visibility 속성
178+
- 렌더링과 페인팅을 필요한 시점까지 지연할 수 있음
179+
- 동적인 콘텐츠 목록의 경우 여전히 위 라이브러리가 효과적

‎챕터_13/오혜성.md‎

Lines changed: 47 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,47 @@
1+
# 렌더링 패턴
2+
3+
## CSR
4+
5+
- 클라이언트에서 완전히 렌더링
6+
7+
## SSR
8+
9+
- 서버에서 동적으로 렌더링 후, 클라이언트에서 하이드레이션
10+
11+
## 정적 렌더링
12+
13+
- 빌드 타임에 서버에서 페이지를 렌더링
14+
15+
## 점진적 정적 생성 (ISR)
16+
17+
- 초기 빌드 이후에도 정적 사이트를 동적으로 추가하거나 수정할 수 있음
18+
19+
20+
## 스트리밍 SSR
21+
22+
- 서버에서 렌더링퇸 콘텐츠를 더 작은 스트림 조각으로 분할하여 전송
23+
24+
## 엣지 렌더링
25+
26+
- 렌더링된 HTML을 클라이언트에 전송하기 전에 엣지에서 수정
27+
28+
## 하이브리드 렌더링
29+
30+
- 빌드 타임, 서버 및 클라이언트 렌더링을 결합하여 유연한 접근 방법 제공
31+
- App router
32+
33+
## 부분 하이드레이션
34+
35+
- 클라이언트에서 일부 컴포넌트만 하이드레이션
36+
37+
## 점진적 하이드레이션
38+
39+
- 클라이언트에서 컴포넌트 하이드레이션 순서를 제어
40+
41+
## 아일랜드 아키텍처
42+
43+
- 정적 사이트 내에 여러 진입점을 가진 도엊ㄱ인 동작의 격리된 영역을 만듬
44+
45+
## 점진적 향상
46+
47+
- 자바스크립트 없이도 애플리케이션이 작동하도록 보장

0 commit comments

Comments
 (0)