React Fiber는 React의 핵심 알고리즘을 지속적으로 재구현한 것
React Fiber의 목표는 애니메이션,레이아웃 및 제스처와 같은 영역에 대한 적합성을 높이는 것 헤드 라인 기능은 증분 렌더링 즉, 렌더링 작업을 청크로 분할하고 여러 프레임에 분산시키는 기능
reconciliation
React 알고리즘은 어떤 부분을 변경해야 하는지 결정하기 위해 한 트리를 다른 트리와 비교하는 데 사용
update
React 앱을 렌더링하는 데 사용되는 데이터의 변경 일반적으로 setState
의 결과 결국 다시 렌더링됨.
React API의 핵심 아이디어는 업데이트가 전체 앱을 다시 렌더링하는 것처럼 생각하는 것 이를 통해 개발자는 앱을 특정 상태에서 다른 상태(A에서 B로, B에서 C, C에서 A)로 효율적으로 전호나하는 방법에 대해 걱정하지 않고 선언적으로 추론 가능
실제로 변경될 때마다 전체 앱을 다시 렌더링하는 것은 가장 사소한 앱에서만 작동 실제 앱에서는 성능 측면에서 엄청나게 비용이 많이 듬. React에는 뛰어난 성능을 유지하면서 전체 앱을 다시 렌더링하는 모양을 만드는 최적화 기능이 있다. 이러한 최적화의 대부분은 조정이라는 프로세스의 일부
조정은 일반적으로 "가상 DOM"으로 이해되는 알고리즘
React를 렌더리아할 때 앱을 설명하는 노드트리가 생성되어 메모리에 저장 앱이 업데이트되면(일반적으로 setState
를 통해) 새 트리가 생성, 새 트리는 렌더링된 앱을 업데이트하는 데 필요한 작업을 계산하기 위해 이전 트리와 비교됨.
Fiber는 reconciler를 처음부터 다시 작성했지만 고급 알고리즘은 대체로 동일하다. 핵심 사항은 다음과 같다.
DOM은 React가 렌더링할 수 있는 렌더링 환경 중 하나 일뿐 이며 다른 주요 대상은 React Native를 통한 기본 IOS 및 android보기입니다.
이렇게 많은 대상을 지원할 수 있는 이유는 React가 조정과 렌더링이 별도의 단계로 설계되었기 때문. 조정자는 트리의 어떤 부분이 변경되었는지 계산하는 작업을 수행함.
그런 다음 렌더러는 해당 정보를 사용하여 렌더링된 앱을 실제로 업데이트 함.
현재 구현에서 React는 재귀적으로 트리를 탐색하고 단일 틱 동안 전체 업데이트된 렌더링 함수를 호출. 그러나 향후 프레임 드롭을 방지하기 위해 일부 업데이트가 지연될 수 있다.
일부 인기 있는 라이브러리는 새 데이터를 사용할 수 있을 때 계산이 수행되는 "푸사" 접근 방식을 구현합니다. 그러나 React는 계산이 필요할 때까지 지연될 수 있는 '당기기' 접근 방식을 고수
React는 일반적인 데이터 처리 라이브러리가 아니다. 사용자 인터페이스를 구축하기 위한 라이브러리임. 우리는 현재 어떤 계산이 관련이 있고 그렇지 않은지 알 수 있는 것이 앱에서 고유한 위치에 있다고 생각
핵심 사항은 다음과 같다.
React는 현재 중요한 방식으로 스케줄링을 활용하지 않는다. 업데이트하면 전체 하위 트리가 즉시 다시 렌더링됨. 스케줄링을 활용하기 위해 React의 핵심 알고리즘을 정비하는 것이 fiber의 핵심 아이디어
우리는 Fiber의 주요 목표가 React가 스케줄링을 활용할 수 있도록 하는 것임을 확인했다. 특히 우리는
이 작업을 수행하려면 먼저 작업을 단위로 나누는 방법이 필요. 어떤 의미에서 그것이 바로 Fiber입니다. Fiber는 작업 단위를 나타냄.
호출 스택의 동작을 사용자 정의하여 UI 렌더링을 최적화할 수 있다면 좋지 않을까요? 호출 스택을 마음대로 중단하고 스택 프레임을 수동으로 조작할 수 있다면 좋지 않을까요?
이것이 React Fiber의 목적. Fiber는 React 구성 요소에 특화된 스택의 재구현임. 단일 파이버를 가상 스택 프레임으로 생각할 수 있다.
스택 재구현의 이점은 스택 프레임을 메모리에 유지하고 원하는 대로 실행할 수 있다는 것. 이것은 우리가 스케줄링을 위해 가지고 있는 목표를 달성하는 중요하다.
자세한 내용은 React Fiber 참고하세요