리액트에서 Virtual DOM 사용하는 이유
리액트 이전
기존 웹페이지에서 서버와 통신하며 요청을 주고 받으면, 받은 데이터를 DOM 객체에 속성값들을 변화시키거나 DOM을 추가 또는 제거하도록 만들었습니다. 그리고 이러한 변경이 있을 때마다 DOM 객체의 변경에 대한 코드를 만들어줘야 했습니다. 뿐만 아니라 DOM 객체에 대한 연산이 많아질수록 reflow, repaint 연산이 많아지면서 브라우저가 컴퓨팅 자원을 많이 사용해야 했습니다.
reflow, repaint
reflow란 화면구조가 변경되었을 때 문서의 일부 또는 전체를 다시 렌더링하기 위해 문서에서 요소의 위치와 크기등의 형상을 다시 계산하는 것을 의미합니다. 대표적으로 화면의 크기 변화, 페이지 초기 렌더링, DOM의 동적 변화가 있는 경우 reflow가 발생합니다. 또한 경우에 따라서 문서의 단일 요소를 reflow하려면 상위 요소와 그 뒤에 오는 모든 요소를 reflow해야 할 수 도 있습니다.
repaint란 이름에서 알 수 있듯이 요소의 보이는 것에 영향을 주지만 레이아웃에는 영향을 주지 않는 요소 변경으로 화면에 다시 그려주는 작업입니다. reflow가 발생하면 변경된 렌더 트리를 화면에 다시 그려야해서 repaint가 발생합니다. 또한 레이아웃에 영향을 주지 않지만 color, background-color, visibility 등과 같은 스타일 속성의 변경에는 reflow는 발생하지 않고, repaint만 발생합니다.
살펴본 reflow, repaint는 컴퓨팅 파워를 많이 필요로 하는 비싼 작업입니다. reflow, repaint가 많이 일어날수록 하드웨어에 많은 부담을 주게 되고, 그 결과 사용자 경험이 나빠질 수 있습니다.
리액트의 문제 해결
이를 해결하기 위해 리액트는 Virtual DOM을 활용해 UI의 이상적인 “가상”적인 표현을 메모리에 저장하고 ReactDOM과 같은 라이브러리에 의해 “실제” DOM과 동기화 합니다. 이 과정을 재조정(Reconciliation)이라고 합니다.
이렇게 연산이 끝난 뒤 최종적인 변화를 실제 DOM에 반영해서 여러 번 reflow, repaint가 발생할 수 있는 작업을 한번으로 줄여줍니다. 또한, Virtual DOM은 변화에 대한 관리를 자동화하고 추상화해서 작업의 편의성을 제공합니다.
재조정에 대해 조금 더 알아보면, 기존에 하나의 트리를 가지고 다른 트리로 변환하기 위한 최소한의 연산 수를 구하는 최첨단 알고리즘도 n개의 엘리먼트가 있는 트리에 대해 O(n^3)의 복잡도를 가지고 있는 한계가 있었습니다. 이에 대해 리액트는 1) 서로 다른 두 엘리먼트는 서로 다른 트리를 만들어낸다. 2) 개발자가 key prop을 통해, 여러 렌더링 사이에서 어떤 자식 엘리먼트가 변경되지 않아야 할지 표시해 줄 수 있습니다. 두 가정을 기반하여 O(n) 복잡도의 비교 알고리즘을 구현했습니다.
참고 자료
https://blog.drakejin.me/React-VirtualDOM-And-Repaint-Reflow/
https://ko.legacy.reactjs.org/docs/faq-internals.html#gatsby-focus-wrapper
https://www.codeit.kr/learn/3799
https://medium.com/swlh/what-the-heck-is-repaint-and-reflow-in-the-browser-b2d0fb980c08
