1. React 동작방식과 다양한 hook

👀  목표

1. 컴포넌트가 언제 리렌더링 되는지 살펴보기

2. 다양한 훅을 이해하고 사용하기

 

👀  React의 렌더링 라이프 사이클

🟣 1. Trigger

단어 그대로 렌더링을 시작하게끔 방아쇠를 당기는 과정.

 

언제 Trigger가 발동되나요?

1. 첫번째 렌더링이 수행될때

a. ReactDOM.createRoot(..).render()

2. 컴포넌트의 state가 변경될 때

a. 클래스 컴포넌트의 setState 메서드

b. useState, useReducer등 상태변경 훅의 setter 함수 호출.

 

1. 렌더링 Batch 처리

Trigger 과정에서 여러가지 작업을 한번에 묶어서 수행하는 Batch 기법을 사용한다.

function Component() {
	const [count, setCount] = useState(0);
	const increase = () => {
		// trigger 함수가 두번 호출되었을때
		setCount(count + 1);
		setCount(count + 2);
	};

	// 두번 호출 될까요?
	console.log('rendered');

	return (
		<>
			<div>{count}</div>
			<button onClick={increase}>Increase</button>
		</>
	)
}

정답은 아니오!

최적화를 위해서 렌더링은 마지막에 지정된 true 값이 뜰때까지 모든 상태변화를 지연실행시켜 한번에 업데이트를 수행한다.

그래서 콘솔도 한번만 찍힌다.

 

비동기 렌더링도 예전에는 Batch 처리가 되지 않았지만 Fiber Architecture가 도입되면서 비동기 콜백에서도 Batch 처리가 가능해졌다.

---

 

🟣 2. Render

어떤 부분을 어떻게 업데이트 해야하는지 확인하는 단계

 

1. Virtual DOM

보통 JS 연산보다 DOM연산 비용이 더 크기때문에 실제 DOM을 건드는게 아닌 Virtual DOM(DOM을 모방한 JS 객체)으로 연산을 마치고 DOM에는 결과만 반영하는 방법을 사용한다.

React에는 Virtual DOM을 구현하기 위해서 React Element, Fiber, VDOM 개념을 사용한다.

 

 

2. React Element

HTML 구조체로 Virtual DOM을 생성하는 과정을 좀 더 편한 문법으로 다룰 수 있게 JSX 문법과 컴파일러를 제공한다.

return (
	<div>
		<div>{count}</div>
		<button onClick={increase}>Increase</button>
	</div>
)

이렇게 작성된 JSX 문법은

return React.createElement(
	'div',
	null,
	React.createElement('div', null, count),
	React.createElement('button', { ... }, 'Increase'),
);

컴파일러를 통해 이런 코드 형식으로 변환된다.

이런 React Element 객체는 불변(Immutable)하다.

 

 

3. Fiber

렌더링을 여러 조각으로 쪼개서 DOM 변경 요소를 처리하는 알고리즘.

Fiber로 인해 비동기 렌더링의 핵심인 렌더링 작업을 중지하고 다시 실행하는 것을 가능하게 한다.

렌더링 단위는 일반적으로 컴포넌트 단위로 이루어진다.

child와 sibling을 참조값으로 다음으로 해야할 렌더링 작업인 다음 Fiber을 가르키는 그래프 구조로 되어있다.

function Component() {
	const [count, setCount] = useState(0);
	const increase = () => setCount(count => count + 1);

	return (
		<div>
			<div>{count}</div>
			<button onClick={increase}>Increase</button>
		</div>
	)
}

 

scheduleWork(fiber, expireTime)

{
// 작업 중인 props (props가 없음)
  pendingProps: null,
// Render Phase 끝난 뒤의 Props (props가 없음)
	memoizedProps: null,
// count 0 에 대한 정보가 담깁니다. 
// 실제 DOM에 커밋되어야 하는데 WORK들이 스케줄링되는 update에 대한 정보도 큐로 관리됩니다.
  memoizedState: {
		baseState: { count: 0 },
		next: null, // hook 이 추가적으로 실행되면 LinkedIn 방식으로 hook 정보가 담깁니다.
	},
	...
}

