마찬가지로 Fragment가 사라진 부분을 제외하고는 특별한 부분은 없습니다.

Fragment는 포장지 역할만 하기 때문에 Fiber로 변환될 때 Fragment를 벗겨내고 자식들을 얻어와 fiber로 확장합니다. 하지만 Fragment도 React element이므로 key를 설정할 수 있습니다. 이 key가 설정된 Fragment는 단순한 포장지 역할을 넘어서 개발자가 의도적으로 컴포넌트를 판별하기 위한 장치로 사용되므로 제거하지 않고 Fragment fiber로 만듭니다. key가 설정되어 있는 Fragment만 createFiberFromTypeAndProps()의 39라인에 도달할 수 있습니다. 이 부분은 나중에 코드로 확인합니다.

만약 Fragment를 다음과 같이 정의했다면 Todo 컴포넌트 자식으로 Fragment가 살아있었을 것입니다.
<Fragment key=“foo”>

VDOM을 DOM에 적용할 때는 HTML element에 대응하는 호스트 컴포넌트만 마운트됩니다.
개발자가 작성한 커스텀 컴포넌트는 React element를 반환하는 상태를 가진 콜백 함수 그 이상 그 이하도 아닙니다.

자 이제 사전준비는 모두 끝났습니다. 본격적으로 재조정 작업을 시작해 봅시다.

5. Sync Work, Async Work

Work 콜백을 스케줄링시켰던 ensureRootIsScheduled() 기억하시나요? 이때 여러 상황을 고려하여 재조정 작업을 비동기로 처리해야 할지 동기적으로 처리해야 할지 결정했습니다. 이 결정에 따라서 사용된 콜백이 각각 performConcurrentWorkOnRoot()와 performSyncWorkOnRoot()입니다.

비동기 작업에 대한 분석은 performConcurrentWorkOnRoot()의 초입부분 까지만 진행하고 이 이후로는 동기 작업에 대해서만 분석하도록 하겠습니다.

5 - 1 Async Work

비동기 작업에 대해 지난 포스트에서 언급만 하고 아직 코드로 확인하지 못했던 부분이 있었습니다. 바로 scheduler에게 잔여작업이 있는지 알려주는 부분22번 라인입니다.

performConcurrentWorkOnRoot()를 통해 확인해볼 텐데 이 부분을 제외하고는 performSyncWorkOnRoot()와 로직이 같으므로 중복되는 것은 동기 작업을 분석할 때 설명하도록 하겠습니다.

reconciler > ReactFiberWorkLoop.js

  
function performConcurrentWorkOnRoot(root, didTimeout) {
  // 처리해야 될 expirationTime을 가지고 온다.
  const expirationTime = getNextRootExpirationTimeToWorkOn(root); 
  if (expirationTime !== NoWork) {
    const originalCallbackNode = root.callbackNode;
    /*...*/

    /* Render phase 진입.. */

    if (workInProgress !== null) {
      /* 작업 중단에 따른 처리.. */
    } else {
      /* Commit phase 진입.. */
    }
    // 각 phase 진행 과정에서 추가적인 업데이트가 발생할 경우를 대비한 스케줄링 요청
    ensureRootIsScheduled(root); 
    if (root.callbackNode === originalCallbackNode) {
      // 해당 root에는 잔여 작업이 남아 있으므로 root를 잡아논 Work 콜백을 반환한다.
      return performConcurrentWorkOnRoot.bind(null, root); 
    }
  }
  return null;
}

root.callbackNode18는 Commit phase14를 지나면 null로 초기화됩니다. null이 아니라는 건 아래의 코드에서 Work를 진행하다 중지된 겁니다.

reconciler > ReactFiberWorkLoop.js

  
function workLoopConcurrent() {
  // Perform work until Scheduler asks us to yield
  while (workInProgress !== null && !shouldYield()) {    workInProgress = performUnitOfWork(workInProgress);
  }
}

while 문이 중지되었다면 workInProgress는 비어있지 않을 것11이므로 Commit phase14에 도달하지 못해 callbackNode18는 초기화되지 않습니다.

그리고 한 가지 더 ensureRootIsScheduled()17를 실행했는데도 root가 가지고 있는 callbackNodeTask가 현재 Work를 진행한 originalCallbackNode6와 같다는 건18 현재 originalCallbackNode가 가장 우선순위가 높음을 나타내므로 계속해서 작업을 이어서 진행할 수 있다는 뜻입니다.

