hyeok999-chapter03~04, 11

chapter03/hyeok999.md

@@ -0,0 +1,49 @@
+# 03장: 리액트 훅
+
+<br>
+
+## 3.1.1 `useState`
+
+```jsx
+const [현재 상태, value를 업데이트하는 함수] = useState(초기값);
+```
+
+### 게으른 초기화(lazy initialization)
+
+> 컴포넌트의 상태를 초기화할 때 초기 상태 계산이 복잡하거나 계산 비용이 높을 경우에 사용되는 기법
+> 함수를 인수로 쓰는 경우.
+
+ 로컬 스토리지, 세션 스토리지의 접근과 map, filter, find 같은 배열의 접근, 초깃값 계산으로 함수 호출 시, 무거운 연산을 포함한 실행 비용이 많이 드는 경우 사용
+
+## 3.1.2 `useEffect`
+
+**`clean-up function`**:
+
+- **이전 상태를 청소해 주는 개념** (unMount 개념이라고 생각했는데, 그게 아니였음.)
+- 이 클린업 함수는 훅에서 생성된 리소스나 효과를 정리하는 데 사용
+- API에서 데이터를 가져오거나 이벤트 리스너를 설정하거나 간격이나 타임아웃을 생성하는 등의 부작용 정리
+- 부수 효과가 클 수록 성능에 악영향을 미칠 수 있으므로 큰 `useEffect` 보다는 여러 개의 `useEffect`로 분리하고 의존성 배열을 나눠 갖기.
+
+## 3.1.3 `useMemo`
+
+- 값 메모라이제이션
+
+## 3.1.4 `useCallback`
+
+- 함수 메모라이제이션
+
+## 3.1.5 `useRef`
+
+- 변경 가능한 값을 유지하는데 사용
+- 값이 변해도 리렌더링하지 않음
+
+## 3.1.6 `useContext`
+
+- 전역으로 상태 접근할 때 사용
+
+## 3.1.7 `useReducer`
+
+- 인자1: reducer — 상태 갱신을 처리.
+- 인자2: initialState — 초기 상태 값.
+- 인자3: initializer — 초기 상태를 설정하는 함수. 옵셔널
+

chapter04/hyeok999.md

@@ -0,0 +1,39 @@
+# 04장: 서버 사이드 렌더링
+
+<br>
+
+## 서버 사이드 렌더링이란?
+
+### SPA와 SSR을 모두 알아야 하는 이유
+
+- 서버 사이드 렌더링 역시 만능이 아니다
+- 성능 수준 : 매우 최적화 잘 된 SPA > 매우 최적화 잘 된 MPA > 애매한 MPA > 애매한 SPA 
+
+<br>
+
+## 4.2 서버 사이드 렌더링을 위한 리액트 API 살펴보기
+
+### 4.2.1 renderToString
+
+- 리액트 컴포넌트를 렌더링하고 HTML 문자열을 생성
+- root에 `data-react` 속성을 제공. 즉, `hydrate`가 가능.
+
+### 4.2.2 renderToStaticMarkup
+
+- root에 `data-react` 속성을 제공하지 않음. 즉, `hydrate`가 불가능.
+- 리액트 컴포넌트를 렌더링하고 HTML 문자열을 생성
+
+### 4.2.3 renderToNodeStream
+
+- return 타입 : Node.js의 ReadableStream
+- 브라우저가 아닌 서버에서 사용 
+
+### 4.2.4 renderToStaticNodeStream
+
+- return 타입 : Node.js의 ReadableStream
+- 브라우저가 아닌 서버에서 사용.
+- hydrate 가 불가능
+
+### 4.2.5 hydrate
+
+-  `renderToString`과 `renderToNodeStream`으로 생성된 HTML 콘텐츠에 자바스크립트 핸들러나 이벤트를 붙이는 역할 제공.

chapter11/hyeok999.md

