Virtual Dom에 대해서

1. DOM?

• HTML, XML 다큐먼트와 상호작용하고 표현하는 API
• 브라우저에서 로드되며 노드, 트리로 표현된다.
• HTML이 돔은 아님
• JS와 같은 스크립팅 언어를 이용해서 해당 문서에 노드 추가, 삭제, 변경 , 이벤트처리 등 수정

  document.getElementByid... : DOM API 썼다.

2. 왜 VD를 접목했을까? => DOM의 문제점 파악하자.

작동 원리

1. 돔트리 생성
2. 렌더트리 생성 : 각 요소들의 스타일이 계산 & 매칭
   3 .레이아웃 : 스크린의 좌표가 주어지고 정확한 위치로 배치되게.
3. 페인팅 : 렌더링된 요소에 색깔 입힌다. 메서드로 됨.

문제점? :

• 복잡해지는 구조, 사용자의 인터렉션 등
• 웹사이트들이 복잡해지면서 위와 같은 과정 횟수가 늘어서 비효율적

  e.g. 30개의 노드를 하나 하나 수정하면 30번의 레이아웃 재계산과 30번의 리렌더링이 일어남...

3. VD의 등장

일종의 돔 캐싱, 돔의 연산 횟수는 줄어들긴 함, 뷰에 변화가 있을 때 실제 돔에 적용되기 전에 가상 돔에 먼저 적용시키고 실제 최종 결과를 실제 돔으로 전달 브라우저 내에서 발생하는 연산 양을 줄여준다.

오해 : 리액트가 돔보다 빨라서 사용한다는 잘못된 사실이다.

그럼에도 사용하는 이유 :

• 직접 수동으로 하나하나 작업할 필요 없이 자동화하고 추상화 해주기 때문.(수동이 더 빠르긴 함, but 비용...)

아래 내용은 참고하기

4. setState로만 값을 변경해줘야하는 이유(불변성 유지 이유)

• 값이 변경 되었다는 걸 판단하기 위해 리액트는 객체로된 state를 비교연산
• 겍체 비교시 근거는 메모리 주소. 직접 값을 수정하면 감지 못 함.
• map, filter, spread 문법 사용해서 새로운 배열을 반환하는 이유도 이 때문.

5. props로 key를 넘겨줘야 하는 이유

• (유니크 키 프롭스 에러) 고유한 키값이 없다면 모든 데이터를 비교해야 하지만 키가 있으면 키값만 비교하여 키가 추가됐는지, 삭제 됐는지만 비교하면 돼서 불필요한 렌더링 줄임.