✨ 윤수현 24-03-04

docs/soohyun-dev/dil/2024-03-04.md

@@ -0,0 +1,60 @@
+## 2024-03-04
+
+📖 공부 범위 : 156p ~ 176p
+
+### getDerivedStateFromError()
+
+- 에러상황에서 실행되는 메서드
+- 에러가 발생했을 경우에 어떠한 자식 리액트 컴포넌트를 렌더링할지 결정해야하기 때문에, 반드시 state를 리턴해야함
+- 부수효과가 있어서는 안됨.
+- render 단계에서 실행
+
+### componentDidCatch()
+
+- 부수효과 수행 가능 ex. `console.error`
+- getDerivedStateFromError에서 에러를 잡고 state를 결정한 이후에 실행
+- 커밋 단계에서 실행
+- 두번째 인수인 ErrorInfo는 어느 컴포넌트에서 에러가 발생했는지에 대한 정보를 가지고 있음
+- 익명함수 일 경우, displayName을 알 수 없다.(평소에 기명함수 or displayName을 쓰는 습관을 들이자)
+
+### 클래스형 컴포넌트의 한계
+
+- 데이터의 흐름을 추적하기 어렵다.
+- 애플리케이션 내부 로직의 재사용이 어렵다.
+- 기능이 많아질수록 컴포넌트의 크기가 커진다.
+- 클래스는 함수에 비해 상대적으로 어렵다.
+- 코드 크기를 최적화하기 어렵다.
+- 핫 리로딩을 하는 데 상대적으로 불리하다.
+
+<br/>
+
+## 함수형 컴포넌트
+
+- 클래스형 컴포넌트의 생명주기 메서드가 함수형 컴포넌트에서는 존재하지 않음.
+- 클래스형 생명주기 메서드와 비슷한 일을 하는 함수들이 있지만 '비슷'할 뿐, '똑같다'는 아니다.
+- useEffect는 생명주기를 위한 훅이 아니다.
+- 클래스형 컴포넌트는 props의 값을 항상 this로부터 가져옴 (this가 가리키는 객체는 mutable한 값.)
+- 함수형 컴포넌트는 props와 state를 기준으로 렌더링
+- 클래스형 컴포넌트는 시간의 흐름에 따라 변화하는 this를 기준으로 렌더링
+
+<br/>
+
+### 렌더링
+
+리액트에서의 렌더링이란?
+
+```
+리액트 애플리케이션 트리 안에 있는 모든 컴포넌트들이 현재 자신들이 가지고 있는
+props와 state의 값을 기반으로 어떻게 UI를 구성하고 이를 바탕으로 어떤
+DOM 결과를 브라우저에게 제공할 것인지 계산하는 일련의 과정
+```
+
+리액트의 렌더링이 일어나는 이유
+
+1. 클래스형 컴포넌트의 setState가 실행되는 경우
+2. 클래스형 컴포넌트의 forceUpdate가 실행되는 경우
+3. 함수형 컴포넌트의 useState()의 두 번째 배열 요소인 setter가 실행되는 경우
+4. 함수형 컴포넌트의 useReducer()의 두 번째 배열 요소인 dispatch가 실행되는 경우
+5. 컴포넌트의 key props가 변경되는 경우
+6. props가 변경되는 경우
+7. 부모 컴포넌트가 레더링될 경우 (부모 컴포넌트가 리렌더링 되면다면, 자식 컴포넌트도 무조건 리렌더랑 발생)