모던 리액트 Deep Dive - 렌더링

⚡리액트 핵심요소 깊게 살펴보기 - 2.4 렌더링은 어떻게 일어나는가?

리액트의 렌더링은 브라우저가 렌더링에 필요한 DOM트리를 만드는 과정이고, 렌더링은 시간과 리소스를 소비해 수행되는 과정이므로 렌더링 과정을 최소한으로 줄이는게 좋음

2.4.1 리액트의 렌더링이란?

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

2.4.2 리액트의 렌더링이 일어나는 이유

🌚리액트에서 렌더링이 발생하는 시나리오

1. 최초렌더링 : 사용자가 처음 애플리케이션을 진입하면 렌더링해야 할 결과물이 필요한데, 리액트는 브라우저에 해당 정보를 제공하기 위해 최초렌더링을 수행함

2. 리렌더링 : 최초 렌더링 발생한 이후에 발생하는 모든 렌더링을 의미함

• 클래스형 컴포넌트의  setState가 실행되는 경우
• 클래스형 컴포넌트의 forceUpdate가 실행되는 경우 
• 함수형 컴포넌트의 useState의 두번째배열 요소인 setter가 실행되는 경우 
• 함수형 컴포넌트의 useReducer의 두번째배열 요소인 dispatch가 실행되는 경우 
• 컴포넌트의 key props가 변경되는 경우 
• props가 변경되는 경우
• 부모 컴포넌트가 렌더링될 경우 

이외의 경우의 시나리오들은 아무리 변경되더라도 리렌더링을 발생시키지 않아 변경된 값을 렌더링 DOM에서 확인할 수 없음

mobX와 Reducx같은 리액트 라이브러리는 각자의 방법으로 상태를 관리해주지만 해당 상태 관리가 리액트의 리렌더링으로 이어지지 않음

리액트의 리렌더링은 컴포넌트의 state나 props가 바뀔 때 일어나지만,MobX나 Redux는 리액트의 내부 state가 아니라 리액트 바깥에서 상태를 따로 관리하는 도구임 즉, 해당 라이브러리들이 상태를 바꾼다고 해서 바로 리액트가 자동으로 리렌더링되는 건 아님 그래서 리렌더링이 일어나려면, 그 상태 변화가 리액트 컴포넌트에 연결되어 있어야 함

2.4.3 리액트 렌더링 프로세스 

🌚렌더링이 어떤 과정을 거쳐 수행되는지 확인

렌더링 프로세스가 시작되면 리액트는 컴포넌트의 루트에서부터 아래쪽으로 내려가면서 업데이트가 필요하다고 지정되어 있는 컴포넌트를 찾음

function Hello(){
	return(
    	<TestComponent a={3} b="yeffect">
        	하이
        </TestComponent>
    )
}

//JSX문법은 React.createElemnt를 호출해서 변환됨
function Hello(){
	return React.createElemnt(
    	TestComponent,
        {a :3, b : 'yeffect'},
        '하이',
    )
}

//결과물
{type:TestComponent ,props:{a:3,b:"yeffect", chiledred : "하이"}}

• 렌더링 프로세스가 실행되면서 해당 과정을 거쳐 각 컴포넌트의 렌더링 결과물을 수집한 다음, 리액트의 새로운 트리인 가상 DOM과 비교해 실제 DOM에 반영하기 위한 모든 변경사항을 수집함
• 주목해야 할 점은 리액트의 렌더링은 렌더 단계와 커밋단계라는 두단계로 분리되어 실행된다는 것임

2.4.4 렌더와 커밋

💡 렌더단계(Render Phase)

• 컴포넌트를 렌더링하고 변경사항을 계산하는 모든 작업을 말함
• 렌더링 프로세스에서 컴포넌트를 실행(render() 또는 return)하여 결과와 이전 가상 DOM을 비교하는 과정을 거쳐 변경이 필요한 컴포넌트를 체크하는 단계
• 비교하는 것은  type, props, key 이며, 세가지 하나라도 변경된 것이 있으면 변경이 필요한 컴포넌트로 체크함

💡 커밋단계(Commit Phase)

• 렌더단계의 변경사항을 실제 DOM에 적용해 사용자에게 보여주는 과정
• 해당 단계가 끝나면 브라우저 렌더링이 발생함
• 리액트의 렌더링이 일어난다고 해서 무조건 DOM업데이트가 일어나는 것은 아니다
• 렌더링을 수행했으나 커밋단계까지 갈 필요가 없다면, 즉 변경사항을 계산했는데 아무런 변경사항이 감지되지 않는다면 해당 커밋단계는 생략할 수 있음(가시적인 변경이 일어나지 않아도 발생할 수 있음)
• 렌더링 과정 중 첫번째 단계에서 변경사항을 감지할 수 없다면 커밋단계가 생략되어 DOM업데이트가 일어나지 않을 수 있음

2.4.5 일반적인 렌더링 시나리오 살펴보기

import { useState } from 'react'

export default function A() {
  return (
    <div className="App">
      <h1>Hello React</h1>
      <B />
    </div>
  )
}

function B() {
  const [counter, setCounter] = useState(0)
  
  function handleButtonClick() {
    setCounter((previous) => previous + 1)
  }
  
  return (
    <>
      <label>
        <C number={counter} />
      </label>
	  <button onClick={handleButtonClick}>+</button>
    </>
  )
}

function C({ number }) {
  return (
    <div>
    {number} <D />
    </div>
  )
}

function D() {
  return <>리액트 재밌다!</>
}

💡사용자가 B 컴포넌트의 버튼을 눌러 counter 변수를 업데이트한다고 가정해보자!

1. B 컴포넌트의 setState가 호출된다.
2. B 컴포넌트의 리렌더링 작업이 렌더링 큐에 들어간다.
3. 리액트는 트리 최상단에서부터 렌더링 경로를 검사한다.
4. A 컴포넌트는 리렌더링이 필요한 컴포넌트로 표시되어 있지 않으므로 별다른 작업을 하지 않는다.
5. 그다음 하위 컴포넌트인 B 컴포넌트는 업데이트가 필요하다고 체크되어 있으므로 B를 리렌더링한다.
6. 5번 과정에서 B는 C를 반환했다.
7. C는 props인 number가 업데이트 됐다. 그러므로 업데이트가 필요한 컴포넌트로 체크되어 있고 업데이트 한다.
8. 7번 과정에서 C는 D를 반환했다.
9. D도 마찬가지로 업데이트가 필요한 컴포넌트로 체크되지 않았다. 그러나 C가 렌더링됐으므로 그 자식인 D도 렌더링됐다.

컴포넌트를 렌더링하는 작업은 하위 모든 컴포넌트에 영향을 미침