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

completeWork 执行在递归节点的 Fiber 创建之后，主要是为创建好的 Fiber 节点插入内容和插入真实 DOM 树

函数开始，会执行 popTreeContext 并传入 workInProgress，这个函数应该也和 Context 相关，然后进入到 swtich 逻辑，根据 WorkInProgress Fiber 节点的 tag 属性进入不同的 case 逻辑，这里和 beginWork 基本上类似 React 的遍历顺序是从父到子，最终再从子回到父，所以首屏渲染中首先进入 completeWork 的 WorkInProgress 不一定会是 FiberNode ，在这里是 HostComponent 进入到 HostComponent 的 case 之后，又执行了一遍 popTreeContext，官方的注释也写明似乎是有一些考虑在 在 HostComponent 的 case 中，会判断 current 和 WorkInProgress.stateNode 是否为空，在首屏渲染的 completeWork 节点，这里都是空的，所以进入为空的逻辑：先检查当前 Fiber 节点是否存在 props 属性，最后调用 createInstance 创建一个 DOM 实例 createInstance 会调用 createElement 方法创建一个 DOM 实例，并调用 precacheFiberNode 和 updateFiberProps 方法，这两个方法都是在插入属性，一个在当前 WorkInProgress Fiber 节点上插入 DOM，一个是在 DOM 上插入 props，最后将处理好的 DOM 返回

appendAllChildren

函数首先会判断 WorkInProgress 的 child 属性是否为空，如果不为空就进入 while 循环，因为这里是首屏渲染的第一次 completeWork 所以进入到一定是最小的子组件，不会存在 child 属性，所以会跳过循环，也就会跳过插入逻辑，回到 completeWork 的调用栈中

然后回到 completeWork 的调用栈，它会将处理完毕的 DOM 示例插入到 WorkInProgress 的 stateNode 属性中，然后会调用 inalizeInitialChildren ，这个函数会为创建的 DOM 元素，插入已有的 props，内部也根据 Fiber 节点的 tag 区分不同的处理逻辑，还有对 props 是否合法的校验，甚至根据 props 的属性也做了不同逻辑的处理，最后会返回一个 Boolean 用于判断是否进入 markUpdate 逻辑，这个函数会把 Fiber 打上 Update 标记 最后再执行 bubbleProperties 进行一些处理，不谈 整个 completeWork 的流程就走完了

completeWork

和首屏渲染不同，这次 current 和 WorkInProgress.stateNode 不为空，所以会进入和首屏渲染时不一样的逻辑：调用 updateHostComponent 函数

updateHostComponent

函数内部会对当前 WorkInProgress Fiber 节点的新旧 props 进行对比，如果完全相同会直接返回，这里的完全相同实际上是指引用地址也相同，所以在本次就算新旧 props 相同也并会被 return，然后取出 Fiber 中的 stateNode 传递给 prepareUpdate 函数，然后被调用 diffProperties 函数，这里还有一个针对 props 的 children 属性是否为字符串或者数字的判断，暂时还不清楚具体目的是什么

diffProperties

函数开始会先执行对 props 属性的校验方法：validatePropertiesInDevelopment 方法，然后根据 Fiber tag 进入不同的 case，这里只有针对三种 tag有特殊的处理，分别是：input、select 和 textarea，本次进入 completeWork 的 Fiber 节点 tag 为 img，所以不会进入 特殊处理的 case，最终进入到 default 逻辑，然后被直接 break，去往 assertValidProps 函数 这里还有一个针对 Fiber 旧 props 属性 onClick 不是 function 且 新 props 属性 onClick 是 function 的一个特殊处理：就是直接给 DOM 的 onclick 属性赋值为一个空函数 ，从官方留下的注释中大概可以知道，这似乎是为了修复 Safari 浏览器的问题的特殊处理

assertValidProps

