👉 React Fiber Architecture

Introduction

React Fiber는 React의 핵심 알고리즘을 지속적으로 재구현한 것입니다. 이것은 React 팀이 2년 넘게 연구한 결과입니다.

React Fiber의 목표는 애니메이션, 레이아웃 및 제스처와 같은 영역에 대한 적합성을 높이는 것입니다. 주요 주제은 증분 렌더링(incremental rendering) 입니다: 렌더링 작업을 chunk로 분할하고 여러 프레임에 분산시키는 기능입니다.

다른 주요 기능에는 새 업데이트가 들어올 때 작업을 일시 중지, 중단 또는 재사용하는 기능이 포함됩니다. 이외에도 다양한 유형의 업데이트에 우선 순위를 할당하는 기능과 새로운 동시성 모드를 위한 초기 작업들이 포함됩니다.

About this document

Fiber는 코드만 보고 파악하기 어려운 몇 가지 새로운 개념을 도입했습니다. 이 문서는 내가 React 프로젝트에서 Fiber의 구현을 따라가면서 작성한 메모들로부터 시작되었습니다. 문서의 양이 많아질수록 다른 사람들에게도 유용한 리소스가 될 수 있다는 것을 깨달았습니다.

핵심 용어를 명시적으로 정의하여 전문 용어를 사용하지 않고 가능한 가장 이해하기 쉬운 언어를 사용하려고 합니다. 그리고 가능한 외부 링크 많이 연결해두겠습니다.

저는 React 팀에 소속되어 있지 않으며 어떠한 권한을 갖고 말하지 않음을 알았으면 한다. 이것은 공식 문서가 아닙니다. 저는 React 팀원들에게 정확성을 검토하도록 요청했습니다.

그리고 이 문서는 진행 중인 작업입니다. Fiber는 완료되기 전에 상당한 리팩터링을 거칠 가능성이 높은 진행 중인 프로젝트입니다. 또한 여기에 디자인을 문서화하려는 시도도 진행 중입니다. 개선 및 제안을 환영합니다.

내 목표는 이 문서를 읽은 후 Fiber가 구현되는 과정을 따라갈 수 있을 만큼 충분히 잘 이해하고 결국에는 React에 다시 기여할 수 있게 되는 것입니다.

Prerequisites(전제 조건)

계속하기 전에 다음 리소스를 숙지하시기 바랍니다.

• React Components, Elements, and Instances: “Component”는 지나치게 다양하게 사용되는 단어입니다. 이런 용어에 대한 확고한 이해는 매우 중요합니다.
• Reconciliation(재조정): React의 재조정 알고리즘에 대한 높은 수준의 설명입니다.
• React Basic Theoretical Concepts: React의 개념적 모델에 대한 설명. 이 중 일부는 처음 읽을 때 이해가 되지 않을 수 있습니다. 괜찮습니다. 시간이 지나면 더 이해가 될 것입니다.
• React Design Principles: 스케줄링 섹션에 특히 집중해서 보세요. React Fiber의 why를 잘 설명하고 있습니다.

Review

아직 전제 조건 항목을 보기 전이라면 꼭 먼저 보길 바랍니다. 새로운 기능을 살펴보기 전에 몇 가지 컨셉을 살펴보겠습니다.

reconciliation(재조정)은 무엇입니까?

reconciliation

• React 알고리즘은 어떤 부분을 변경해야 하는지 결정하기 위해 한 트리를 다른 트리와 비교하는 데 사용합니다.

update

• React 애플리케이션을 렌더링하는 데 사용되는 데이터의 변경. 일반적으로 setState의 결과입니다. 결국 리랜더링 됩니다.

React API의 핵심 아이디어는 업데이트가 전체 앱을 리랜더링하는 것처럼 생각하는 것입니다. 이를 통해 개발자는 애플리케이션을 특정 상태에서 다른 상태로 효율적으로 전환하는 방법에 대해 고민하는 대신 선언적으로 추론할 수 있습니다. (A에서 B로, B에서 C로, C에서 A로 등)

실제로 매 변화가 있을 때마다 실제 앱을 리렌더링 하는 것은 정말 사소한(trivial) 앱에서나 가능한 일이다. 실제 앱에서는 성능 측면에서 엄청나게 비용이 많이 듭니다. React에는 뛰어난 성능을 유지하면서 전체 앱을 리렌더링하는 모양을 만드는 최적화 기능이 있습니다. 이러한 최적화의 대부분은 reconciliation(재조정)이라는 프로세스의 일부입니다.

재조정은 "가상 DOM(Virtual DOM)"으로 일반적으로 이해되는 알고리즘입니다. 높은 수준의 설명(high-level description)은 다음과 같습니다: React 애플리케이션을 렌더링하면 앱을 나타내는 노드 트리가 생성되어 메모리에 저장됩니다. 그런 다음 이 트리는 렌더링 환경으로 플러시됩니다. (예를 들어, 브라우저 애플리케이션의 경우 DOM 작업 형태로 변환됩니다.) 앱이 업데이트되면(일반적으로 setState를 통해) 새 트리가 생성됩니다. 새 트리는 렌더링된 앱을 업데이트하는 데 필요한 작업을 계산하기 위해 이전 트리와 비교됩니다.