@@ -0,0 +1,59 @@
+# 11장 Next 13과 리액트 18
+
+## Next.js에서의 리액트 서버 컴포넌트 
+
+### 기존 리액트 컴포넌트와 서버 사이드 렌더링
+
+- 리액트의 모든 컴포넌트는 클라이언트에서 작동하고 브라우저에서 자바스크립트 코드 처리.
+- 웹 사이트를 방문하면 리액트 실행에 필요한 코드를 다운로드하고 리액트 컴포넌트 트리를 만든 후 DOM에 렌더링.
+- **서버 사이드 렌더링의 경우** 서버에서 DOM을 만듬 > 클라이언트에서는 DOM에 하이드레이션
+
+### 기존 리액트 컴포넌트와 서버 사이드 렌더링의 한계
+
+- 자바스크립트 번들 크기가 0인 컴포넌트를 만들 수 없다
+- 백엔드 리소스에 대한 직접적인 접근이 불가능
+- 자동 코드 분할이 불가능
+- 연쇄적으로 발생하는 클라이언트와 서버의 요청을 대응하기 어려움
+- 추상화 비용이 크다.
+
+ ### 결론
+
+- 서버 사이드 렌더링은 정적 콘텐츠의 빠른 제공, 서버에 있는 데이터를 쉽게 접근할 수 있지만 인터랙션에 따른 다양한 사용자 경험을 제공하긴 어렵다. 
+- 클라이언트 사이드 렌더링은 사용자의 인터랙션에 따라 정말 다양한 것들을 제공할 수 있지만 서버에 비해 느리고 데이터를 가져오는 것도 어렵다. 
+- 이러한 두 구조의 장점을 모두 취하고자 하는 것이 **리액트 서버 컴포넌트**
+
+### 리액트 서버 컴포넌트란?
+
+서버 컴포넌트란 하나의 언어, 하나의 프레임워크, 그리고 하나의 API와 개념을 사용하면서 **서버와 클라이언트 모두에서 컴포넌트를 렌더링 할 수 있는 기법**을 의미한다. 서버에서 할 수 있는 일은 서버가 처리하고, 서버에서 할 수 없는 클라이언트 작업은 브라우저에서 실행된다. 즉, 일부 컴포넌트는 브라우저에서 일부 컴포넌트는 서버에서 렌더링된다. (단, 클라이언트 컴포넌트는 서버 컴포넌트를 임포트 할 수 없음.)
+
+리액트는 클라이언트 컴포넌트, 서버 컴포넌트, 서버와 클라이언트에서 모두 사용할 수 있는 공용 컴포넌트로 나뉜다. 이들의 차이점을 알아보자
+
+- 서버 컴포넌트
+    - 요청이 오면 그 순간 서버에서 딱 한 번 실행될 뿐이므로 상태를 가질 수 없다. useState, useReducer 등의 훅을 사용할 수 없다.
+    - 렌더링 생명주기 역시 사용할 수 없다. useEffect, useLayoutEffect를 사용할 수 없다.
+    - 앞의 제약사항 때문에 커스텀 훅을 사용할 수 없다. 다만 effect, state에 의존하지 않고 서버에서 제공할 수 있는 기능만 사용하는 훅이라면 충분히 사용 가능하다.
+    - DOM API, window, document 등에 접근할 수 없다.
+    - DB, 내부 서비스, 파일 시스템 등 서버에 있는 데이터를 비동기로 접근할 수 있다.
+    - 다른 컴포넌트, html 요소, 클라이언트 컴포넌트를 렌더링 할 수 있다.
+- 클라이언트 컴포넌트
+    - 서버 컴포넌트, 서버 전용 훅을 임포트 할 수 없다.
+    - 서버 컴포넌트를 자식으로 갖는 것은 가능하다. 서버 컴포넌트는 이미 서버에서 완성된 트리고 클라이언트 컴포넌트는 이미 서버에서 만들어진 트리를 삽입해서 보여주기만 하면 되기 때문이다.
+    - 이 두가지만 제외하면 일반적인 리액트 컴포넌트와 비슷하다.
+- 공용 컴포넌트
+    - 이 컴포넌트는 클라이언트, 서버에서 모두 사용할 수 있으며 제약 사항 역시 클라이언트 컴포넌트, 서버 컴포넌트의 제약 사항을 그대로 받는다.
+
+### 서버 사이드 렌더링과 서버 컴포넌트의 차이
+
+- 서버 사이드 렌더링 : 응답 받은 페이지 전체를 HTML로 렌더링하는 과정을 서버에서 수행한 후 그 결과를 클라이언트에 내려준다. 그리고 이후 하이드레이션 과정을 거쳐 서버의 결과물을 확인하고 이벤트를 붙이는 등의 작업을 수행한다. 따라서 여전히 정적인 HTML을 빠르게 내려주는 것에 초점을 두고 있다. HTML 렌더링 이후, 클라이언트에서 JS코드를 다운,파싱,실행하는데 비용이 듦
+
+### 서버 컴포넌트는 어떻게 작동하는가?
+
+1. 서버가 렌더링 요청을 받는다.
+2. 서버는 받은 요청에 따라 컴포넌트를 JSON으로 직렬화한다. 이때 서버에서 렌더링할 수 있는 것은 직렬화해서 내보내고, 클라이언트 컴포넌트로 표시된 부분은 해당 공간을 플레이스홀더 형식으로 비워두고 나타낸다. 브라우저는 이 결과물을 받아 다시 역직렬화 한 다음 렌더링을 수행한다.
+3. 브라우저가 리액트 컴포넌트 트리를 구성한다. 서버로 스트리밍으로 JSON 결과물을 받았다면 이 구문을 다시 파싱한 결과물을 바탕으로 트리를 재구성해 컴포넌트를 만들어 나간다. 클라이언트 컴포넌트를 받았다면 클라이언트에서 렌더링을 진행할 것이고, 서버에서 만들어진 결과물을 받았다면 이 정보를 기반으로 리액트 트리를 그대로 만들것이다. 최종적으로 만들어진 이 트리를 렌더링해 브라우저의 DOM에 커밋한다.
+
+## Next.js에서의 리액트 서버 컴포넌트
+
+- Next에서도 기본적인 서버 컴포넌트의 제약은 동일하다.
+- 서버 컴포넌트는 클라이언트 컴포넌트를 불러올 수 없으며, 클라이언트 컴포넌트는 서버 컴포넌트를 childeren props로 받는 것만 가능하다. 
+