react-fiber-architecture

KO | EN

gitlite — search

#hacktoberfest #ai #golang #go #android #rust #java #awesome #kubernetes #vue #pytorch #security #mcp #ios

react-fiber-architecture

(★ 13,005)

React의 새로운 핵심 알고리즘인 React Fiber에 대한 설명

파일 탐색기

최종 버전 다운로드 (.zip)

README.md

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

# React Fiber Architecture

## Introduction

React Fiber는 React 핵심 알고리즘을 지속적으로 재구현하는 프로젝트입니다. 이는 React 팀이 2년 이상 동안 진행해 온 연구의 결정체입니다.

React Fiber의 목표는 애니메이션, 레이아웃, 제스처와 같은 영역에 대한 적합성을 높이는 것입니다. 핵심 기능은 바로 **증분 렌더링(incremental rendering)**으로, 렌더링 작업을 여러 청크로 나누어 여러 프레임에 걸쳐 분산시키는 능력입니다.

기존에 진행 중이던 작업에 새로운 업데이트가 들어올 때 작업을 일시 중지, 중단 또는 재사용하는 기능, 서로 다른 유형의 업데이트에 우선순위를 부여하는 기능, 그리고 새로운 동시성(concurrency) 프리미티브가 다른 주요 기능에 포함됩니다.

### About this document

Fiber는 코드만 보고는 온전히 이해하기 어려운 몇 가지 새로운 개념들을 도입합니다. 이 문서는 제가 React 프로젝트에서 Fiber 구현 과정을 따라가며 작성한 메모 모음에서 시작되었습니다. 문서가 커짐에 따라 다른 사람들에게도 유용한 리소스가 될 수 있겠다는 깨달음을 얻었습니다.

가능한 한 가장 평이한 언어를 사용하고, 핵심 용어를 명시적으로 정의하여 전문 용어를 피하고자 노력할 것입니다. 또한 가능하면 외부 리소스에 대한 링크도 적극적으로 첨부하겠습니다.

저는 React 팀 소속이 아니며, 어떠한 권위를 가지고 이야기하는 것이 아님을 유념해 주세요. **이는 공식 문서가 아닙니다.** 정확성을 검토해 달라고 React 팀 멤버들에게 요청한 바 있습니다.

이 문서는 또한 현재 진행 중인 작업입니다. **Fiber는 완료되기 전에 상당한 리팩토링을 거칠 가능성이 높은 진행 중인 프로젝트입니다.** 여기에 그 설계를 문서화하려는 저의 시도 역시 현재 진행형입니다. 개선 사항과 제안은 언제든지 환영합니다.

