|
|
@ -100,24 +100,29 @@ if ((current.flags & ForceUpdateForLegacySuspense) !== NoFlags) { |
|
|
|
} |
|
|
|
} |
|
|
|
``` |
|
|
|
``` |
|
|
|
|
|
|
|
|
|
|
|
至此 current 不为空的逻辑就结束了,我们可以在这里做个小小的总结:**在 前beginWork 阶段主要是判断当前组件是否发生变化需要更新, 是否可以复用,在满足复用条件情况下会跳过 正式beginWork 阶段进入 baliout 逻辑而不再创建新的 Fiber 节点,从中可以看到对于特殊组件如 Suspense 而言可能并不会进入 baliout 逻辑** |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
在此之外我们也可以看到一些很有意思的点:**对于组件新旧 props 对比使用的是简单的三等判断** |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### current 为空 |
|
|
|
### current 为空 |
|
|
|
|
|
|
|
|
|
|
|
首先 didReceiveUpdate 会被赋值为 false |
|
|
|
首先 didReceiveUpdate 会被赋值为 false |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
紧接着会进入一个似乎关于 SSR 服务端渲染的判断逻辑,代码内容如下,这一段代码的行为还不清楚,暂时先跳过 |
|
|
|
|
|
|
|
|
|
|
|
```javascript |
|
|
|
```javascript |
|
|
|
didReceiveUpdate = false; |
|
|
|
didReceiveUpdate = false; |
|
|
|
// 检查 hydrate 状态 和 是否存在 Forked flag |
|
|
|
// 检查 hydrate 状态 和 是否存在 Forked flag |
|
|
|
if (getIsHydrating() && isForkedChild(workInProgress)) { |
|
|
|
if (getIsHydrating() && isForkedChild(workInProgress)) { |
|
|
|
|
|
|
|
// 后续的逻辑似乎和 SSR 服务端渲染有关 |
|
|
|
|
|
|
|
// 根据官方的注释,这边的代码似乎是为了给 React 的并发模式铺路 |
|
|
|
var slotIndex = workInProgress.index; |
|
|
|
var slotIndex = workInProgress.index; |
|
|
|
var numberOfForks = getForksAtLevel(); |
|
|
|
var numberOfForks = getForksAtLevel(); |
|
|
|
pushTreeId(workInProgress, numberOfForks, slotIndex); |
|
|
|
pushTreeId(workInProgress, numberOfForks, slotIndex); |
|
|
|
} |
|
|
|
} |
|
|
|
``` |
|
|
|
``` |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
至此整个前 beginWork 阶段就结束了,我们可以在这里做个小小的总结:**在前beginWork 阶段主要是判断当前组件是否发生变化需要更新, 是否可以复用,在满足复用条件情况下会跳过 正式beginWork 阶段进入 baliout 逻辑而不再创建新的 Fiber 节点,从中可以看到对于特殊组件如 Suspense 而言可能并不会进入 baliout 逻辑** |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
在此之外我们也可以看到一些很有意思的点:**对于组件新旧 props 对比使用的是简单的三等判断** |
|
|
|
|
|
|
|
|
|
|
|
## 正式 beginWork 阶段 |
|
|
|
## 正式 beginWork 阶段 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|