DIL: 모던 리액트 딥 다이브, 1주차-6

스터디: 월간 CS, https://github.com/monthly-cs/2024-03-modern-react-deep-dive
오늘 진행: 개인공부

---

DIL-week1-6_2024-03-09

| DIL 주차 | 범위 | 내용 | 오늘차 진도 | | -------- | ------ | ------------------------------ | ----------- | | 1주차 | 1, 2장 | 리액트 핵심요소와 자바스크립트 | 162p~ |

오늘 읽은 내용을 markdown으로 간단히 메모
읽은 시간: 10시~12시반 시간이 없다!

1. 빠르게 읽기: 추가 검색x, 예제 만들기x => 하지만 만들었죠?

2. 발표 맥락 정하기

3. 장표 만들면서 추가 공부

4. 궁금한 점은 정리해서 일요일 10시에 토의

• 댄 아브라모프 Dan Abramov의 블로그 인용이 많이 나온다 https://overreacted.io/

---

클래스 컴포넌트의 한계

• 데이터의 흐름을 추적하기 어렵다: state의 업데이트 위치 어디? 생명 주기 메소드 코드의 흐름 파악해야함
• 재사용이 어렵다: HOC로 감싸거나, props를 전달해서 재사용 시, wrapper hell에 빠질 수 있다. 컴포넌트 상속으로 재사용 시, 클래스의 흐름을 쫓아야 함
• 컴포넌트가 커진다: 로직, 내부 데이터 흐름이 복잡하면 생명주기 메서드를 많이 써서 컴포넌트가 뚱뚱해짐
• 상대적으로 어렵다: JS 개발자들이 class 문법에 익숙하지 않고, 혼돈의 JS this
• 코드 크기 최적화 어려움: 번들 크기를 줄이기 어렵다. 메서드명이 minified되지 않고, 사용하지 않는 메서드가 트리쉐이킹 되지 않음
• hot reloading에 불리
  • class component: 최초 랜더링 시 instance를 생성 => 내부에서 state 값 관리. instance 내부에 있는 render()를 수정할 시, instance를 새로 만듦 => state이 초기화됨
  • function component: state 값을 클로저에 저장, 함수가 다시 실행되도 state을 잃지 않음

함수 컴포넌트

• 16.8 버전 이전에는 무상태 컴포넌트를 구현하기 위한 수단

생명주기 메서드

• componentDidMount, componentDidUpdate, componentUnmount를 useEffect를 사용해 비슷하게 구현
  • useEffect는 생명주기x => 그냥 동기적인 side effect 매커니즘

함수 컴포넌트와 랜더링된 값

| 구분 | 차이점 | props | 설명 | | ------------------ | --------------------------- | ------------ | --------------------------------------------------------------------------- | | class component | 랜더링된 값을 고정하지 않음 | this.props | 따라서 생명주기 메서드가 변경된 nextProps 값을 읽을 수 있다 (변화하는 this) | | function component | 랜더링된 값을 고정함 | props는 인수 | 랜더링이 일어날 때, 그 순간의 props, state을 기준으로 랜더링 |

• class component에서 props를 고정하고 싶다면?
  • 미리 함수를 실행해 인수에 전달해놓는다
  • render(){ 여기 } 내에 값을 넣는다. 이상해

랜더링은 어떻게 일어나는가?

• 리액트 랜더링: 브라우저가 랜더링에 필요한 DOM 트리를 만드는 과정
• 리액트 애플리케이션 트리 안에 있는 모든 컴포넌트들이 현재 자신들이 가지고 있는 props와 state의 값을 기반으로 어떻게 UI를 구성하고, 이를 바탕으로 어떤 DOM 결과를 브라우저에 제공할 것인지 계산하는 일련의 과정

리액트에서 랜더링이 발생하는 이유

• 최초 랜더링
  • 사용자가 처음 애플리케이션에 진입
  • 브라우저에 랜더링할 결과물(정보)를 제공하기 위해 최초 랜더링 수행
