[React] 리액트 기술 면접 핸드북 I - virtual DOM, react fiber etc.

1. 리액트는 라이브러리인가 프레임워크인가
2. 리액트를 사용하는 이유
3. virtual DOM이란
4. 리액트 렌더링
5. 리액트 파이버 
6. 리액트 파이버 트리
7. 리액트 파이버, DOM 그리고 virtual DOM의 관계
8. 렌더 단계와 커밋 단계

---

1. 리액트는 라이브러리인가 프레임워크인가 ⭐️

• 라이브러리
  • 특정 기능에 대한 API(도구/함수)를 모은 집합
• 프레임워크
  • Application 개발시 코드의 품질, 필수적인 코드, 알고리즘, 암호화, 데베 연동 같은 기능들을 어느 정도 구성이 되어있는 뼈대(구조)를 제공하도록 만들어진 것
• 라이브러리 vs. 프레임워크
  • 라이브러리를 사용하는 애플리케이션 코드는 애플리케이션 흐름을 직접 제어함
  • 단지 동작하는 중에 필요한 기능이 있을 때 능동적으로 라이브러리를 사용할 뿐임
    
    
  • 프레임워크는 거꾸로 애플리케이션 코드가 프레임워크에 의해 사용됨
  • 프레임워크에는 분명한 제어의 역전 개념이 적용되어 있어야 함
  • 애플리케이션 코드는 프레임워크가 짜놓은 틀에서 수동적으로 동작해야함
• 결론!
  • 어플리케이션의 흐름을 누가 제어하느냐에 따라 프레임워크인지 라이브러리인지 구분할 수 있음

 

2. 리액트를 사용하는 이유 ⭐️⭐️

• 컴포넌트 기반의 화면 구성
  • 리액트는 화면의 한 부분을 컴포넌트라는 단위로 나눌 수 있으며 독립적으로 관리할 수 있다
  • 대규모 웹 애플리케이션에서 컴포넌트는 역할과 기능에 따라 따로 관리하기 용이하며, 반복되는 부분을 대체할 수 있게 해주어서 코드 재사용성을 높여준다.
  • 또한 컴포넌트 기반의 화면을 구성한다면 블록 쌓기처럼 컴포넌트를 쌓아서 빠르고 효율적으로 화면을 구성할 수 있다.
• virtual Dom으로 인한 충분히 빠른 속도
  • virtual Dom은 UI의 이상적인 또는 "가상"적인 표현을 메모리에 저장하고 ReactDOM과 같은 라이브러리에 의해 "실제" DOM과 동기화하는 프로그래밍 개념(이 과정을 재조정(reconciliation)이라고 함)
  • 이 접근 방식이 React의 선언적 API를 가능하게 함
• SPA(싱글 페이지 어플리케이션)
  • 장점: 서버 자원 아낄 수 있고 더 좋은 사용자 경험을 누릴 수 잇음
  • 단점: 사용자와 인터렉션이 많은 경우에는 서버의 자원이 많이 사용되고 불필요한 트래픽이 낭비 될 수도
• 결론!
  • 컴포넌트를 사용해서 유지보수가 용이함(필요한 부분의 컴포넌트만 렌더링됨. 최적화된 렌더링 가능)
  • virtual DOM 활용해서 빠른 렌더링 가능

 

3. virtual DOM이란 ⭐️⭐️

• DOM(Document Object Model)
  • XML 이나 HTML 문서에 접근하기 위한 일종의 인터페이스
  • 문서의 구조화된 표현(structured representation)을 제공, 프로그래밍 언어가 DOM 구조에 접근할 수 있는 방법을 제공해 문서 구조, 스타일, 내용 등을 변경할 수 있게 도움
  • 새로운 요청이 있으면 `HTTP response > DOM tree > CSSOM tree > render tree > painting` 형태를 거처 리렌더링을 하게 됨
  • DOM의 속도는 느리지 않지만 매번 새롭게 구성하기 때문에 양이 많으면 퍼포먼스가 떨어짐 
  • 그래서 Virtual DOM이 나이스하다!
