Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Binary file modified .DS_Store
Binary file not shown.
21 changes: 13 additions & 8 deletions chapter02/wogus216.md
Original file line number Diff line number Diff line change
Expand Up @@ -665,15 +665,15 @@ componentDidcatch 두개의 인수를 받는데, 첫번째는 getDerivedStateFro
1. 최초 렌더링
2. 리렌더링: 최소 렌더링이 발생한 이후로 발생하는 모든 렌더링을 의미

리렌더링 발생하는 경우는 다음과 같다.

리렌더링 발생하는 경우는 다음과 같다.
* 클래스형 setState가 실행되는 경우: state의 변화는 컴포넌트 상태의 변화를 의미
* 클래스형 forceUpdate가 실행되는 경우
* 함수형 useState 두 번째 배열요소 setter가 실행되는 경우
* 함수형 useReducer 두 번째 배열요소 dispatch가 실행되는 경우: useReducer도 useState와 마찬가지로 상태를 업데이트 함수를 배열로 제공
* 컴포넌트의 key props가 변경되는 경우: 리액트에서 Key는 리렌더링이 발생하는 동안 형제요소들 사이에서 동일한 요소를 식별하는 값.
* props가 변경되는 경우: 부모로 전달 받는 값이 props가 달라지면 자식 컴포넌트 변경이 필요
* 부모 컴포넌트가 렌더링될 경우
- 클래스형 setState가 실행되는 경우: state의 변화는 컴포넌트 상태의 변화를 의미
- 클래스형 forceUpdate가 실행되는 경우
- 함수형 useState 두 번째 배열요소 setter가 실행되는 경우
- 함수형 useReducer 두 번째 배열요소 dispatch가 실행되는 경우: useReducer도 useState와 마찬가지로 상태를 업데이트 함수를 배열로 제공
- 컴포넌트의 key props가 변경되는 경우: 리액트에서 Key는 리렌더링이 발생하는 동안 형제요소들 사이에서 동일한 요소를 식별하는 값.
- props가 변경되는 경우: 부모로 전달 받는 값이 props가 달라지면 자식 컴포넌트 변경이 필요
- 부모 컴포넌트가 렌더링될 경우

### 2.4.3 리액트의 렌더링 프로세스

Expand Down Expand Up @@ -750,5 +750,10 @@ memo나 다른 메모제이션 방법을 사용하는 것이 이점이 있을
- 리액트가 구 트리와 신규 트리를 비교

얼핏 봐도 memo를 하지 않았을 때 치러야할 잠재적인 위험비용이 더 커보인다.
정리하자면 메모제이션은 하지 않는 것 보다 메모이제이션을 했을 때 더 많은 이점을 누린다.

> 예제의 차이를 이해해보자

### 2.5.3 결론 및 정리

꼼꼼히 확인 하고 써보거나 쓰면서 계속 체크를 하는 둘 중 하나 방법
65 changes: 65 additions & 0 deletions chapter03/info.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,65 @@
# 03장: 리액트 훅 깊게 살펴보기

리액트를 이루는 핵심 요소들을 깊게 살펴보고, 리액트의 렌더링 과정을 이해하는 장입니다.

<br>

- [03장: 리액트 훅 깊게 살펴보기](#03장-리액트-훅-깊게-살펴보기)
- [3.1 리액트 훅 깊게 살펴보기](#31-리액트-훅-깊게-살펴보기)
- [3.1.1 useState](#311-usestate)
- [3.1.2 useEffect](#312-useeffect)
- [3.1.3 useMemo](#313-usememo)
- [3.1.4 useCallback](#314-usecallback)
- [3.1.5 useRef](#315-useref)
- [3.1.6 useContext](#316-usecontext)
- [3.1.7 useReducer](#317-usereducer)
- [3.1.8 useImperativeHandle](#318-useimperativehandle)
- [3.1.9 useLayoutEffect](#319-uselayouteffect)
- [3.1.10 useDebugValue](#3110-usedebugvalue)
- [3.1.11 훅의 규칙](#3111-훅의-규칙)
- [3.1.12 정리](#3112-정리)
- [3.2 사용자 정의 훅과 고차 컴포넌트 중 무엇을 써야 할까?](#32-사용자-정의-훅과-고차-컴포넌트-중-무엇을-써야-할까)
- [3.2.1 사용자 정의 훅](#321-사용자-정의-훅)
- [3.2.2 고차 컴포넌트](#322-고차-컴포넌트)
- [3.2.3 사용자 정의 훅과 고차 컴포넌트 중 무엇을 써야 할까?](#323-사용자-정의-훅과-고차-컴포넌트-중-무엇을-써야-할까)
- [3.2.4 정리](#324-정리)

<br>

## 3.1 리액트 훅 깊게 살펴보기

### 3.1.1 useState

### 3.1.2 useEffect

### 3.1.3 useMemo

### 3.1.4 useCallback

### 3.1.5 useRef

### 3.1.6 useContext

### 3.1.7 useReducer

### 3.1.8 useImperativeHandle

### 3.1.9 useLayoutEffect

### 3.1.10 useDebugValue

### 3.1.11 훅의 규칙

### 3.1.12 정리

<br>

## 3.2 사용자 정의 훅과 고차 컴포넌트 중 무엇을 써야 할까?

### 3.2.1 사용자 정의 훅

### 3.2.2 고차 컴포넌트

### 3.2.3 사용자 정의 훅과 고차 컴포넌트 중 무엇을 써야 할까?

### 3.2.4 정리