이 모든 근거를 바탕으로 performConcurrentWorkOnRoot()20를 반환해 scheduler에게 해당 root에 잔여 작업이 남아 있음을 알려줍니다. 이렇게 반환한 Work 콜백은 scheduler가 다음 프레임에 실행시켜 줄 것입니다.

concurrent mode에 대해서는 자세히 다루지는 않았지만 기반이 되는 몇몇 부분들을 확인해보았습니다. 이번 시리즈에서는 이 이상으로 분석하지는 않지만, 추후에 보편적으로 사용하게 되는 날이 오면 그때 가서 다루어 보도록 하겠습니다.

5 - 2 Sync Work

async Work와는 다르게 해당 Work는 한번 실행되면 모든 작업이 끝날때 까지 동기적으로 처리합니다.

reconciler > ReactFiberWorkLoop.js

  
function performSyncWorkOnRoot(root) {
  // Check if there's expired work on this root. Otherwise, render at Sync.
  const lastExpiredTime = root.lastExpiredTime;
  const expirationTime = lastExpiredTime !== NoWork ? lastExpiredTime : Sync;
  /*...*/
}

lastExpiredTime는 이전 Work가 만료되었을 때 할당되는 시간입니다. 이 부분은 위에서 performConcurrentWorkOnRoot()를 다룰 때 여러분의 이해를 위해 생략했던 부분으로 아래에서 확인해 볼 수 있습니다.

reconciler > ReactFiberWorkLoop.js

  
function performConcurrentWorkOnRoot(root, didTimeout) {
  if (didTimeout) {
    const currentTime = requestCurrentTimeForUpdate();
    markRootExpiredAtTime(root, currentTime);
    ensureRootIsScheduled(root);
    return null;
  }
    /*...*/
}

concurrent mode에서 비동기로 Work를 진행하다 만료가 될 경우(workLoop()의 20 ~ 22) root에 lastExpiredTime이 새겨지고4 다음 프레임에 동기로 처리하기 위해 performSyncWorkOnRoot()를 root에 스케줄링5 시킵니다.

reconciler > ReactFiberWorkLoop.js

  
function ensureRootIsScheduled(root: FiberRoot) {
  const lastExpiredTime = root.lastExpiredTime;
  if (lastExpiredTime !== NoWork) {
    // Special case: Expired work should flush synchronously.
    root.callbackExpirationTime = Sync;
    root.callbackPriority = ImmediatePriority;
    root.callbackNode = scheduleSyncCallback(
      performSyncWorkOnRoot.bind(null, root),
    );
    return;
  }
  /*...*/
}

정리하자면 sync work가 실행되는 경우는 두 가지입니다. concurrent -> sync와 처음부터 sync인 경우이며 이때 expirationTime을 구하는 방식이 다르기 때문에 아래 4번 라인이 필요한 것입니다.

reconciler > ReactFiberWorkLoop.js

  
function performSyncWorkOnRoot(root) {
  /*...*/
  // const expirationTime = lastExpiredTime !== NoWork ? lastExpiredTime : Sync;

  if (root !== workInProgressRoot || expirationTime !== renderExpirationTime) {
    prepareFreshStack(root, expirationTime);
  }

  /*...*/
}

if 문6의 의미를 알아보겠습니다.

이 부분도 concurrent mode와 연관이 있는데 자바스크립트는 멀티 스레드 환경에서 실행되는 게 아니므로 리액트는 하나의 VDOM에 대한 Work만 진행할 수 있습니다. 그래서 reconciler가 작업 중인 root를 전역변수 workInProgressRoot로 잡아둘 수 있는 것입니다.

하지만 현재 가장 우선순위가 높은 Task의 root가 작업 중이던 workInProgressRoot와 다르다면6 reconciler의 컨텍스트는 새로운 작업을 진행하기 위해 초기화7 해야 합니다.

expirationTime !== renderExpirationTime도 root와 비슷한 의미로 다른 작업이 더 우선순위가 높아 이전 작업을 초기화 해야 함을 나타냅니다.

