1. 리액트 가상 돔 사용 이유
- 답변)
-
의도 : 리액트의 기본 원리와 가상 돔의 핵심을 이해하고 있는지,
그리고 가능하면 useState와의 관계성도 설명할 수 있는지 확인 -
모범 답안 : 실제 돔은 HTML의 요소를 트리로서 가지고 있는 객체 기반의 모델이며, 브라우저는 실제 돔을 기반으로 화면을 렌더링.
반면에 가상 돔은 실제 돔을 경량화한 복사본으로, 리액트의 최적화를 위해 사용.
실제 돔을 직접 조작하는 것은 성능 비용이 큰 작업이기 때문에, 리액트는 상태가 업데이트 될 때마다 우선 빠르고 가벼운 가상 돔을 업데이트하고, 결과를 실제 돔과 비교한다. 이후 변경된 부분만 실제 돔에 반영함으로써 불필요한 리소스 사용을 최소화하고 성능을 향상시킨다.이 과정을 가장 쉽게 살펴볼 수 있는 리액트의 메서드가
useState.
이를 통해 상태를 업데이트하면 상태 값이 곧바로 반영되지 않는데,
왜냐면 상태 업데이트는 그저 변수에 데이터를 담아내는 것이 아니라,
앞서 설명했던 가상 돔과 실제 돔의 비교 과정이 실행되기 때문이다.
상태 값이 자기 자신을 참조하여 상태를 업데이트할 때 생기는 오류는 대부분 여기서 기인한다. 이러한 문제를 해결하기 위해useState훅에 값이 아닌 콜백 함수의 참조를 인자로 전달할 수 있다.
-
실제 돔과 가상 돔 차이점
실제 돔 (Document Object Model)
: 브라우저가 HTML 문서를 파싱해서 생성하는 트리 구조의 객체 모델.
개발자가 돔 요소를 변경할 때마다 브라우저는 화면을 재렌더링(Repaint & Reflow)하는데, 이 과정은 매우 비용이 크다. 특히 많은 요소를 한 번에 조작하거나 업데이트를 자주 하면 성능 저하가 발생.
가상 돔 (Virtual DOM)
: 실제 돔을 경량화한 자바스크립트 객체 기반의 복사본.
상태나 데이터가 변경되면 리액트는 가상 돔을 우선 업데이트한다.
이후 변경된 가상 돔과 이전 가상 돔을 비교하는 Diffing 알고리즘을 사용해 차이점을 찾는다.
마지막으로 실제 돔에 변경된 부분만 반영(Reconciliation)하여 성능을 최적화한다.
비교 과정 예시
- 상태 업데이트가 발생 → 리액트가 새로운 가상 돔을 생성.
- 새로운 가상 돔과 이전 가상 돔을 비교 (Diffing).
- 변경된 부분만 찾아서 실제 돔에 반영 (Reconciliation).
- 브라우저가 변경된 돔만 렌더링 → 최소한의 리소스 사용으로 성능 최적화.
useState와 가상 돔의 관계
useState는 리액트의 상태 관리 훅으로, 컴포넌트의 상태를 변경할 수 있게 해주는데, 상태를 변경하는 과정이 가상 돔과 깊은 연관이 있다.
useState의 동작 순서
- useState를 통해 상태를 업데이트하면 리액트가 상태의 변경을 감지.
- 상태 변경 시 리액트는 가상 돔을 새로 생성.
- 새로운 가상 돔과 이전 가상 돔을 비교 (Diffing)해 차이점 찾음.
- 변경된 부분만 실제 돔에 업데이트 (Reconciliation).
- 화면 다시 렌더링.
왜 useState가 상태 업데이트를 즉시 반영하지 않을까?
useState를 사용하면 상태 값이 즉시 업데이트된 것처럼 보이지 않는 이유
: 리액트는 성능 최적화를 위해 비동기적으로 상태 업데이트를 처리한다.
상태가 변경될 때마다 가상 돔이 업데이트되고, 그 후에 실제 돔이 업데이트되기 때문이다. 이 과정에서 렌더링을 효율적으로 관리하려고 변경 사항을 배치(batch)하여 한 번에 처리하기도 한다.
이 문제를 해결하는 방법
: 상태 값을 바로 참조하여 업데이트하는 대신, useState의 콜백 함수 사용.
🖥️ javascript
setCount((prevCount) => prevCount + 1);
이처럼 콜백을 사용하면 이전 상태 값을 안전하게 참조해서 업데이트를 보장➡️ 실제 돔은 직접 조작할 때 성능 비용이 크지만,
리액트는 가상 돔을 통해 변경 사항 관리 효율적.
➡️ useState를 사용한 상태 업데이트는 가상 돔을 새로 생성하고 비교한 뒤,
최적화된 변경 사항만 실제 돔에 반영한다. 이를 통해 불필요한 렌더링을 최소화하고