제 목표는 이 문서를 읽고 나면 [구현 과정을 따라갈 수 있을](https://github.com/facebook/react/commits/master/src/renderers/shared/fiber) 만큼 Fiber를 잘 이해하게 되고, 결과적으로 React에 다시 기여할 수 있게 되는 것입니다.

### Prerequisites

계속 진행하기 전에 다음 리소스들에 익숙해지는 것을 강력히 추천합니다:

- [React Components, Elements, and Instances](https://facebook.github.io/react/blog/2015/12/18/react-components-elements-and-instances.html) - "Component"는 종종 여러 의미로 혼용되는 용어입니다. 이러한 개념을 확실히 이해하는 것이 매우 중요합니다.
- [Reconciliation](https://facebook.github.io/react/docs/reconciliation.html) - React의 재조정(reconciliation) 알고리즘에 대한 고수준 설명.
- [React Basic Theoretical Concepts](https://github.com/reactjs/react-basic) - 구현에 대한 부담 없이 React의 개념적 모델을 설명합니다. 처음 읽을 때는 이해가 가지 않을 수도 있습니다. 괜찮습니다. 시간이 지나면 더 명확해질 것입니다.
- [React Design Principles](https://facebook.github.io/react/contributing/design-principles.html) - 스케줄링(scheduling)에 관한 섹션에 특히 주의를 기울이세요. React Fiber의 \*이유(why)\*를 설명하는 데 훌륭한 역할을 합니다.

## Review

아직 사전 요구 사항 섹션을 확인하지 않으셨다면 확인해 주시기 바랍니다.

새로운 내용을 살펴보기 전에 몇 가지 개념을 복습해 보겠습니다.

### What is reconciliation?

reconciliation
:   어떤 부분을 변경해야 하는지 결정하기 위해 React가 하나의 트리와 다른 트리를 비교(diff)하는 데 사용하는 알고리즘.

update
:   React 앱을 렌더링하는 데 사용되는 데이터의 변경 사항. 보통 `setState`의 결과로 발생하며, 궁극적으로 리렌더링을 유발합니다.

React API의 핵심 아이디어는 업데이트가 마치 전체 앱을 다시 렌더링하는 것처럼 동작한다고 생각하는 것입니다. 이를 통해 개발자는 앱을 특정 상태에서 다른 상태로(A에서 B로, B에서 C로, C에서 A로 등) 효율적으로 전환하는 방법에 대해 고민하는 대신, 선언적으로 사고할 수 있습니다.
실제로 변경이 일어날 때마다 앱 전체를 다시 렌더링하는 방식은 가장 단순한 앱에서만 작동하며, 실제 앱에서는 성능 비용이 너무 커서 사용할 수 없습니다. React에는 훌륭한 성능을 유지하면서도 앱 전체가 다시 렌더링되는 것처럼 보이게 만드는 최적화 기능이 있습니다. 이러한 최적화의 대부분은 \*\*재조정(reconciliation)\*\*이라고 하는 프로세스의 일부입니다.
재조정은 대중적으로 "가상 DOM(virtual DOM)"이라고 이해되는 개념의 이면에 있는 알고리즘입니다. 고수준에서 설명하자면 다음과 같습니다: React 애플리케이션을 렌더링할 때, 앱을 설명하는 노드 트리 가 생성되어 메모리에 저장됩니다. 이 트리는 렌더링 환경으로 전달됩니다. 예를 들어 브라우저 애플리케이션의 경우, 일련의 DOM 작업으로 변환됩니다. 앱이 업데이트되면(보통 `setState`를 통해) 새로운 트리가 생성됩니다. 렌더링된 앱을 업데이트하는 데 어떤 작업이 필요한지 계산하기 위해 새 트리를 이전 트리와 비교(diffing)합니다.
Fiber는 재조정자를 처음부터 새로 작성한 것이지만, [React 문서에 설명된](https://facebook.github.io/react/docs/reconciliation.html) 고수준 알고리즘은 대체로 동일합니다. 핵심 포인트는 다음과 같습니다:
- 서로 다른 컴포넌트 타입은 실질적으로 다른 트리를 생성한다고 가정합니다. React는 이들을 비교하려고 시도하지 않고, 이전 트리를 완전히 교체합니다.
- 리스트 비교는 key를 사용하여 수행됩니다. key는 "안정적이고, 예측 가능하며, 고유해야" 합니다.

### 재조정 대 렌더링
DOM은 React가 렌더링할 수 있는 여러 렌더링 환경 중 하나일 뿐이며, 또 다른 주요 타겟은 React Native를 통한 네이티브 iOS 및 Android 뷰입니다. (이것이 바로 "가상 DOM"이라는 용어가 약간 잘못된 명칭인 이유입니다.)
이렇게 다양한 타겟을 지원할 수 있는 이유는 React가 재조정(reconciliation)과 렌더링(rendering)을 별도의 단계로 분리하도록 설계되었기 때문입니다. 재조정자는 트리의 어떤 부분들이 변경되었는지 계산하는 작업을 수행하고, 렌더러는 그 정보를 사용하여 실제로 렌더링된 앱을 업데이트합니다.
이러한 분리 덕분에 ReactDOM과 React Native는 React 코어가 제공하는 동일한 재조정자를 공유하면서 각자의 렌더러를 사용할 수 있습니다.
Fiber는 재조정자를 다시 구현한 것입니다. 렌더링 자체에 주로 관여하는 것은 아니지만, 렌더러들은 새로운 아키텍처를 지원하고 (그 장점을 활용)하기 위해 변경이 필요합니다.

### 스케줄링 (Scheduling)

스케줄링 (scheduling)
: 작업을 언제 수행해야 할지 결정하는 프로세스.

작업 (work)
: 수행되어야 하는 모든 연산. 작업은 보통 업데이트(예: `setState`)의 결과로 발생합니다.

React의 [Design Principles](https://facebook.github.io/react/contributing/design-principles.html#scheduling) 문서는 이 주제에 대해 너무나 잘 설명하고 있으므로, 여기서 그대로 인용하겠습니다.
> 현재 구현에서 React는 트리를 재귀적으로 탐색하며 단일 틱(tick) 내에 업데이트된 전체 트리의 render 함수를 호출합니다. 하지만 미래에는 프레임 드랍을 방지하기 위해 일부 업데이트를 지연시키기 시작할 수도 있습니다.
>
> 이것은 React 디자인의 공통된 주제입니다. 일부 인기 있는 라이브러리는 새로운 데이터를 사용할 수 있을 때 연산이 수행되는 "푸시(push)" 접근 방식을 구현합니다. 그러나 React는 연산이 필요할 때까지 지연될 수 있는 "풀(pull)" 접근 방식을 고수합니다.
>
> React는 범용 데이터 처리 라이브러리가 아닙니다. 사용자 인터페이스를 구축하기 위한 라이브러리입니다. 우리는 React가 앱 내에서 어떤 연산이 지금 당장 관련이 있고 어떤 연산이 그렇지 않은지 알 수 있는 독보적인 위치에 있다고 생각합니다.
>
> 무언가 화면 밖에 있다면, 우리는 그것과 관련된 모든 로직을 지연시킬 수 있습니다. 데이터가 프레임 레이트보다 빠르게 도착하는 경우, 업데이트를 병합하고 배치(batch) 처리할 수 있습니다. 프레임 드랍을 방지하기 위해 사용자 상호작용에서 비롯된 작업(예: 버튼 클릭으로 인한 애니메이션)을 네트워크에서 방금 로드된 새로운 콘텐츠를 렌더링하는 것과 같은 덜 중요한 백그라운드 작업보다 우선시할 수 있습니다.

핵심 포인트는 다음과 같습니다.
- UI에서는 모든 업데이트가 즉시 적용될 필요가 없습니다. 사실 그렇게 하는 것은 낭비일 수 있으며, 프레임 드랍을 유발하고 사용자 경험을 저하시킵니다.
- 서로 다른 유형의 업데이트는 서로 다른 우선순위를 가집니다. 예를 들어 애니메이션 업데이트는 데이터 스토어의 업데이트 등보다 더 빠르게 완료되어야 합니다.
- 푸시 기반 접근 방식은 앱(개발자인 여러분)이 작업 일정을 예약하는 방법을 결정하도록 요구합니다. 풀 기반 접근 방식은 프레임워크(React)가 영리해져서 여러분을 대신해 그러한 결정을 내리도록 허용합니다.

React는 현재 스케줄링을 큰 방식으로 활용하고 있지 않습니다. 업데이트는 전체 서브트리가 즉시 다시 렌더링되는 결과를 낳습니다. 스케줄링을 활용하기 위해 React의 코어 알고리즘을 전면 개정하는 것이 Fiber의 이면에 있는 추진력 있는 아이디어입니다.

---

이제 Fiber의 구현으로 뛰어들 준비가 되었습니다. 다음 섹션은 지금까지 논의한 것보다 더 기술적입니다. 계속 진행하기 전에 이전 내용에 익숙해졌는지 확인해 주세요.

## Fiber란 무엇인가요?

우리는 지금 React Fiber 아키텍처의 핵심을 논의하려고 합니다. Fiber는 애플리케이션 개발자가 일반적으로 생각하는 것보다 훨씬 더 로우 레벨의 추상화입니다. 이를 이해하려는 시도에서 좌절감을 느낀다면 낙심하지 마세요. 계속 시도하다 보면 결국 이해하게 될 것입니다. (마침내 이해하게 된다면, 이 섹션을 개선할 수 있는 방법을 제안해 주세요.)

시작합니다!

---

Fiber의 주요 목표 중 하나가 React가 스케줄링을 활용할 수 있도록 하는 것임을 확인했습니다. 구체적으로 우리는 다음을 할 수 있어야 합니다.
- 작업을 일시 중지하고 나중에 다시 돌아오는 것.
- 서로 다른 유형의 작업에 우선순위를 할당하는 것.
- 이전에 완료된 작업을 재사용하는 것.
- 더 이상 필요하지 않은 경우 작업을 중단하는 것.

이 중 어떤 것이라도 수행하려면, 먼저 작업을 여러 단위로 쪼갤 수 있는 방법이 필요합니다. 어떤 의미에서 그것이 바로 fiber가 하는 일입니다. Fiber는 \*\*작업 단위(unit of work)\*\*를 나타냅니다.

더 나아가기 위해, 흔히 다음과 같이 표현되는 [함수로서의 React 컴포넌트](https://github.com/reactjs/react-basic#transformation) 개념으로 돌아가 봅시다.
```
v = f(d)
```
따라서 React 앱을 렌더링하는 것은 본문에 다른 함수에 대한 호출 등이 포함된 함수를 호출하는 것과 유사합니다. 이 비유는 fiber에 대해 생각할 때 유용합니다.

컴퓨터가 일반적으로 프로그램의 실행을 추적하는 방식은 [호출 스택(call stack)](https://en.wikipedia.org/wiki/Call\_stack)을 사용하는 것입니다. 함수가 실행될 때, 새로운 \*\*스택 프레임(stack frame)\*\*이 스택에 추가됩니다. 해당 스택 프레임은 그 함수에 의해 수행되는 작업을 나타냅니다.

UI를 다룰 때의 문제는 너무 많은 작업이 한꺼번에 실행되면 애니메이션의 프레임이 떨어지고 화면이 끊겨 보일 수 있다는 점입니다. 게다가 그 작업 중 일부는 더 최신 업데이트로 인해 대체될 경우 불필요할 수도 있습니다. 바로 여기서 비교가 시작됩니다.

UI 컴포넌트와 함수는 역할이 분리되는데, 컴포넌트가 일반적인 함수보다 더 구체적인 관심사를 가지기 때문입니다.

최신 브라우저(그리고 React Native)는 정확히 이 문제를 해결하는 데 도움이 되는 API들을 구현하고 있습니다. `requestIdleCallback`은 유휴 시간(idle period) 동안 호출될 우선순위가 낮은 함수를 예약하고, `requestAnimationFrame`은 다음 애니메이션 프레임에서 호출될 우선순위가 높은 함수를 예약합니다. 문제는 이러한 API를 사용하려면 렌더링 작업을 점진적인 단위로 쪼갤 수 있는 방법이 필요하다는 점입니다. 만약 호출 스택(call stack)에만 의존한다면, 스택이 빌 때까지 계속 작업을 수행하게 될 것입니다.

UI 렌더링을 최적화하기 위해 호출 스택의 동작을 커스텀할 수 있다면 얼마나 좋을까요? 마음대로 호출 스택을 중단시키고 스택 프레임을 수동으로 조작할 수 있다면 얼마나 좋을까요?

그것이 바로 React Fiber의 목적입니다. Fiber는 React 컴포넌트에 특화된 스택의 재구현체입니다. 단일 fiber를 \*\*가상 스택 프레임(virtual stack frame)\*\*으로 생각할 수 있습니다.

스택을 재구현하는 것의 장점은 [스택 프레임을 메모리에 유지](https://www.facebook.com/groups/2003630259862046/permalink/2054053404819731/)하고 원하는 방식과 (\*원하는 시점*)에 실행할 수 있다는 것입니다. 이는 우리가 스케줄링에서 달성하고자 하는 목표를 위해 매우 중요합니다.

스케줄링 외에도, 스택 프레임을 수동으로 다루면 동시성(concurrency) 및 에러 경계(error boundaries)와 같은 기능들의 잠재력이 열리게 됩니다. 이 주제들은 추후 섹션에서 다루겠습니다.

다음 섹션에서는 fiber의 구조에 대해 더 자세히 살펴보겠습니다.

### Fiber의 구조

\*참고: 구현 세부사항이 더 구체화됨에 따라 무언가 변경될 가능성이 커집니다. 실수나 오래된 정보를 발견하시면 PR을 제출해 주세요.\*

구체적으로, fiber는 컴포넌트, 해당 컴포넌트의 입력(input), 출력(output)에 대한 정보를 포함하는 JavaScript 객체입니다.

fiber는 스택 프레임에 대응되지만, 컴포넌트의 인스턴스에도 대응됩니다.

다음은 fiber에 속하는 중요한 필드들입니다. (이 목록이 전부는 아닙니다.)

#### `type`과 `key`

fiber의 type과 key는 React 엘리먼트에서와 동일한 목적을 수행합니다. (실제로 엘리먼트로부터 fiber가 생성될 때 이 두 필드는 그대로 복사됩니다.)

fiber의 type은 그것이 대응되는 컴포넌트를 설명합니다. 합성 컴포넌트(composite component)의 경우, type은 함수 또는 클래스 컴포넌트 그 자체입니다. 호스트 컴포넌트(`div`, `span` 등)의 경우, type은 문자열입니다.

개념적으로 type은 실행이 스택 프레임에 의해 추적되고 있는 함수(예: `v = f(d)`)입니다.

type과 함께 key는 재조정(reconciliation) 과정에서 fiber를 재사용할 수 있는지 여부를 결정하는 데 사용됩니다.

#### `child`와 `sibling`

이 필드들은 다른 fiber들을 가리키며, fiber의 재귀적 트리 구조를 설명합니다.

child fiber는 컴포넌트의 `render` 메서드가 반환하는 값에 대응됩니다. 따라서 다음 예시에서

```js
function Parent() {
return 
}
```

`Parent`의 child fiber는 `Child`에 대응됩니다.

sibling 필드는 `render`가 여러 개의 자식을 반환하는 경우를 처리합니다 (Fiber의 새로운 기능!):

```js
function Parent() {
return [, ]
}
```

child fiber들은 첫 번째 자식을 헤드로 하는 단일 연결 리스트(singly-linked list)를 형성합니다. 따라서 이 예시에서 `Parent`의 자식은 `Child1`이며, `Child1`의 sibling은 `Child2`입니다.

앞서 비유했던 함수 이야기로 돌아가서, child fiber를 [꼬리 호출된 함수(tail-called function)](https://en.wikipedia.org/wiki/Tail\_call)로 생각할 수 있습니다.

#### `return`

return fiber는 현재 fiber를 처리한 후에 프로그램이 돌아와야 하는 fiber입니다. 이는 개념적으로 스택 프레임의 반환 주소(return address)와 동일합니다. 또한 부모 fiber로 생각할 수도 있습니다.

만약 fiber가 여러 개의 child fiber를 가지고 있다면, 각 child fiber의 return fiber는 부모가 됩니다. 따라서 앞서 살펴본 예시에서 `Child1`과 `Child2`의 return fiber는 `Parent`입니다.

#### `pendingProps`와 `memoizedProps`

개념적으로 props는 함수의 인자입니다. fiber의 `pendingProps`는 시작 부분에 설정됩니다.

s execution, and `memoizedProps`는 종료 시점에 설정됩니다.
새로 들어오는 `pendingProps`가 `memoizedProps`와 같을 경우, 이는 fiber의 이전 출력을 재사용할 수 있음을 나타내어 불필요한 작업을 방지합니다.
#### `pendingWorkPriority`
fiber가 나타내는 작업의 우선순위를 나타내는 숫자입니다. [ReactPriorityLevel](https://github.com/facebook/react/blob/master/src/renderers/shared/fiber/ReactPriorityLevel.js) 모듈에는 다양한 우선순위 레벨과 그것이 의미하는 바가 나열되어 있습니다.
0인 `NoWork`를 제외하면, 숫자가 클수록 낮은 우선순위를 의미합니다. 예를 들어, 다음 함수를 사용하여 fiber의 우선순위가 주어진 레벨 이상인지 확인할 수 있습니다:
```js
function matchesPriority(fiber, priority) {
return fiber.pendingWorkPriority !== 0 &&
fiber.pendingWorkPriority <= priority
}
```
\*이 함수는 예시일 뿐이며, 실제로 React Fiber 코드베이스의 일부는 아닙니다.\*
스케줄러는 우선순위 필드를 사용하여 수행할 다음 작업 단위를 검색합니다. 이 알고리즘은 추후 섹션에서 다룰 것입니다.
#### `alternate`

flush
:   Fiber의 출력을 화면에 그려내는(render) 것입니다.

work-in-progress
:   아직 완료되지 않은 fiber이며, 개념적으로는 아직 반환되지 않은 스택 프레임입니다.

어느 시점이든 컴포넌트 인스턴스에 대응하는 fiber는 최대 두 개 존재합니다. 바로 현재의(current, flushed) fiber와 work-in-progress fiber입니다.
현재 fiber의 alternate는 work-in-progress이며, work-in-progress의 alternate는 현재 fiber입니다.
Fiber의 alternate는 `cloneFiber`라는 함수를 사용해 지연 생성(lazily created)됩니다. `clone`된 객체를 항상 새로 생성하는 대신, `cloneFiber`는 기존 alternate fiber가 존재할 경우 재사용을 시도하여 메모리 할당을 최소화합니다.
`alternate` 필드는 구현 세부사항으로 생각해야 하지만, 코드베이스에서 너무 자주 등장하기 때문에 여기서 다룰 가치가 있습니다.
#### `output`

host component
:   React 애플리케이션의 리프 노드(leaf node)입니다. 렌더링 환경에 따라 다릅니다(예: 브라우저 앱인 경우 `div`, `span` 등). JSX에서는 소문자 태그 이름으로 표시됩니다.

개념적으로 fiber의 output은 함수의 반환 값입니다.
모든 fiber는 결국 output을 가지지만, output은 리프 노드인 **host components**에 의해서만 생성됩니다. 생성된 output은 트리 위로 전달됩니다.
이 output은 렌더링 환경에 변경 사항을 반영(flush)할 수 있도록 최종적으로 렌더러에게 전달되는 것입니다. output이 어떻게 생성되고 업데이트되는지를 정의하는 것은 렌더러의 책임입니다.
## Future sections
지금은 여기까지이지만, 이 문서는 아직 완성되려면 멀었습니다. 향후 섹션에서는 업데이트의 전체 생명주기 동안 사용되는 알고리즘을 설명할 예정입니다. 다룰 주제는 다음과 같습니다:
- scheduler가 수행해야 할 다음 작업 단위를 찾는 방법.
- fiber 트리를 통해 우선순위가 추적되고 전파되는 방식.
- scheduler가 작업을 일시 중지하고 재개해야 할 시점을 파악하는 방법.
- 작업이 flush되고 완료로 표시되는 방식.
- 사이드 이펙트(예: 생명주기 메서드)가 작동하는 방식.
- coroutine이란 무엇이며, 이를 사용하여 context 및 layout과 같은 기능을 구현하는 방법.
## Related Videos
- [What's Next for React (ReactNext 2016)](https://youtu.be/aV1271hd9ew)

react-fiber-architecture

파일 탐색기

오늘의 추천 프로젝트

Was this content helpful?

Recent Feedback

react-fiber-architecture

파일 탐색기

오늘의 추천 프로젝트

Was this content helpful?

Recent Feedback

Download README