VDOM에는 하나의 root만 존재합니다. 이 말인즉슨 root가 다르다는 의미는 ReactDOM.render()를 통해 만들어진 다른 VDOM에서 발생한 작업이 더 우선순위가 높다는 말입니다. 그래서 새로운 VDOM root에 재조정 작업을 진행하기 위한 작업용 트리를 만드는 함수가 prepareFreshStack()입니다.

renderExpirationTime는 초기에는 noWork0입니다. 만약 맨 처음으로 performSyncWorkOnRoot()가 호출되는 경우 if문6은 true일 것이고(expirationTime !== noWork) 재조정 작업 전에 항상 초기화될 것입니다.

prepareFreshStack()은 current의 최상단 노드인 Host root를 복제하여 workInProgress tree의 Host root를 만듦과 동시에 reconciler의 컨텍스트 변수들을 초기화합니다.

reconciler > ReactFiberWorkLoop.js

  
function prepareFreshStack(root, expirationTime) {
  root.finishedWork = null; 
  root.finishedExpirationTime = NoWork;

  workInProgressRoot = root;
  workInProgress = createWorkInProgress(root.current, null, expirationTime);
  renderExpirationTime = expirationTime;
  workInProgressRootExitStatus = RootIncomplete;
  workInProgressRootFatalError = null;
  workInProgressRootLatestProcessedExpirationTime = Sync;
  workInProgressRootLatestSuspenseTimeout = Sync;
  /*...*/
}

workInProgress를 만들 때 매번 새로운 객체로 만들어내지 않습니다. 재조정 작업은 매우 반복적으로 발생하는 작업입니다. 그래서 매번 객체를 만들어 리소스를 낭비하지 않고 기존에 만들어진 객체를 재활용하고 속성만 초기화합니다.

export function createWorkInProgress(
  current: Fiber,
  pendingProps: any,
  expirationTime: ExpirationTime,
): Fiber {
  let workInProgress = current.alternate;
  // 새로 생성
  if (workInProgress === null) {
    workInProgress = createFiber(
      current.tag,
      pendingProps,
      current.key,
      current.mode,
    );
    workInProgress.elementType = current.elementType;
    workInProgress.type = current.type;
    workInProgress.stateNode = current.stateNode;

    workInProgress.alternate = current;
    current.alternate = workInProgress;

  // 재활용
  } else {
    // 기존 객체에서 재활용 하지 못하는 속성들은 초기화 해준다.
    workInProgress.pendingProps = pendingProps;
    workInProgress.effectTag = NoEffect;
    workInProgress.nextEffect = null;
    workInProgress.firstEffect = null;
    workInProgress.lastEffect = null;
  }
  // current와 workInProgress가 공유하는 속성들
  workInProgress.childExpirationTime = current.childExpirationTime;
  workInProgress.expirationTime = current.expirationTime;

  workInProgress.child = current.child;
  workInProgress.memoizedProps = current.memoizedProps;
  workInProgress.memoizedState = current.memoizedState;
  workInProgress.updateQueue = current.updateQueue;

  workInProgress.sibling = current.sibling;
  workInProgress.index = current.index;
  workInProgress.ref = current.ref;

  return workInProgress;
}

이쯤에서 한 가지 여러분에게 상기시켜 드릴 부분이 있습니다.

현재 위치는 재조정 작업을 진행하기 전 시작 위치이며 최상단 current을 복제한 workInProgressHost root를 만들었습니다. 여기까지만 놓고 봤을 때 컴포넌트의 상태가 변하면 항상 Host root부터 시작한다는 걸 어림짐작할 수 있습니다. 깊이가 깊은 자식의 상태 값이 바뀌어도 항상 Host root부터 시작하여 자식까지 workInProgress 트리를 만들어 가게 됩니다.

❗ workInProgress 트리만 만든다는 것이지 Host root부터 자식까지 컴포넌트을 호출하는게 아님을 유의하세요.

prepareFreshStack()이 실행된 후 VDOM의 상태는 다음과 같습니다.

root node fiber === Host root

이렇게 작업용 VDOM의 entry를 만들었습니다.

다음 포스트에서는 본격적으로 Render phase에 진입하여 Work를 진행합니다. 이 과정에서 VDOM 탐색은 어떤 방식으로 구현되어있는지, 업데이트 컴포넌트를 어떻게 찾아내는지, 재조정 작업은 무엇인지 등을 확인하게 됩니다.