• virtual DOM
  • DOM에 접근해 조작하는 것을 추상화한 자바스크립트 객체를 구성해 사용(실제 DOM의 가벼운 사본과 비슷함) → 업데이트 처리 간결성 제공
  • 리액트에서 데이터가 변하여 웹 브라우저에 실제 DOM을 업데이트할 때 다음 세 가지 절차를 밟음
    ① 전체 UI를 virtual DOM에 리렌더링
    ② 이전 내용과 현재 내용 비교
    ③ 바뀐 부분만 실제 DOM에 적용
  • virtual DOM 사용한다고 해서 무조건 빠른 건 아님(지속적으로 데이터가 변화하는 대규모 애플리케이션 구축에 유용)

 

4. 리액트 렌더링

• 브라우저 렌더링
  • HTML과 CSS 리소스를 기반으로 웹페이지에 필요한 UI를 그리는 과정
• 리액트 렌더링
  
  • 브라우저가 렌더링에 필요한 DOM 트리를 만드는 과정 → 브라우저 렌더링보다 먼저 실행됨
  • 리액트 애플리케이션 트리 안에 있는 모든 컴포넌트들이 현재 자신이 가지고 있는 props과 state의 값을 기반으로 어떻게 UI를 구성하고 이를 바탕으로 어떤 DOM 결과를 브라우저에 제공할 것인지 계산하는 일련의 과정임

 

5. 리액트 파이버

• 리액트 파이버
  • 리액트에서 관리하는 평범한 자바스크립트 객체
  • 파이버 재조정자(fiber reconciler)가 관리하는데, 가상 DOM과 실제 DOM을 비교해 변경 사항을 수집하며, 만약 둘 사이에 차이가 있으면 변경에 관련된 정보를 가지고 있는 파이버 기준으로 화면에 렌더링을 요청하는 역할
  • 리액트 앱에서 발생하는 애니메이션, 레이아웃, 사용자 인터렉션에 올바른 결과물을 만드는 반응성 문제를 해결하는 것이 목표
  • 모든 과정은 비동기로 일어나고, 작업을 스케줄링하기도 함

 

6. 리액트 파이버 트리 

• current fiber tree
  • 현재 화면에 렌더링되어 있는 UI 상태(실제 DOM의 현재 모습을 가상적으로 표현)
  • 트리 노드들은 실제 DOM 노드와 1:1 대응 관계를 가짐
• workInProgress fiber tree
  • 다음 렌더링 작업 시 업데이트될 UI 상태를 계산하기 위해 사용
  • virtual DOM의 역할을 함. 여기서 새로운 virtual DOM 트리가 생성되고 계산됨
• 리액트 파이버의 작업이 끝나면 리액트는 단순히 포인터만 변경해 workInProgress fiber tree를 current fiber tree로 바꿈(더블 버퍼링)

 

7. 리액트 파이버, DOM 그리고 virtual DOM의 관계

• current fiber tree는 현재 상태를 나타내고 workInProgress fiber tree는 virtual DOM의 역할을 해 다음 렌더링 작업을 계산함
• Reconciliation 과정을 거쳐 변경 사항만 실제 DOM에 반영되고 workInProgress fiber tree가 새로운 current fiber tree가 됨
  
  
• Reconciliation 과정
  • current fiber tree와 workInProgress fiber tree를 비교해 변경된 부분 찾기

 

8. 렌더 단계와 커밋 단계

• 렌더 단계(Render Phase)
  • virtual DOM 트리의 변경 사항을 계산하고 메모리에 새로운 virtual DOM 트리를 생성하는 단계
  • 메모리 안에서 이루어지며 실제 DOM에는 아무런 변화가 일어나지 않음
• 커밋 단계(Commit Phase)
  • 렌더링 단계에서 계산된 변경 사항을 실제 DOM에 반영하는 단계
  • 필요한 DOM 노드를 메모리에 추가, 변경 및 제거함
  • 이벤트 핸들러 등의 업데이트도 수행
  • 커밋 단계가 완료되면 변경된 DOM이 화면에 반영됨
• 렌더링와 커밋 단계를 분리함으로 react는 성능을 최적화함
  • 메모리 상에서 렌더링 작업을 수행하므로 DOM 작업에 비해 빠름
  • 실제 DOM 변경을 최소한으로 유지되어 느린 DOM whwkrdmf wnfdla
  • 렌더링 단계에서 업데이트 로직을 중단할 수 있어 사용자 상호작용에 더욱 반응적임