Merge pull request #2 from monthly-cs/윤수현W_01

3월 1주차 회고

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

@@ -0,0 +1,40 @@
+## 2024-03-02
+
+📖 공부 범위 : 96p ~ 143p
+
+### 1.6
+
+- 주요 문법들이 정리되어있음
+- 추가로 실무에서 자주사용하는 문법들 정리하면 좋을 것 같음.
+
+### 1.7
+
+- 타입스크립트는 타입 체크를 런타임이 아닌 빌드 타임에 수행
+- 타입스크립트가 아닌 자바스크립트로만 프로젝트를 수행한다면?
+- any를 사용하는 예
+- 제네릭을 하나 이상 사용하는 경우 T보다는 네이밍 추천
+- 인덱스 시그니처는 실무에서 매우 자주 만나보았음. 알아두면 좋다,
+
+```
+ex) Record<KEY, string>
+```
+
+- 덕 타이핑
+- 타입스크립트는 협업 프로젝트에서 빛을 낸다 생각
+
+### 2.1
+
+- JSX는 React에 종속적이지 않음.
+- JSXIdentifier 라는 것이 있음. ($, \_ 해당 태그들이 가능함. <숫자></숫자> or 다른 특수문자들은 안됨.)
+- 이스케이프(\)를 처리하는데 있어 JS와 차이점이 있음.
+- 코드 2.6은 새롭게 안 사실. 다만, 가독성은 안좋아 보인다.
+
+### 2.2
+
+- 렌더링 과정, 화면에 보이지 않는 노드는 방문x
+- 레이아웃 => 리페인팅
+- 일반적으로 가상 DOM이 빠르다고 하는 것은 일반적인 DOM을 관리하는 브라우저보다 빠르다는 얘기
+- 리액트 파이버 (비동기)
+- 파이버는 컴포넌트가 최초로 마운트되는 시점에 생성되어 이후에는 가급적이면 재사용됨.
+- 더블 버퍼링
+- 파이버와 가상DOM 내용은 한번에 이해가 잘 안됨. 여러번 읽어봐야겠다.

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

@@ -0,0 +1,7 @@
+## 2024-03-03
+
+📖 공부 범위 : 143p ~ 156p
+
+- 오늘은 가볍게 읽어보았다.
+- 역시 클래스형 컴포넌트 내용은 어렵다...
+- 사용 해보지 않은 것들이라서 텍스트로만 이해하는게 참 어렵다.

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. 부모 컴포넌트가 레더링될 경우 (부모 컴포넌트가 리렌더링 되면다면, 자식 컴포넌트도 무조건 리렌더랑 발생)