** 주의 이 글은 개인적인 공부정리 글로써, 최대한 정확한 내용을 전달 하기 위해서 공식 문서 기반으로 작성 하였으나 본의 아니게 주관적인 내용을 함유 할 수도 있음을 고지합니다 **
변역한 자료 https://beta.reactjs.org/learn/render-and-commit
들어가며
부트캠프에서 프로젝트를 개발하기 위해서 나는 리액트를 사용했다.
예전에도 잠깐 리액트를 전반적으로 공부하고 다뤘기 때문에, 잘할 수 있을 거라고 생각했다.
하지만, 그 생각은 오산이였다.
프로젝트 도중 낙관에 종종 부딪히게 됐다.
예기치 못한 리렌더링, 그리고 리렌더링을 예상했지만, 리렌더링이 되지 않는 상황,
useEffect가 실행되지 않는 상황 등을 겪으며.
생각했다. 다시 리액트를 기초부터 공부하자.
이 글은 그 여정을 위한 첫걸음이다.
리액트에서의 렌더링이란?
리액트에서 정확히 렌더링이란 각 컴포넌트가 화면에 표시되기 전을 의미한다.
해서 먼저 용어를 명확히 하기 위해서
리액트에서 각 컴포넌트가 사용자 화면에 보이기까지 어떤 과정을 거치는지 그리고 각 과정이 어떤 용어로 쓰이는지 먼저 살펴보자.
만약 필자의 설명이 마음에 안들거나 이해가 안된다면 공식문서를 살펴보자https://beta.reactjs.org/learn/render-and-commit
총 3가지의 순서로 진행된다.
- 렌더링 트리거 ****(마치 손님의 주문표를 차곡차곡 주방에다 전달하는 같은것.)
- 컴포넌트 렌더링
- DOM에다 커밋
즉 트리거, 렌더링, 커밋 이렇게 나뉜다고 쉽게 생각하면 된다.
1. Trigger
렌더링 트리거
렌더링 트리거란 렌더링을 하기 위해서 대기열에 추가하는 로직을 뜻합니다( 자의적인 의역이 포함되어 있습니다, 뜻의 왜곡이 있을수 있으니 공식문서를 참고해 주세요 )
리액트에서 각 컴포넌트의 렌더링은 크게 2가지 경우 발생한다.
- 초기 렌더링
- 상태가 업데이트 될때.
초기 렌더링
리액트 앱이 실행될때 발생 하는 초기 렌더링
보통 ReactDOM.render() 와 컴포넌트가 실행될떄를 뜻합니다
import Image from './Image.js';
import ReactDOM from 'react-dom';
ReactDOM.render(
<Image />,
document.getElementById('root')
);상태 업데이트시 리 렌더링
상태가 useState 같은 훅을 통해서 상태가 업데이트되면 다시 리렌더링을 하라고 트리거를 할 수 있습니다
즉 상태가 업데이트가 되면 자동으로 트리거가 되면서 렌더링 대기열에 추가가 됩니다
2. 렌더링
트리가 된 후에는 React는 컴포넌트를 호출해서 화면에 표시해야 할 내용을 파악합니다
즉 렌더링이란 컴포넌트를 호출하는 React 이다. 즉 내 식대로 해석을 하자면, 렌더링이란 React가 컴포넌트를 호출해서 실행시키는 것 같은 뜻인듯하다
위 트리거에서 설명했듯이 렌더링은 2가지 경우 발생한다
- 초기 렌더링: 루트 컴포턴트가 호출돰
- 리렌더링: React의 상태가 업데이트가 되면 렌더링을 트리거 한 해당 함수 컴포넌트가 호출된다’
이때 이 프로세스는 재귀적으로 발생한다.
업데이트된 컴포넌트가 다른 컴포넌트를 리턴하면 React는 해당 컴포넌트를 렌더링하고
그렇게 계속 재귀적으로 렌더링을 하면서 더 이상 중첩된 컴포넌트가 없을 시 해당 프로세스가 멈춘다.
이때 리렌더링일 경우에는 이전 렌더링과 비교해서 변경된 속성을 계산하고
커밋 단계 전까지 변경사항 계산 과정만 실행하고 실제 Dom에는 반영하지 않는다.
3. 커밋
컴포넌트 렌더링(호출) 이후에 React는 Dom을 수정한다.
이때 초기 렌러딩이후 상태 변경으로 발생하는 리렌더링 일때는, 이전에 레더링 단계에서 계산한 것처럼 변경된 요소만 Dom에 적용을 하게 된다.
마지막 브라우저 페인팅
이제 React가 Dom을 업데이트 한 이후에 브라우저 렌더링 과정이 실행된다, 이때 여기서 브라우저 페인팅이라고 한 이유는 위의 렌더링과 다른 단어를 쓰기 위해서 페인팅이라는 단어를 썼다
배운점 및 생각
리액트가 브라우저 렌더링을 위해서 어떤 과정을 거치는지 배운 것 같다.
내 생각으로는 리액트는 브라우저 렌더링을 좀 더 편하게 다루고 싶어서 해당 과정을 설계한듯하다
일단 과정이 계층화가 되어있다.
렌더링을 위한 트리거, 그리고 렌더링, 이후 dom에 반영같이 3단계로 계층화를 시킴으로써
각 계층이 해야 할 일을 명확히 할 수 있게 되고, 만약 버그 발생 시 어느 계층에서 문제가 발생된지 파악이 되어서 에러 수정을 좀 더 손쉽게 할 수 있지 않을까 생각이 든다.
게다가 이렇게 계층화를 함으로써 각 변경마다 dom에 반영 하는것이 아니라 상태와 렌더링을 분리 함으로써
프론트엔드에서의 상태관리를 좀더 쉽게할 수 있게 만든게 아닐까 생각된다.
또 생각해 보면, TCP/IP 구조도 그렇고, 기본적으로 어떠한 프로그램이든지, 설계의 구조가 커지게 되면 동작하는 구조를 계층화를 하는 것이 좋은 패턴이 아닐까 한다.
