Obsidian_Note/React 的深入探索/React 的流程解析 - Fiber 递归/React 的深入探索 - beginWork.md

>beginWork 执行在递归节点的 Fiber 创建之前，主要是为传入的 Fiber 节点根据类型创建第一个子 Fiber 节点

[代码位置](https://github.com/facebook/react/blob/bd4784c8f8c6b17cf45c712db8ed8ed19a622b26/packages/react-reconciler/src/ReactFiberBeginWork.old.js#L3818)

```javascript
function beginWork(current, workInProgress, renderLanes) {

	// 前 beginWork 阶段
	if (current !== null) {
		......
	} else {
		......
	}

	// 正式 beginWork 阶段
	switch (workInProgress.tag) {
		......
	}
}
```

beginWork 函数接受三个参数，分别是 current 节点，workInProgress 节点和 renderLanes 优先级，根据 beginWork 函数的结构，我们可以分成两个阶段，分别是：前 beginWork 阶段和正式 beginWork 阶段

## 前 beginWork 阶段

```javascript
if (current !== null) {
	......
} else {
	didReceiveUpdate = false;
}
```

在进入正式 beginWork 阶段之前，会先对传入的 current 节点进行空值判断，根据 current 是否为空进入不同的处理逻辑。

**那么为什么需要判断 current 是否为空呢？答案是为了性能，前面说到 beginWork 函数的主要任务就是给当前传入的 Fiber 节点创建它的第一个子 Fiber 节点，要是在上次更新和本次更新中当前的 Fiber 节点并没有发生变化，那么还需要再次创建一个新的 Fiber 节点吗？肯定是不需要的，所以我们只需要将这个已经存在的并没有发生变化的 Fiber 节点拿过来复用就行了，而这段逻辑正是在前 beginWork 阶段中判断并执行的**
这一段代码的主要目的是为了赋值 didReceiveUpdate  变量，这个变量表示在本次更新中当前 current 节点是否存在变化

### current 不为空

在 current 不为空的逻辑中，会先取出先前存储在 Fiber 节点中的新旧 props，连同其他几个判断条件一起做 if 判断，判断条件如下：
1. 用三等判断 props 是否发生变化
2. 检查 context 是否发生变化
3. 检查新旧 Fiber type 是否发生变化

如果判断条件为 true 则会给 didReceiveUpdate 变量赋值为 true，进入正式 beginWork 阶段

```javascript
var oldProps = current.memoizedProps;
var newProps = workInProgress.pendingProps;

if (
	// 对比新旧 props
	oldProps !== newProps ||
	// 检查 context 是否发生变化
	hasContextChanged() || 
	// 判断 Fiber type 是否发生变化
	(workInProgress.type !== current.type )
) {
	didReceiveUpdate = true;
} else {
	......
}
```

如果判断条件为 false，会进入后续判断逻辑

此时会先调用 checkScheduledUpdateOrContext 函数检查 current 是否存在优先级相关的更新，关于 React 优先级相关我们先暂且按表不谈，进入 if 判断

- 不存在优先级相关的更新且 workInProgress 节点不存在 DidCapture flag
	- True：跳过后续的正式 beginWork 阶段，进入 baliout 也就是组件复用逻辑
	- False：判断当前 current 节点是否存在 ForceUpdateForLegacySuspense flag
		- True：didReceiveUpdate 赋值为 true
		- False：didReceiveUpdate 赋值为 false

```javascript
// props 和 context 都没有发生变化，检查优先级相关
var hasScheduledUpdateOrContext = checkScheduledUpdateOrContext(current, renderLanes);

if (
	// 不存在优先级相关的更新c
	!hasScheduledUpdateOrContext &&
	// workInProgress 节点上不存在 DidCapture flag
	(workInProgress.flags & DidCapture) === NoFlags
) {
	didReceiveUpdate = false;
	// 这里会跳过正式 beginWork 阶段，进入 baliout 逻辑也就是组件复用
	return attemptEarlyBailoutIfNoScheduledUpdate(
			current,
			workInProgress,
			renderLanes
		);
}

// current 节点不存在 ForceUpdateForLegacySuspense flag
if ((current.flags & ForceUpdateForLegacySuspense) !== NoFlags) {
	didReceiveUpdate = true;
} else {
	didReceiveUpdate = false;
}
```

### current 为空

首先 didReceiveUpdate 会被赋值为 false，紧接着会进入一个似乎关于 SSR 服务端渲染的判断逻辑，代码内容如下，这一段代码的行为还不清楚，暂时先跳过

```javascript
didReceiveUpdate = false;
// 检查 hydrate 状态 和 是否存在 Forked flag
if (getIsHydrating() && isForkedChild(workInProgress)) {
	// 后续的逻辑似乎和 SSR 服务端渲染有关
	// 根据官方的注释，这边的代码似乎是为了给 React 的并发模式铺路
	var slotIndex = workInProgress.index;
	var numberOfForks = getForksAtLevel();
	pushTreeId(workInProgress, numberOfForks, slotIndex);
}
```

至此整个前 beginWork 阶段就结束了，我们可以在这里做个小小的总结：**在前beginWork 阶段主要是判断当前组件是否发生变化需要更新， 是否可以复用，在满足复用条件情况下会跳过 正式beginWork 阶段进入 baliout 逻辑而不再创建新的 Fiber 节点，从中可以看到对于特殊组件如 Suspense 而言可能并不会进入 baliout 逻辑**

在此之外我们也可以看到一些很有意思的点：**对于组件新旧 props 对比使用的是简单的三等判断**

## 正式 beginWork 阶段

正式 beginWork 阶段开始，会将 workInProgress 的 lanes 清空，接着会进入一个 switch 逻辑，根据 tag 不同进入对应的 case 处理逻辑，代码如下：

```javascript
workInProgress.lanes = NoLanes;

switch (workInProgress.tag) {
	case IndeterminateComponent: ...
	case LazyComponent: ...
	// Function Component 处理逻辑
	case FunctionComponent: ...
	// Class Component 处理逻辑
	case ClassComponent: ...
	case HostRoot: ...
	case HostComponent: ...
	case HostText: ...
	// Suspense 处理逻辑
	case SuspenseComponent: ...
	case HostPortal: ...
	case ForwardRef: ...
	case Fragment: ...
	case Mode: ...
	case Profiler: ...
	case ContextProvider: ...
	case ContextConsumer: ...
	case MemoComponent: ...
	case SimpleMemoComponent: ...
	case IncompleteClassComponent: ...
	case SuspenseListComponent: ...
	case ScopeComponent: ...
	case OffscreenComponent: ...
	case LegacyHiddenComponent: ...
	case CacheComponent: ...
}
```

switch 中的 case 逻辑太多了，全部都写出来会让笔记显得特别繁杂，这里只写出几个常用的处理逻辑如 HostComponent、FunctionComponent，其他处理逻辑后边有时间再另起一篇文章阐述

### updateHostRoot

首先会执行 pushHostRootContext 函数，这个函数与 context  有关，暂且不谈

然后会接着执行 cloneUpdateQueue 方法

**cloneUpdateQueue**

 这个方法比较简单，会判断 current 和  workInProgress 中的 updateQueue 是否相同，如果相同会创建新的对象重复赋值以清除引用，这里是为了保证后续对 workInProgress 的操作不会影响到 current 

```javascript
function cloneUpdateQueue(current, workInProgress) {
	var queue = workInProgress.updateQueue;
	var currentQueue = current.updateQueue;

	// 用三等对比更新队列，如果为 true 表示 queue 还未清除引用
	if (queue === currentQueue) {
		// 清除引用
		var clone = {
			baseState: currentQueue.baseState,
			firstBaseUpdate: currentQueue.firstBaseUpdate,
			lastBaseUpdate: currentQueue.lastBaseUpdate,
			shared: currentQueue.shared,
			effects: currentQueue.effects
		};
		// 赋值
		workInProgress.updateQueue = clone;
	}
}
```

从 cloneUpdateQueue 函数出来回到 updateHostRoot 调用栈，会紧接着执行  processUpdateQueue 方法，这个方法和更新队列有关，暂时不展开讲

```javascript
function updateHostRoot(current, workInProgress, renderLanes) {
	// context 相关
	pushHostRootContext(workInProgress);
	// 取出 updateQueue
	var updateQueue = workInProgress.updateQueue;
	if (current === null || updateQueue === null) {
		throw new Error("...");
	}

	// 取出组件新 props
	var nextProps = workInProgress.pendingProps;
	// 取出组件 state
	var prevState = workInProgress.memoizedState;
	// 从 state 中取出 element
	var prevChildren = prevState.element;
	cloneUpdateQueue(current, workInProgress);
	processUpdateQueue(workInProgress, nextProps, null, renderLanes);
	var nextState = workInProgress.memoizedState;
	var root = workInProgress.stateNode;

	{
	    var nextCache = nextState.cache;
	    pushRootCachePool(root);
		pushCacheProvider(workInProgress, nextCache);
	    
	    if (nextCache !== prevState.cache) {
		    propagateContextChange(
			    workInProgress,
			    CacheContext,
			    renderLanes
			);
	    }
	}

	......
}
```

再往后是一些针对服务端渲染的一些处理逻辑，服务端渲染也不是这次讨论的目的，也先跳过
最终调用 reconcileChildren 为 FIber 创建一个子 Fiber 节点并返回

至此一个节点的 beginWork 流程就走完了，下一次会根据是否存在子 Fiber 节点判断是执行当前 WorkInProgress Fiber 节点的 completeWork ，还是继续对子节点执行 beginWork


### beginWork

第一次触发更新，进入这个函数的逻辑前边和首屏渲染是都是一样的，但是在判断组件是否发生修改的时候逻辑和首屏渲染并不同，在首屏渲染，beginWork 会走到 switch 逻辑，并根据 Fiber tag 不同分别执行不同的 mount l逻辑，在这里会经过一些判断最终进入 attemptEarlyBailoutIfNoScheduledUpdate 这个函数，这个函数内部又有着一个 switch 逻辑，也是根据 workInProgress tag 属性分别进入不同的 case，在这个例子中进入的是 HostRoot 对应的 case，首先会执行 pushHostRootContext 函数，Context 相关 ~~不谈~~，最后继续处理服务端渲染的逻辑最后返回交由 bailoutOnAlreadyFinishedWork 函数处理，bailoutOnAlreadyFinishedWork 会对 WorkInProgress 赋上 current 的 dependencies 属性，然后就是 bailoutOnAlreadyFinishedWork 最终的目的： 调用 cloneChildFibers

### cloneChildFibers

这个函数从名字上就能看出来，目的是为了 clone Fiber 的 child 属性，这个函数会调用 createWorkInProgress 函数，从上边可以知道，这个函数可以根据传入的 current 和 WorkInProgress 进行判断是否创建一个新的 Fiber 节点或者复用已有的 current Fiber 节点，并将其互相链接，最终将结果返回，cloneChildFiber 接收到返回的 Fiber 子节点，将其链接到当前 WorkInProgress Fiber 的 child 属性上，并把 Fiber 子节点的 return 赋值 WorkInProgress Fiber

也就是说，如果在 beginWork 中当前，如果组件并没有发生变化且没有要执行的逻辑，那么他会直接 clone 已有的 Fiber 节点，而不会走到 reconcileChildren 函数创建新的 Fiber 节点

最后返回到 bailoutOnAlreadyFinishedWork 在由它返回到 beginWork，beginWork 流程执行结束