• 리랜더링
  • 클래스 컴포넌트
    • setState 실행
    • forceUpdate 실행(shouldComponentUpdate를 건너뜀, render 내부에서 실행하면? 무한 루프)
  • 함수 컴포넌트
    • useState의 setter 실행
    • useReducer의 dispatch 실행
    • key props가 변경되는 경우
    • 부모 컴포넌트가 랜더링 될 경우
    • props가 변경되는 경우

key props?

• 리랜더링이 발생하는 동안, 형제 요소들 사이에서 동일 요소를 식별하는 값
• key가 없다면? 파이버 내부의 sibling 인덱스만 기준으로 판단하게 됨
• key를 사용해 강제로 리랜더링 하는 것도 가능

리액트의 랜더링 프로세스

• 랜더링 프로세스가 시작되면, 컴포넌트 루트에서부터 아래쪽으로 내려가며 업데이트가 필요한 컴포넌트를 찾는다
  • 발견 시, 클래스 컴포넌트라면 render()
  • 발견 시, 함수 컴포넌트라면 FunctionComponent()를 호출 후, 결과 저장

    // 결과
    {type: MyComponent, props: {count: 0, required: true, children: "안녕"}}
    

  • JSX니까 createElement()를 호출하는 구문으로 변환된다
• Reconciliation 재조정: 컴포넌트의 랜더링 결과물을 수집, 가상 DOM과 비교해서 실제 DOM에 반영하기 위한 변경 사항 수집하는 과정.
• 변경 사항을 동기 시퀀스로 DOM에 적용

Render Phase와 Commit Phase

• 랜더 Render Phase
  • 컴포넌트를 실행: render(), return
  • 결과와 이전 가상 DOM을 비교
  • type, props, key 중 변경이 있다면 변경이 필요한 컴포넌트
• 커밋 Commit Phase
  • 랜더 단계의 변경 사항을 실제 DOM에 적용
  • 업데이트 시, 만든 DOM 노드 및 인스턴스를 리액트 내부의 참조를 업데이트
    • componentDidMount, componentDidUpdate 메서드, useLayoutEffect 훅 호출
  • 커밋 이후, 브라우저의 랜더링이 발생한다
• 리액트의 랜더링이 일어나도 랜더 단계에서 변경사항을 감지할 수 없다면? 커밋 단계가 생략되어 브라우저 DOM 업데이트가 일어나지 않을 수 있다

메모이제이션

컴포넌트와 함수의 무거운 연산을 기억 useMemo, useCallback, HOC memo

갑론을박 🤜🤛

memoization 반대파

• memoization은 비용이다.
  • 값을 비교하고 랜더링 혹은 재계산이 필요한지 확인하는 작업
  • 결과물을 저장해 두었다가 다시 꺼내오는 작업
• 신중하게 해야한다.
  • premature optimization / premature memoization 을 경계하자.
• 리액트가 모든 컴포넌트를 PureComponent로 만들거나, memo로 감싸는 작업을 하지 않은 이유: 트레이트 오프가 있다. silver bullet이 아님

memoization 찬성파

• memoization의 비용은? props에 대한 얕은 비교, 리랜더링 리액트의 Reconciliation 알고리즘과 같다. 어차피 결과물은 저장 중
• 잠재적 위험 비용
  • 랜더링 비용
  • 컴포넌트 내부의 복잡한 로직 재실행
  • 자식 컴포넌트에서 반복적으로 일어남
  • 리액트가 구 트리 and 신규 트리 비교

function useMath(number: number) {
  const [double, setDouble] = useState(0);
  const [triple, setTriple] = useState(0);

  useEffect(() => {
    setDouble(number * 2);
    setTriple(number * 3);
  });

  return useMemo(() => ({ double, triple }), [double, triple]);
}

• 메모이제이션 예제: ./2024-03-09_sample.tsx