생성된 Fiber은 DOM에 반영되기 위해서 스케줄링 된다.

 

 

4. React Virtual DOM

변경사항을 확인하기 위한 Fiber 노드의 트리 자료구조.

virtual dom에는 현재 상태와 다음 상태를 비교하기 위해서 두개의 트리로 이루어져 있다.

current tree는 현재 상태의 트리, workInProgress는 현재 작업으로 인해 바뀌는 트리다.

(쉽게 current tree의 참조주소를 working tree에 덮어씌워서 업데이트 하는것으로 이해했다.)

 

나는 이때까지 virtual dom으로 인해 로딩 속도가 빠르다고 알고있는 상태였다.

그래서 virtual dom이 react의 손에 꼽는 장점이라고만 알고있었다.

 

하지만 단점도 존재했다.

연산 비용이 큰 DOM을 직접 조작하지 않아서 성능을 개선하는 용도로 쓰였지만

애초에 virtual dom을 관리하는게 많은 메모리와 CPU 오버헤드가 발생한다.

(이번에 공부하면서 react 공식 문서에서 virtual dom이라는 용어가 제거되었다는 소식을 들었다.)

 

 

5. 재조정(Reconciliation)과 diff(Diffing) 알고리즘

재조정 : DOM 트리에 업데이트 해야하는 내용을 이전 트리와 비교해 계산하고 파악하는 과정

 

보통 두개의 트리를 비교하는 알고리즘은 최소 O(n^3)의 순회비용이 발생한다고 한다.

React에서는 위의 시간복잡도를 줄이기 위해 key 값을 이용한 Heuristics 알고리즘을 이용해서 O(n)까지 줄이는데 성공했다.

---

 

🟣 3. Commit

재조정(Reconciliation) 프로세스의 마지막 단계로 변화된 부분을 DOM에 반영한다.

이 단계에서는 보통 아래의 작업들을 수행한다.

 

1. pre-commit phase

변경 사항을 확정하기 전 작업 준비.

주로 레이아웃 효과(useLayoutEffect)가 예약된다.

 

2. commit phase

DOM 업데이트 

DOM 속성 및 스타일 업데이트

Ref 업데이트 : DOM 요소에 직접 접근하는 방법으로 이 단계에서 업데이트 된다.

레이아웃 효과(useLayoutEffect) 실행

 

3. post-commit phase

Effects 업데이트 : 사이드이펙트 훅이 실행된다.

비동기 작업 실행

 

---

 

👀  React의 여러가지 hook

🟣 useState

export default function UseStateTest() {
  const [state, setState] = useState({ bar: { count: 1 } });
  const increment = () => {

    setState((prev)=>({
      ...prev, // useState는 불변함을 지켜주는 형태로 값을 바꿔야 렌더링 trigger의 조건이 지켜진다.
      bar:{
        ...prev.bar,
        count: prev.bar.count+1
      }
    }))
  }

  return (
    <div>
      count: {state.bar.count}
      <button onClick={increment}>증가</button>
    </div>
  );
}

 

🟣 useMemo

import { useMemo, useState } from "react";
import { repeatBarked, repeatMeow } from "./UseMemoTest.utils.ts";

export default function UseMemoTest() {
  const [meowCount, setMeowCount] = useState(1);
  const [barkedCount, setBarkedCount] = useState(1);

  // useMemo는 의존성 배열의 값이 업데이트 될때까지 이미 계산된 값을 캐싱한다.
  const meow = useMemo(()=>repeatMeow(meowCount),[meowCount]) 
  const bark = useMemo(()=>repeatBarked(barkedCount),[barkedCount])

  return (
    <div>
      <p data-testid="cat">고양이 "{meow}"</p>
      <p data-testid="dog">강아지 "{bark}"</p>
      <button data-testid="meow" onClick={() => setMeowCount(n => n + 1)}>야옹</button>
      <button data-testid="bark" onClick={() => setBarkedCount(n => n + 1)}>멍멍</button>
    </div>
  );
}

 