函数一开始会检查 props 是否存在，不存在直接 return 然后就是一大串的 if 用于对 props 是否合法的兜底操作，比如说 dangerouslySetInnerHTML 属性和 children 属性智能存在一个之类的，如果找到不合法的操作会直接通过 throw Error 被抛出

之后就进入 diffProperties 最主要的任务：对新旧 props 进行对比然后生成 updateQueue 这里有两个 for in 循环：循环旧 props 属性和循环新 props 属性

警告：以下解析受限于我的表达能力，可能会有读起来一头雾水的情况，建议和源码一起看

循环旧 props 属性：

• 以下条件跳出当前循环：
  1. 新 props 自身不存在相同属性
  2. 属性非旧 props 自身属性
  3. 该属性在旧 props 的值为 null
• 当找到 style 属性，会遍历 style 属性，初始化 styleUpdates 对象为空，并在上边新增当前 style 属性的 key 并赋值空字符串
• 当找到一些特殊属性如 dangerouslySetInnerHTML 等，会初始化 updatePayload 为空数组
• 如果没有以上属性，即没有 style 和 特殊属性，会进入最后的 else 逻辑：给 updatePayload 数组 push 进属性名和 null，进入下一轮循环

循环新 props 属性：

• 以下条件跳出当前循环：
  1. 新 props 自身不存在当前属性
  2. 新 props 属性值和旧 props 属性值相同（引用相同）
  3. 新旧 props 属性值都为 null
• 当找到 style 属性：
  • 如果新 props 属性值存在且值合法（就是转换成 boolean 不为 false），会调用 Object.freeze 函数冻结当前属性值
  • 如果旧 props 也存在 style 属性且不等于 null：
    • 开始遍历旧 props style
      • 如果出现旧 props style 有 style 样式，但是新 props style 没有的也就是新增样式的情况，那么会初始化 styleUpdates 对象为空（如果已经初始化过就会跳过），并在上边新增当前 style 属性的 key 并赋值空字符串
    • 开始遍历新 props style
      • 如果找到新 props style 属性存在，但是与旧 props style 属性不同，也就是样式发生修改的情况，那么会初始化 styleUpdates 对象为空（如果已经初始化过就会跳过），并在上边对当前 style 属性的 key 做新增或是修改，值为新 props style 属性
  • 如果旧 props 不存在 style 属性 或者等于 null：
    • 如果 styleUpdates 不为 null，且是数组时长度不等于 0，给 updatePayload push 进 style 和 styleUpdates
    • 否则给 styleUpdates 赋值 props style 属性
• 当找到特殊属性 dangerouslySetInnerHTML ：
  • 会与旧 props 的 dangerouslySetInnerHTML 对比，发生变化则 push 进 updatePayload 数组
• 当找到 children 属性，会将其转换为字符串和 属性名一起 push 进 updatePayload
• 当找到除 dangerouslySetInnerHTML 之外的特殊属性，会对其进行专属的逻辑
• 最后没有找到以上属性，会进入最后的 else 逻辑：给 updatePayload 数组 push 进 props 属性名和 对应的属性值，进入下一轮循环

当所有的循环结束会判断 styleUpdates 是否合法（不为 null，且数组长度不为0），合法则进入将调用 validateShorthandPropertyCollisionInDev 函数，传递 styleUpdates 和 新 props style 属性，最后将 style 字符串 和 styleUpdates 推入 updatePayload 返回 updatePayload

回到 updateHostComponent 函数，将 prepareUpdate 也就是 diffProperties 返回的 updatePayload 赋值给 workInProgress 的 updateQueue 属性，如果它不为空则执行 markUpdate 函数

markUpdate

为传入的 workInProgress 打上 Update 标记

返回 null，回到 completeWork 的调用栈，如果 current ref 和 workInProgress ref 不同，调用 markRef 函数

markRef

为传入的 workInProgress 打上 Ref 和 RefStatic 标记

最后调用 bubbleProperties 函数，这又是一个比较长的函数，暂且不谈

completeWork 逻辑结束