영문 블로그 글을 번역했습니다. 허가를 받으면 시리즈를 이어갈 예정입니다.
원문링크:https://jser.dev/react/2021/07/28/how-does-context-work
ℹ️React Internals Deep Dive에피소드 9,유튜브에서 제가 설명하는 것을 시청해주세요.
⚠React@18.2.0기준, 최신 버전에서는 구현이 변경되었을 수 있습니다.
💬 역자 주석: Jser의 코멘트는 ❗❗로 표시 해뒀습니다.
그 외 주석은 리액트 소스 코드 자체의 주석입니다.
... 은 생략된 코드입니다.
컴포넌트 트리(tree of components)로 React 코드를 작성하면, props로 데이터를 전달할 수 있지만 트리가 매우 깊은 경우에는 번거롭습니다. 예를 들어, 모든 컴포넌트에 사용될 수 있는 전역 색을 정의하려면 결국 모든 컴포넌트가 이를 지원하기 위해 새로운 prop이 필요할 수 있습니다.
Context는 이 문제를 해결하기 위해 props 없이 하위 트리에 데이터를 전달할 수 있게 해줍니다.
1. React Context 데모
여기에 Context를 사용하는 간단한 리액트 앱이 있습니다. 이건 그저 JSer를 렌더링 합니다.
데모 링크(코드 샌드박스)
import { createContext } from 'react';
const Context = createContext("123");
function Component1() {
return <Component2 />;
}
function Component2() {
return <Context.Consumer>
{(value) => value}
</Context.Consumer>;
}
이 데모는 매우 간단한데, 자 이제 React Context가 내부적으로 어떻게 동작하는지 알아봅시다.
2. React.createContext()
import { REACT_PROVIDER_TYPE, REACT_CONTEXT_TYPE } from "shared/ReactSymbols";
import type { ReactContext } from "shared/ReactTypes";
export function createContext<T>(defaultValue: T): ReactContext<T> {
const context: ReactContext<T> = {
$$typeof: REACT_CONTEXT_TYPE,
_currentValue: defaultValue,
_currentValue2: defaultValue,
_threadCount: 0,
Provider: (null: any),
Consumer: (null: any),
};
context.Provider = {
$$typeof: REACT_PROVIDER_TYPE,
_context: context,
};
context.Consumer = context;
return context;
}
즉 createContext()는 기본값을 보유한 객체를 반환하고 Provider와 Consumer를 노출하기만 하면 됩니다.
Provider는 REACT_PROVIDER_TYPE의 특수 엘리먼트 타입으로, 곧 다룰 예정입니다.
Consumer는 흥미로운데, 이건 context에 설정됩니다.
위의 데모 코드와 마찬가지로 Provider와 Consumer는 실제로 렌더링에 사용되므로 Context는 이들을 페어링하는 방법입니다.
3. Provider
여기서 엘리먼트 타입 REACT_PROVIDER_TYPE은 파이버 태그 ContextProvider에 매핑됩니다.
Provider의 유일한 목적은<Provider value={...}/> 구문에서 Consumer가 사용하는 값을 설정하는 것이며, 아래는 렌더링 중에 Provider가 처리되는 방식입니다.
ℹ 렌더링 내부에 대한 자세한 내용은 React가 최초 마운트를 수행하는 방법 과 React가 리-렌더링하는 방법을 참조하십시오.
function beginWork() {
case ContextProvider:
return updateContextProvider(current, workInProgress, renderLanes);
}
function updateContextProvider(
current: Fiber | null,
workInProgress: Fiber,
renderLanes: Lanes,
) {
const providerType: ReactProviderType<any> = workInProgress.type;
const context: ReactContext<any> = providerType._context;
const newProps = workInProgress.pendingProps;
const oldProps = workInProgress.memoizedProps;
const newValue = newProps.value;
pushProvider(workInProgress, context, newValue);
if (enableLazyContextPropagation) {
} else {
if (oldProps !== null) {
const oldValue = oldProps.value;
if (is(oldValue, newValue)) {
if (
oldProps.children === newProps.children &&
!hasLegacyContextChanged()
) {
return bailoutOnAlreadyFinishedWork(
current,
workInProgress,
renderLanes,
);
}
} else {
propagateContextChange(workInProgress, context, renderLanes);
}
}
}
const newChildren = newProps.children;
reconcileChildren(current, workInProgress, newChildren, renderLanes);
return workInProgress.child;
}
렌더링 중에 Provider가 작동하는 방식을 요약해 보겠습니다.
호출하면 먼저 pushProvider()로 새 값을 업데이트합니다.
값이 변하지 않으면, bailout을 시도합니다
그렇지 않으면 propagateContextChange()로 Consumer를 업데이트하고 자식들을 렌더링합니다.
3.1 pushProvider()
export function pushProvider<T>(
providerFiber: Fiber,
context: ReactContext<T>,
nextValue: T
): void {
if (isPrimaryRenderer) {
push(valueCursor, context._currentValue, providerFiber);
context._currentValue = nextValue;
} else {
...
}
}
이렇게 값이 Fiber 스택 구조로 푸시됩니다.
파이버 스택은 루트에서 현재 파이버까지의 경로를 따라 정보를 보관한다고 생각할 수 있습니다. 동일한 Context에 여러 Provider가 있는 경우 스택 구조는 Fiber 노드에 대해 가장 가까운 값을 사용하도록 합니다.
컨텍스트 자체는 최신 값으로 설정되어 있지만 Fiber 스택은 이전 값을 저장하고 있는데, 이는 컨텍스트에 기본값이 있기 때문입니다.
3.2 popProvider()
푸시(push)가 있는 곳에는 팝(pop)이 있습니다. completeWork()에서 popProvider()가 호출됩니다.
이는 파이버 트리가 workInProgress를 순회 중일 때 컨텍스트가 올바른 값을 반영하고 있는지 확인하기 위한 것입니다. 엘리먼트를 Provider의 형제(sibling)라고 생각하면, React가 이 파이버로 이동하면 Provider의 정보가 없어야 하므로, Context 정보를 팝(pop)해야 합니다.
Fiber 스택은 루트에서 현재 파이버 노드까지의 경로를 따라 컨텍스트 정보들을 보유한다는 점을 유의하세요.
export function popProvider(
context: ReactContext<any>,
providerFiber: Fiber
): void {
const currentValue = valueCursor.current;
pop(valueCursor, providerFiber);
if (isPrimaryRenderer) {
if (
enableServerContext &&
currentValue === REACT_SERVER_CONTEXT_DEFAULT_VALUE_NOT_LOADED
) {
context._currentValue = context._defaultValue;
} else {
context._currentValue = currentValue;
}
} else {
...
}
}
파이버 스택이 이전 값을 저장하기 때문에 popProvider()가 하는 일은 간단합니다. 컨텍스트에 설정하고 팝하기만 하면 끝입니다!
4. Consumer
propagateContextChange()의 작동 방식을 이해하려면 먼저 Consumer의 작동 방식을 이해해야 합니다.
위에서 언급했듯이, Consumer는 실제로 컨텍스트 자체이며 ContextConsumer파이버 태그가 사용됩니다(소스).
function updateContextConsumer(
current: Fiber | null,
workInProgress: Fiber,
renderLanes: Lanes
) {
let context: ReactContext<any> = workInProgress.type;
const newProps = workInProgress.pendingProps;
const render = newProps.children;
prepareToReadContext(workInProgress, renderLanes);
const newValue = readContext(context);
let newChildren;
newChildren = render(newValue);
workInProgress.flags |= PerformedWork;
reconcileChildren(current, workInProgress, newChildren, renderLanes);
return workInProgress.child;
}
좋아요. 이것은 사실 아주 간단합니다.
먼저 prepareToReadContext()함수를 실행하고
그리고 readContext() 로 값을 읽고
소비자가 자식의 렌더링 prop을 예상하기 때문에 newChildren = render(newValue)로 설정합니다.
4.1 prepareToReadContext()
export function prepareToReadContext(
workInProgress: Fiber,
renderLanes: Lanes
): void {
currentlyRenderingFiber = workInProgress;
lastContextDependency = null;
lastFullyObservedContext = null;
const dependencies = workInProgress.dependencies;
if (dependencies !== null) {
if (enableLazyContextPropagation) {
dependencies.firstContext = null;
} else {
const firstContext = dependencies.firstContext;
if (firstContext !== null) {
if (includesSomeLane(dependencies.lanes, renderLanes)) {
markWorkInProgressReceivedUpdate();
}
dependencies.firstContext = null;
}
}
}
}
prepareToReadContext()가 updateContextConsumer()에서만 호출되는 것이 아니라 기본적으로 모든 컴포넌트를 렌더링할 때 호출된다는 점을 기억하세요. dependencies는 컴포넌트에 사용된 모든 Context를 추적하여, 나중에 컨텍스트 값이 변경될 때, React가 어떤 컴포넌트를 업데이트할지 알 수 있도록 하기 위한 것임을 잊지 마세요.
4.2 readContext()
export function readContext<T>(context: ReactContext<T>): T {
const value = isPrimaryRenderer
? context._currentValue
: context._currentValue2;
if (lastFullyObservedContext === context) {
} else {
const contextItem = {
context: ((context: any): ReactContext<mixed>),
memoizedValue: value,
next: null,
};
if (lastContextDependency === null) {
lastContextDependency = contextItem;
currentlyRenderingFiber.dependencies = {
lanes: NoLanes,
firstContext: contextItem,
};
if (enableLazyContextPropagation) {
currentlyRenderingFiber.flags |= NeedsPropagation;
}
} else {
lastContextDependency = lastContextDependency.next = contextItem;
}ㅋ
}
return value;
}
파이버의 경우 여러 컨텍스트를 사용할 수 있으므로, dependencies는 실제로 링크드 리스트입니다.
readContext()는 컨텍스트에서 값을 읽고 dependencies을 업데이트하기만 하면 됩니다.
4.3 useContext()는 readContext()의 alias 입니다.
const HooksDispatcherOnMount: Dispatcher = {
useCallback: mountCallback,
useContext: readContext,
useEffect: mountEffect,
...
};
const HooksDispatcherOnUpdate: Dispatcher = {
useCallback: updateCallback,
useContext: readContext,
useEffect: updateEffect,
...
};
네, 간단합니다.
5. propagateContextChange()
컨텍스트의 값이 변경되면, 모든 소비자에 대한 업데이트를 예약해야 하는데, 이는 업데이트가 어떻게든 건너뛰어지지 않도록 하기 위해서입니다.
업데이트 스케줄링은 기본적으로 루트에서 파이버 노드까지 경로의 모든 노드에 대한 lanes와 childLanes를 업데이트하는 것을 의미합니다. 이에 대한 자세한 내용은 조정에서 React bailout이 작동하는 방식에서 확인할 수 있습니다.
소스 코드에는 꽤 많은 줄이 있으므로 여기에 붙여넣지 않겠습니다.
아이디어는 꽤 간단한데, 코드를 보면, 이 Provider 아래의 하위 트리가 순회되고, 각 파이버에 대해 dependencies가 확인되며, 만약 여기서 컨텍스트가 사용되는 것을 발견되면 scheduleContextWorkOnParentPath()를 호출하여 일부 작업을 예약한다는 것을 쉽게 알 수 있습니다.
Provider의 beginWork() 단계에서 스캔될 때까지 기다렸다가, 소비자가 아직 트리에 없는 경우면 어떻게 하냐고 질문할 수 있습니다.
좋은 질문입니다. 언뜻 보기에는 Consumer 노드가 렌더링된 후에만 종속성이 업데이트되므로 순서가 조금 이상해 보입니다. 하지만 실제로는 렌더링 중에 Consumer 노드가 추가되면 자동으로 최신 값을 사용하므로 한 번만 스캔하면 됩니다.
6. 요약
컨텍스트는 사실 이해하기가 그리 복잡하지 않습니다. 핵심 아이디어는 경로를 따라 정보를 저장할 수 있는 파이버 스택입니다.
7. 코딩 챌린지
이제 이해를 돕기 위해 제가 만든 간단한 코딩 챌린지를 소개합니다. 즐겨보세요!
(원글 게시일 2021-07-28)
![[번역] React에서 Context는 어떻게 동작하나요?](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fres%2Fhashnode%2Fimage%2Fupload%2Fv1713962934193%2F0bff74ea-091b-4efb-87bd-d17956563415.jpeg&w=3840&q=75)