🟣 pureComponent

import { memo, useState } from "react";
import { Cat, Dog } from "./PureComponentTest.components.tsx";

// memo는 컴포넌트를 캐싱해서 동일한 props로 여러번 렌더링 되는것을 방지한다.
// memo를 걸지않으면 부모 컴포넌트가 렌더링되면 자식 컴포넌트도 전부 렌더링되기 때문에
// memo를 걸어서 부모 컴포넌트가 렌더링 되어도 동일한 props인 자식 컴포넌트는 렌더링되지 않게 막는다.
const MemoCat = memo(Cat);
const MemoDog = memo(Dog);

export default function PureComponentTest() {
  const [meowCount, setMeowCount] = useState(1);
  const [barkedCount, setBarkedCount] = useState(1);

  return (
    <div>
      props의 값이 변경될 때만 렌더링이 발생
      <MemoCat crying={meowCount}/>
      <MemoDog crying={barkedCount}/>
      <button data-testid="meow" onClick={() => setMeowCount(n => n + 1)}>야옹</button>
      <button data-testid="bark" onClick={() => setBarkedCount(n => n + 1)}>멍멍</button>
    </div>
  );
}

 

🟣 useCallback

import { ComponentProps, PropsWithChildren, memo, useCallback, useMemo, useState } from "react";
import { BarkButton, MeowButton } from "./UseCallbackTest.components.tsx";

// pureComponent와 useCallback을 사용해서 불필요한 렌더링을 막는다.
const PureComponent = memo(({ children, ...props }: PropsWithChildren<ComponentProps<'p'>>) => {
  return <p {...props}>{children}</p>
})

export default function UseCallbackTest() {
  const [meowCount, setMeowCount] = useState(0);
  const [barkedCount, setBarkedCount] = useState(0);

  const callbackMeowCount = useCallback(
    ()=>{setMeowCount(n => n + 1)},[setMeowCount]
  )
    
  const callbackBarkCount = useCallback(
    ()=>{setBarkedCount(n => n + 1)},[setBarkedCount]
  )

  return (
    <div>
      <PureComponent data-testid='cat'>meowCount {meowCount}</PureComponent>
      <PureComponent data-testid='dog'>barkedCount {barkedCount}</PureComponent>
      <MeowButton onClick={callbackMeowCount}/>
      <BarkButton onClick={callbackBarkCount}/>
    </div>
  );
}

 

🟣 RequireRefactoring

// useMemo, useCallback 등을 사용하지 않고 이 컴포넌트를 개선할 수 있다.

import { ComponentProps, memo, PropsWithChildren } from "react";

type Props = {
  countRendering?: () => void;
}

// React는 성능 최적화를 위해 얕은 비교를 사용하여 객체의 참조 주소를 비교한다.
// 그 중 memo는 props가 변경될때마다 얕은 비교를 한다.
// 그래서 참조 타입의 경우 주소가 변경되면 props가 변경된 것으로 간주.
// 그래서 PureComponent가 memo를 썼지만 부모 컴포넌트에서 객체와 함수로 props를 넘겨주면 값이 같아도 리렌더링이 된다.
const PureComponent = memo(({ children, countRendering, ...props }: PropsWithChildren<ComponentProps<'div'> & Props>) => {
  countRendering?.();
  return <div {...props}>{children}</div>
})

// eslint-disable-next-line @typescript-eslint/no-unused-vars
let outerCount = 1

// 컴포넌트 밖에 정의한 객체나 함수같은 참조타입은 프로그램이 실행될때 한번 생성되어서
// 컴포넌트 안에서 밖에 정의된 객체를 사용해도 주소값은 같은곳을 바라보고 있기때문에 리렌더링을 방지할 수 있다.
const style = { width: '100px', height: '100px' }
const onClick = () => {
  outerCount += 1;
}

