-
1. 기존 DOM의 문제가 뭐길래?
- 브라우저가 html을 받아서 그릴때, SPA에서 화려한(?) User Interaction을 위해서 DOM 조작을 할 때 무슨일이 일어날까?
- 처음 HTML을 받은 경우에는 이를 파싱해서 DOM Node로 이뤄진 트리를 만든다. 이 Node는 각각 HTML element에 대해 존재한다.
- DOM Tree와 css 등 스타일 문서를 통해 Node에 그 Node의 스타일을 붙여주고, 이런 렌더링 정보를 담고있는 Render Tree를 만든다.
- Render Tree를 만드는데에 많은 computing이 필요하다. 스타일 문서를 파싱하는것부터 시작해서...
- 만들어진 Render Tree를 통해 실제 화면의 어느 자리에 위치할지 계산하는 레이아웃 과정을 거치면
- 실제 화면에 각 Node들을 painting 한다.
- 여기서 문제점은 모든 DOM 조작에 대해 위 computing 과정이 거쳐진다는 것이다.
- a 노드 변화 -> DOM 조작 실행 -> 화면 렌더링 위해 스타일, 레이아웃 관련 computing -> 렌더링
b 노드 변화 ...
c 노드 변화 ...
- 만약 a, b, c 변화가 세트로 이뤄져서 사용자가 볼 때 a, b, c를 한 그룹으로 묶어서 변화시켜도 문제 없는 거라면?
- 어쩌면 유저가 불편함을 느끼지 않는 선에서 DOM 변화에 대해 중간에서 버퍼링을 하고, 어떤 단위의 윈도우만큼씩 DOM에 반영(리 컴퓨팅, 리 렌더링 포함)하면 되는거라면?
- 그런걸 위해서 Virtual DOM이 있다.
- Virtual DOM은
- 실제 브라우저가 n개의 변화에 대해 n번 computing, n번 렌더링 하게 하지 않기위해 존재하는 중간 버퍼
- node 변화들을 묶어서 Virtual DOM tree에 반영하면, 실제 브라우저는 그 다음 화면에 보여줄 것을 한번만 computing 하고 한번만 rendering 하면 된다.
- 즉 유저 입장에서 화면 A를 보고 있다가 버튼을 눌러서 화면 B를 보게 되는 시나리오가 있다 하자.
- 원래대로라면 화면 A에서 화면 B가 되는 과정에서 변경되는 노드 n개에 대해 n번 (computing + rendering)이 필요하다.
- 그러나 virtual DOM과 함께라면, B가 되기 위한 연산을 다 하고 바뀌는 노드 n개를 모두 Virtual DOM에 반영한 후 새로운 한 벌의 Virtual DOM을 브라우저의 DOM에 보여주면서 이렇게 그려~ 라고 하면 되는것이다.
- 이렇게 되면 1번만 (computing + rendering) 하면 된다.
- 대신 변화되는 양이 많다보니 computing과 rendering이 각각 많아지긴 하겠지.
- 즉 Virtual DOM은 SPA에서 렌더링을 최적화하기위한 것이다~