|
|
|
@ -33,6 +33,9 @@ updateHostRoot 函数中首先会执行 pushHostRootContext 方法，这个方 |
|
|
|
在 updateHostRoot 逻辑一开始，它会将 current 和 WorkInProgress 传递给 cloneUpdateQueue 这个函数，这个函数会将 Fiber 中的 queue 属性进行 clone，除非它们已经是 clone 之后的属性，那么具体是怎么做的判断是否是 clone 过的属性呢？其实很简单，它只是使用了 === 三个等于判断属性的引用是否相同，也就是说这个函数实际上做的是清除引用，保证在之后对 WorkInProgress 的操作不会影响到 current Fiber 树，判断两个 Fiber 树的 updateQueue 属性的引用完全相同，那么就会创建一个新的对象并重复赋值达到清除应用的目的，最后赋值给 WorkInProgress Fiber 节点 |
|
|
|
在 updateHostRoot 逻辑一开始，它会将 current 和 WorkInProgress 传递给 cloneUpdateQueue 这个函数，这个函数会将 Fiber 中的 queue 属性进行 clone，除非它们已经是 clone 之后的属性，那么具体是怎么做的判断是否是 clone 过的属性呢？其实很简单，它只是使用了 === 三个等于判断属性的引用是否相同，也就是说这个函数实际上做的是清除引用，保证在之后对 WorkInProgress 的操作不会影响到 current Fiber 树，判断两个 Fiber 树的 updateQueue 属性的引用完全相同，那么就会创建一个新的对象并重复赋值达到清除应用的目的，最后赋值给 WorkInProgress Fiber 节点 |
|
|
|
之后，再把 WorkInProgress Fiber 节点交给 processUpdateQueue 函数，这个函数主要是处理更新队列，在这里先不展开，TODO |
|
|
|
之后，再把 WorkInProgress Fiber 节点交给 processUpdateQueue 函数，这个函数主要是处理更新队列，在这里先不展开，TODO |
|
|
|
再往后是一些针对服务端渲染的一些处理逻辑，服务端渲染也不是这次讨论的目的，也先跳过 |
|
|
|
再往后是一些针对服务端渲染的一些处理逻辑，服务端渲染也不是这次讨论的目的，也先跳过 |
|
|
|
|
|
|
|
最终调用 reconcileChildren 为 FIber 创建一个子 Fiber 节点并返回 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
至此一个节点的 beginWork 流程就走完了，下一次会根据是否存在子 Fiber 节点判断是执行当前 WorkInProgress Fiber 节点的 completeWork ，还是继续对子节点执行 beginWork |
|
|
|
|
|
|
|
|
|
|
|
### completeWork |
|
|
|
### completeWork |
|
|
|
|
|
|
|
|
|
|
|
|
