Virtual DOM

VirtualDOM에 대해서 알아보기 전에 브라우저가 어떻게 작동하는지 먼저 알아 봅시다

쉽게 생각하면 html과 css를 합치고 화면에 나올 수 있게 배치한 후 출력한다

DOM Tree 생성

브라우저가 HTML을 전달 받으면, 브라우저의 렌더 엔진이 이를 파싱하고 DOM노드로 이뤄진 트리를 만듭니다

각 노드는 각 HTML 엘리먼트들과 연관되어있습니다

Render Tree 생성

그 후 외부 css파일과 각 엘리먼트의 inline 스타일을 파싱합니다.

스타일 정보를 사용하여 DOM트리에 따라 새로운 트리, 렌더트리를 만들어요

Render Tree 생성 -그 뒤에선 무슨일이 일어나고 있는가

Webkit에서는 노드의 스타일을 처리하는 과정을 'attachment'라고 부릅니다.

DOM트리의 모든 노드들은 'attach'라는 메소드가 있습니다

이 메소드는 스타일 정보를 계산하여 객체 형태로 반환합니다.

이 과정은 동기적 작업이며, DOM트리에 새로운 노드가 추가되면 그 노드의 attach메소드가 실행됩니다

렌더 트리를 만드는 과정에선, 각 요소들의 스타일이 계산 되고, 이 계산되는 과정에서 다른 요소들의 스타일 속성들을 참조합니다.

Layout 

렌더 트리가 다 만들어지고 나면, 레이아웃 과정을 거칩니다

각 노드들은 스크린의 좌표가 주어지고. 정확히 어디에 나타나야 할 지 위치가 주어집니다

Painting

그 다음 작업은 렌더링 된 요소들에 색을 입힙니다

트리의 각 도드들을 거쳐가면서 paint()메소드를 호출하게 되면 스크린에 원하는 정보가 나타납니다

 DOM 조작의 실제 문제는 각 조작이 레이아웃 변화, 트리 변화와 렌더링을 일으킨다는겁니다.

 예를 들어 30개의 노드를 하나 하나 수정하면, 그 뜻은 30번의 (잠재적인) 레이아웃 재계산과 30번의 (잠재적인) 리렌더링을 초래한다는 것이죠.

이런 경우 VirtualDOM이 빛을 발합니다

그럼 VirtualDOM이란?

 변화가 일어나면 그걸 오프라인 DOM 트리에 적용을 시킵니다. 

 이 DOM 트리는 렌더링도 되지 않기때문에 연산 비용이 적습니다. 

 연산이 끝나고나면 최종적으로 변경사항이 적용된 가상 DOM트리를 DOM에 던집니다

 레이아웃 계산과 리렌더링의 규모는 커지겠지만, 한번만 랜더링이 되기 때문에 연산의 횟수가 줄어듭니다

변화가 있을 때, 그 변화를 묶어서 DOM fragment 에 적용한 다음에 기존 DOM 에 던져주는 방법으로 

Virtual DOM 이 없이도 이뤄질수 있습니다

그럼에도 Virtual DOM을 사용하는 이유는 DOM fragment를 관리하는 과정을 수동으로 하나하나 작업 할 필요 없이, 자동화하고 추상화하기 때문입니다. 또한 DOMfragment를 사용한다면 기존 값 중 어떤게 바뀌었고 어떤게 바뀌지 않았는지 계속 파악하고 있어야하는데 (그렇지 않으면 수정 할 필요가 없는 DOM 트리도 업데이트가 될 수 있음), Virtual DOM 이 이걸 자동으로 해주는거에요. 어떤게 바뀌었는지 , 어떤게 바뀌지 않았는지 알아내주죠.

마지막으로, DOM 관리를 Virtual DOM 이 하도록 함으로써, 컴포넌트가 DOM 조작 요청을 할 때 다른 컴포넌트들과 상호작용을 하지 않아도 되고, 특정 DOM 을 조작할 것 이라던지, 이미 조작했다던지에 대한 정보를 공유 할 필요가 없습니다. 즉, 각 변화들의 동기화 작업을 거치지 않으면서도 모든 작업을 하나로 묶어줄 수 있습니다.

참고 :  https://velopert.com/3236