Fiber는 조정자(reconciler)를 처음부터 재작성한 것이지만, React 문서에 설명된 고급 알고리즘은 대체로 동일합니다. 여기서 키 포인트는 다음과 같습니다:

• 다른 컴포넌트 타입은 실질적으로 다른 트리를 생성한다고 가정합니다. React는 그것들을 비교하려고 시도하지 않고 이전 트리를 완전히 교체합니다.
• 리스트 비교는 키를 사용하여 수행됩니다. 키는 "안정적이고 예측 가능하며 고유해야 합니다."

Reconciliation vs rendering(재조정 vs 렌더링)

DOM은 React가 렌더링할 수 있는 렌더링 환경 중 하나일 뿐이며, 이외에도 React Native를 통한 기본 iOS 및 Android 보기(views)입니다. (이것이 "가상 DOM"이 약간 잘못된 이름인 이유입니다.)

이렇게 많은 대상을 지원할 수 있는 이유는 React가 재조정과 렌더링이 별도의 단계로 설계되었기 때문입니다. 조정자(reconciler)는 트리의 어떤 부분이 변경되었는지 계산하는 작업을 수행합니다. 그런 다음 렌더러(renderer)는 해당 정보를 사용하여 렌더링된 앱을 실제로 업데이트합니다.

이러한 분리는 React DOM과 React Native가 React 코어에서 제공하는 동일한 조정자(reconciler)를 공유하면서 자체 렌더러(renderer)를 사용할 수 있음을 의미합니다.

Fiber는 조정자를 다시 구현합니다. 렌더링 과정에는 크게 관여하지 않지만, 렌더러가 새로운 아키텍처를 지원하고 활용하기 위해 변화해야합니다.

Scheduling

scheduling(스케쥴링)

• 작업을 수행해야 하는 시기를 결정하는 프로세스입니다.

work(작업)

• 수행해야 하는 모든 계산. 작업은 일반적으로 업데이트(예: setState)의 결과입니다.

React의 디자인 원칙 문서는 이 주제에 대해 너무 잘 작성되어 있어서 그대로 인용하도록 하겠습니다.

현재 구현에서 React는 재귀적으로 트리를 탐색하고 한 번의 틱(tick) 동안 전체 업데이트된 트리의 렌더링 함수를 호출합니다. 그러나 미래에 프레임 드롭을 방지하기 위해 일부 업데이트가 지연될 수 있습니다.
이것은 React 디자인의 공통 주제입니다. 일부 인기있는 라이브러리는 새 데이터를 사용할 수 있을 때 계산이 수행되는 "push" 접근 방식을 구현합니다. 그러나 React는 계산이 필요할 때까지 지연될 수 있는 "당기기(pull)" 접근 방식을 고수합니다.
React는 제네릭한(generic / 일반적인) 데이터 처리 라이브러리가 아닙니다. React는 사용자 인터페이스를 구축하기 위한 라이브러리입니다. 우리는 현재 어떤 계산이 관련이 있고 그렇지 않은지 알 수 있는 것이 앱에서 고유한 위치에 있다고 생각합니다.
무언가가 화면 밖에 있는 경우 관련 로직을 지연시킬 수 있습니다. 만약 데이터가 프레임 속도보다 빠르게 도착하면 병합하고 업데이트를 일괄 처리할 수 있습니다. 프레임 손실을 방지하기 위해 덜 중요한 백그라운드 작업(예: 네트워크에서 방금 로드된 새 콘텐츠 렌더링)보다 사용자 상호 작용에서 발생하는 작업(예: 버튼 클릭으로 인한 애니메이션)에 우선순위를 둘 수 있습니다.

키포인트는 다음과 같습니다.

• UI에서 모든 업데이트를 즉시 적용할 필요는 없습니다. 실제로 그렇게 하면 낭비가 될 수 있으며 프레임이 떨어지고 사용자 경험(user experience)이 저하될 수 있습니다.
• 업데이트 유형에 따라 우선 순위가 다릅니다. 예를 들어 애니메이션 업데이트는 데이터 저장소(data store)의 업데이트보다 더 빨리 완료되어야 합니다.
• 푸시 기반(push-based) 접근 방식을 사용하려면 앱(당신, 프로그래머)이 작업 예약 방법(how to schedule work)을 결정해야 합니다. 풀 기반(pull-based) 접근 방식을 사용하면 프레임워크(React)가 똑똑하게 이러한 결정을 내릴 수 있습니다.

React는 현재 중요한 방식으로 스케줄링의 장점을 활용하지 못합니다. 업데이트하면 전체 하위 트리가 즉시 리렌더링됩니다. 스케줄링을 활용하기 위해 React의 핵심 알고리즘을 정비하는 것이 Fiber의 핵심 아이디어입니다.

---

이제 Fiber 구현에 대해 자세히 알아볼 준비가 되었습니다. 다음 섹션은 지금까지 논의한 것보다 더 기술적인 부분입니다. 계속 진행하기 전에 이전 자료에 익숙해졌는지 확인하세요.

• https://github.com/acdlite/react-fiber-architecture
• https://blog.kiprosh.com/react-fiber/