export default function RequireRefactoring({ countRendering }: Props) {

  return (
    <PureComponent
      // 첫번째 문제점. 객체로 props를 전달하면 컴포넌트안의 객체는 항상 값은 같아도 새로 생성되기 때문에 다른 주소값을 가져서 새로운 객체로 간주해서 리렌더링됨.
      style={style}
      // 두번째 문제점. onClick에 전달된 함수도 참조타입이기 때문에 내용이 같더라도 새로운 함수로 간주해서 리렌더링됨.
      onClick={onClick}
      countRendering={countRendering}
    >
      test component
    </PureComponent>
  );
}

/** 내가 잘못 생각한것 : 왜 컴포넌트 안의 객체는 다른 주소값을 가지지?? react에서 일부러 다른 메모리 주소를 참조하게 해서 해당 컴포넌트의 리렌더링을 일으키기 위한건가??
 * 컴포넌트도 결국 하나의 함수라는것을 깜빡함..ㅠ
 * 컴포넌트는 함수이기 때문에 호출될때마다 새로운 실행컨텍스트를 생성한다.
 * 그래서 내부의 변수나 객체도 새로운 실행컨텍스트 내에서 새로 생성된다.
 * 그래서 동일한 코드라도 리렌더링하면 컴포넌트안의 참조타입들(객체, 배열, 함수 등)은 새로운 주소를 참조한다.
 */

 

🟣 useMyRef

import { useMemo } from "react"

export function useMyRef<T>(initValue: T | null) {

  const ref = useMemo(()=>{
    return { current: initValue };
  },[])

  return ref;
}

// 같은 메모리의 참조타입을 반환하지 않는다.
// 그럼 지금 문제는 리렌더링 버튼을 누를때마다 계속 새로운 객체를 반환한다는 건데,
// useMyRef는 함수. 함수는 실행될때마다 새로운 실행컨텍스트가 생성되기 때문에
// 그 안의 객체도 같은 값이여도 새로운 주소의 객체를 반환한다.
// 리렌더링 될때 메모이제이션 훅들로 다른 메모리로 객체를 생성하지 못하게 막아야 하나..?

// useMemo를 사용하면 계산된값을 캐싱을 하기때문에 의존성 배열의 값이 바뀔때까지 같은 메모리 참조를 한다.
// useRef는 .current 값을 바꿔도 항상 같은 메모리의 객체를 반환한다.
// 이 커스텀훅에도 동일하게 해주기 위해서 의존성 배열을 비운다.
// 의존성 배열을 비우면 다시 계산해야될 기준이 없기때문에
// 처음 렌더링 되었을때 계산된 값을 어떤 메모리에 값을 저장하고 그 뒤에는 동일한 메모리를 참조한다.
// 그러면 객체내부의 값은 바뀌어도 동일한 메모리를 참조해서 useRef와 비슷하지 않을까...?

이건 나의 풀이

import { useState } from "react";

export function useMyRef<T>(initValue: T | null) {
  // 사실 ref도 state의 한 종류입니다. set을 하지 않기 때문에, 언제나 동일한 state로 존재합니다.
  const [ref] = useState<{ current: typeof initValue}>({ current: initValue });
  return ref
}

이건 정답..

 

나는 동일한 메모리를 참조하는것에만 집중했는데 정답을 보고 아하! 했다ㅠ

화면에 바뀐 내용을 보여주려면 useState는 무조건 불변성을 지켜야한다!를 뒤집는 생각이었다.

setter 함수를 사용하지 않고 상태 객체 속성을 직접 변경해서 불변성을 지키지 않았기 때문에 동일한 참조를 유지할 수 있다.

 

---

tmi...

3주동안 한걸 정리하면서 멘토님의 피드백을 보는데 나에겐 아직 험난한 난이도(ㅠㅠ)로 인해

첫 주만 나의 생각을 토대로 정리해서 과제를 낼 수 있었고, 그에 대한 피드백을 받을 수 있었다..

흑....ㅠㅠㅠ 2,3주차 너무 어려워요😇