Virtual DOM 등장 배경

브라우저 렌더링 과정

Reference: 브라우저 렌더링 원리에 대해 설명해주세요.

DOM 조작의 비효율성

위 과정을 전부 렌더링 될 때 마다 다시해줘야함. (여기서 DOM 트리를 생성하는 것이 비효율 적인게 아니라 렌더링 하는 과정이 비효율적이다!)

예전에는 SSR(Server Side Rendering)을 사용하여 서버에서 데이터와 함께 완전한 페이지를 렌더링 해줬다. DOM은 이러한 정적인 페이지를 보여주는 용도였기 때문에 DOM의 동적인 변화가 그렇게 큰 문제는 아니었다.

SPA의 등장과 함께 CSR(Client Side Rendering) 방식이 많이 사용되면서 현재는 DOM 업데이트가 상당히 많이 발생하게 된다.

DOM vs VirtualDOM

VirtualDOM은 DOM 노드 트리를 복제한 자바스크립트 객체이다. 쉽게 말하면 DOM의 가벼운 버전이다. → class, style등의 속성을 가지지만 DOM api 메서드(getElementById와 같은)를 가지지 않기 때문이다.

VirtualDOM의 동작 방식

1. 브라우저가 실제 DOM 트리를 생성하고 브라우저 화면에 우리의 어플리케이션 ui가 렌더링 된다.
2. 이때 Virtual DOM은 DOM 트리를 앞서 말했듯 가벼운 버전으로 복사한다.

1. DOM 노드에 변화가 생기면 Virtual DOM은 새로운 Virtual DOM을 생성한다.
   • 매번 VirtualDOM을 생성하더라도 메모리상에서 동작하고 렌더링을 하지 않기 때문에 비용이 그렇게 비싸지 않음.
2. Diff를 통해 변경된 부분만 체크한다 (PATCH)
3. RealDOM에 PATCH를 적용한다.

즉, 변화가 일어날 때마다 렌더링 하는 것이 아니라, 변화를 모두 모아서 한 번만 렌더링 하는 것이 핵심이다.

리액트에서 Virtual DOM

Render Phase

Reconciliation(재조정) → Previous VirtualDOM vs Current VirtualDOM 비교하여(Diffing 알고리즘 사용) Real DOM에 필요한 부분(PATCH) 체크

Diffing 알고리즘

Element들을 비교하게 되는데 Element는 (type, props) 두 가지 속성을 가진다.

const Element = {
	type: "h1"
	props: {
		title: "foo"
	},
}

Diffing 알고리즘은 두 가지 케이스로 분류된다.

1. type === type: 속성만 변경
2. type ≠ type: 트리를 재생성한다.

Commit Phase

Render Phase에서 체크했던 변경이 필요한 부분을 RealDOM에 반영해주는 부분이다. 만약, 변경이 필요한 부분이 없다면 Commit Phase는 스킵된다.

Reference

• https://www.youtube.com/watch?v=6rDBqVHSbgM&t=16s