지금까지는 간단하게 리액트를 알아봤지만, 여기선 조금 더 추상적인 개념들을 작성해보겠다.
Component
컴포넌트는 리액트의 핵심 빌딩 블록 중 하나로 UI 요소를 표현하는 최소한의 단위이며 화면의 특정 부분이 어떻게 생길지 정하는 선언체이다. 즉, 리액트에서 개발할 모든 애플리케이션은 컴포넌트라는 조각으로 구성된다는 것! 컴포넌트는 UI 구축 작업을 훨씬 쉽게 만들어준다.
컴포넌트를 생성하고 보여지고자 하는 UI 요소를 컴포넌트 내부에서 JSX를 통해 선언하면 이를 리액트가 화면에 그려주었다. 리액트 컴포넌트가 선언체라는 개념은 아주 중요하다.
그 이유는 리액트의 컴포넌트기반 개발 이전에는 브라우저에서 동적으로 변하는 UI를 표현하기 위해 직접 DOM 객체를 조작하는 명령형 프로그래밍 방식으로 구현했다. 그렇다면 기존 명령형 프로그래밍과 리액트 컴포넌트의 선언적 프로그래밍은 어떻게 다를까?
명령형(DOM)은 어떻게 중요시여겨서 프로그램의 제어의 흐름과 같은 방법을 제시하고, 목표를 명시하지 않는 형태이다.
선언형(리액트)은 무엇을 중요시 여겨서 제어의 흐름보다는 원하는 목적을 중요시 여기는 형태이다.
명령형으로 작성된 코드의 경우 Hello, World!를 출력하기 위해 컴퓨터가 수행하는 절차를 일일히 코드로 작성해주어야 한다.
리액트 코드는 어떨까?
리액트 코드의 경우 내가 UI를 선언하고 render() 를 호출하면 알아서 절차를 수행해 화면에 출력해준다.
즉, 화면에 어떻게 그려야할지는 React 내부에 잘 숨겨져 추상화되어 있다.
DOM을 직접 조작하여 명령형 프로그래밍 방식으로 작성하던 코드가 나쁘다는 것은 아니다.
카운터 예시와 같이 격리된 예제에서는 차라리 리액트와 같은 UI 라이브러리를 사용하지 않고 만드는게 더 빠르고 전체적인 번들 사이즈 측면에서도 더 효율적인 방법일 수 있다. 하지만 더 복잡한 UI 시스템에서는 관리하기가 기하급수적으로 어려워진다.
Rendering
리액트에서 랜더링이란, 컴포넌트가 현재 props와 state의 상태에 기초하여 UI를 어떻게 구성할지 컴포넌트에게 요청하는 작업을 의미한다.
컴포넌트를 주방에서 요리하는 주방장이라고 생각해보자.
리액트는 손님으로부터 주문을 받아 주방에 전달하고 완성된 요리를 손님에게 서빙하는 웨이터로 가정해보겠다. 그리고 손님이 주문하고 주방장이 만드는 것이 요리가 아닌 UI라고 하자.
- UI - 음식
- 컴포넌트 - 음식을 만드는 주방장
- 리액트 - 웨이터
라고 할 때, 렌더링이 일어나는 프로세스를 아래와 같이 설명할 수 있다.
- 렌더링을 일으키는 것은 (triggering) - UI를 주문하고 주방으로 전달하는 것
- 렌더링한다는 것은 (rendering) - 주방에서 컴포넌트가 UI를 만들고 준비하는 것
- 렌더링 결과는 실제 DOM에 커밋한다는 것은 (commit) - 리액트가 준비된 UI를 손님 테이블에 올려놓는 것
1. 렌더링 트리거
렌더링이 발생하는 경우는 언제일까?
1. 첫 리액트 앱을 실행했을 때
2. 현재 리액트 내부의 어떤 상태(state)에 변경이 발생했을 때
- 컴포넌트 내부 state가 변경되었을 때
- 컴포넌트에 새로운 props가 들어올 때
- 상위 부모 컴포넌트에서 위의 두 이유로 렌더링이 발생했을 때
리액트 앱이 실행되고 첫 렌더링이 일어나면 리액트는 컴포넌트의 루트에서 시작하여 아래쪽으로 쭉 훑으며 컴포넌트가 반환하는 JSX 결과물을 DOM 요소에 반영한다.
2. 리렌더링
첫 렌더링은 자동으로 일어난 것이었다. 리액트 앱이 실행되면 리액트는 전체 컴포넌트를 렌더링하고 결과물을 DOM에 반영해 브라우저상에 보여준다. 첫 렌더링이 끝난 이후에 추가로 렌더링을 트리거 하려면 상태(state)를 변경해주면 된다.
+setState 함수만을 다뤘지만 몇 가지가 더 있는데 뒤에서 다루겠다!
암튼.. 컴포넌트 상태에 변화가 생기면 리렌더링이 발생한다. 이 때 여러 상태가 변경됐다면 리액트는 이를 큐 자료구조에 넣어 순서를 관리한다.
1. 주방 예시를 다시 들면, 리렌더링은 음식점 손님이 첫 주문 이후에 갈증이 생겨 추가로 음료를 주문하거나 처음 받은 음식이 마음에 들지 않아 새로운 메뉴를 주문하는 것과 같다.
2. 새로운 UI주문 (=리렌더링)이 일어나면 리액트가 변경된 내용을 주방에 있는 요리사(=컴포넌트)에게 전달하고 컴포넌트는 새롭게 변경된 주문을 토대로 새로운 요리(=UI)를 만든다.
3. 새롭게 만들어진 요리(=렌더링 결과)는 리액트에 의해 다시 손님 테이블에 올려진다.
(DOM에 반영 - commit phase).
3. 브라우저 렌더링
브라우저 렌더링 != 리액트 렌더링.. 엄연히 다른 독립적인 프로세스이다.
렌더링이 완료되고 React가 DOM을 업데이트 한 후 브라우저는 화면을 그린다. 이 프로세스를 브라우저 렌더링 이라고 하지만, 혼동을 피하기 위해 페인팅 이라고도 한다.
