>React 从 16 开始，对底层架构做了一次重构，和 15 不同，渲染 vdom 的时候一改以往的递归执行，引入了一个新的概念，叫做 Fiber，虽然最后渲染到页面的时候还是递归，但是 Fiber 的递归是可以中断的，根据优先级由浏览器优先执行任务，保证在大量视图需要更新的时候，浏览器仍然能保证快速的响应 在 React 中，视图的更新使用了双缓存的方式，也就是说在 React 运行时，同时有着两棵 Fiber 树，一颗是当前视图上的 Fiber 树，叫 `current`，另外一棵是存在内存当中的下一次视图更新时用的叫做 `workInProgress`，React 在构建时会创建整个 app 唯一的根 Fiber 节点，叫做 `FiberRootNode`，这个节点上有一个 `current 指针`，指向的是当前正在页面上显示的 Fiber 树也就是 `current`，当 `workInProgress` 递归生成完毕，指针会立即指向 workInProgress ，而旧的 `current` 就会在下一次渲染中变成 `workInProgress` ，就这样循环交替完成页面的递归渲染 本次源代码解读的 DEMO 只用了最简单的 `useState` 做计数器修改触发页面刷新，并没有新增新的DOM 节点之外的其他操作，第一次和第二次和之后页面刷新实际上都只是 `useState` 触发变化并在页面上显示计数内容出现变化 ## 首屏渲染 ### createWorkInProgress React 的首屏渲染时会交由 `createWorkInProgress` 函数生成一个 WorkInProgress Fiber 节点，这个节点就是 FiberNode，`createWorkInProgress` 接收两个参数，分别是 `current` 和 `pendingProps`，这里的 `pendingProps` 是组件的属性 因为传入的是 current Fiber 树，所以 `createWorkInProgress` 内会从 `current` 的 `alternate` 取出中取出与之链接的 WorkInProgress Fiber 节点，并对其做空值判断，因为对于首屏渲染而言，WorkInProgress 是不存在的，所以会走到不存在 WorkInProgress 的逻辑，在这里也就是调用 `createFiber` 函数，这个函数会更加传递的参数 `new` 一个 Fiber 的实例，其内部并没有什么复杂的逻辑，而是对 Fiber 节点的属性进行了初始化，`createFiber` 返回之后，会对返回的 FiberNode 节点进行赋值，复用 current FiberNode 节点的内容，并对它们各自的 alternate 进行赋值，双向链接 `createWorkInProgress` 之后，Fiber 的操作就会交由 `beginWork` 和 `completeWork` 开始正式的递归 ### beginWork >beginWork 执行在递归节点的 Fiber 创建之前，主要是为传入的 Fiber 节点根据类型创建第一个子 Fiber 节点 首先会对 current 做空值判断，因为对于首屏渲染而言，当前传入的 current Fiber 节点是 FiberNode，所以是存在的，会进入 current !== null 的逻辑，然后会判断当前 Fiber 节点是否发生变化，然后赋值 `didReceiveUpdate` 做更新标识，判断的条件如下： 1. 新旧 props 是否相同 2. Context 是否发生变化 3. Fiber 节点 type 是否发生变化 在本次首屏渲染中，以上的条件都为否，会进入后续条件判断，在后续的条件判断中主要是为了应付一些特殊的场景，例如错误边界和 legacy 模式，可以看到官方留下的代码注释，在我们现在的场景下，最终会走到 didReceiveUpdate 为 false 的情况下，也就是当前 Fiber 并没有变化，因为在之前的 createWorkInProgress 中 WorkFiberProgress 被赋值上了 current Fiber 的同名属性，所以它们会是相同的两个 FIber 节点，在这里的代码可以看到：beginWork 中还有对优先值 lanes 的一些处理，在这里先不展开，后续再补充 最后会走入 switch 环节，这了主要根据传入的 WorkInProgress Fiber 节点的类型进入不同的处理逻辑，这也是 beginWork 最主要的任务：为当前 WorkInProgress Fiber 节点创建它的第一个 Fiber 子节点，其内部根据 Fiber 的 tag 不同有对应的： - updateClassComponent 处理 Class Component - updateHostComponent 处理 Host Component - updateSuspenseComponent 处理 Suspense Component 本次的是首屏渲染，传入的 WorkInProgress Fiber 为 FiberNode，所以会进入 HostRoot 的 case，执行 updateHostRoot 方法 ### updateHostRoot updateHostRoot 函数中首先会执行 pushHostRootContext 方法，这个方法和 Context 相关，现在暂且不谈 在 updateHostRoot 逻辑一开始，它会将 current 和 WorkInProgress 传递给 cloneUpdateQueue 这个函数，这个函数会将 Fiber 中的 queue 属性进行 clone，除非它们已经是 clone 之后的属性，那么具体是怎么做的判断是否是 clone 过的属性呢？其实很简单，它只是使用了 === 三个等于判断属性的引用是否相同，也就是说这个函数实际上做的是清除引用，保证在之后对 WorkInProgress 的操作不会影响到 current Fiber 树，判断两个 Fiber 树的 updateQueue 属性的引用完全相同，那么就会创建一个新的对象并重复赋值达到清除应用的目的，最后赋值给 WorkInProgress Fiber 节点 之后，再把 WorkInProgress Fiber 节点交给 processUpdateQueue 函数，这个函数主要是处理更新队列，在这里先不展开，TODO 再往后是一些针对服务端渲染的一些处理逻辑，服务端渲染也不是这次讨论的目的，也先跳过 最终调用 reconcileChildren 为 FIber 创建一个子 Fiber 节点并返回 至此一个节点的 beginWork 流程就走完了，下一次会根据是否存在子 Fiber 节点判断是执行当前 WorkInProgress Fiber 节点的 completeWork ，还是继续对子节点执行 beginWork ### completeWork >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 的流程就走完了 ## 第一次触发更新 ### createWorkInProgress 还是交由 createWorkInProgress 这个函数，这个函数会从 current 中取出 alternate 属性，用于判断是否已经存在 WorkInProgress 树，在本次更新，当前的 current 就是上一次渲染的 WorkInProgress，首屏渲染完成之后，实际上只渲染完成了一棵树，但是这次的 WorkInProgress 并不会走等于 null 的逻辑，因为在首屏渲染的时候，那个还是 current 的 WorkInProgress 实际上已经有一个 Fiber 节点了，那就是 FiberNode ，所以在这次渲染，它也还是有那一个 FiberNode 的，所以会走不为空的逻辑：复用现有的 Fiber 节点，其他和首屏渲染是一样的，这里不多赘述 ### 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 流程执行结束 ### 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` 属性 ## 第二次触发更新和后续触发更新 ### createWorkInProgress 第一步很熟悉，有了前面两次执行的流程可以猜到，第二次触发更新也是进入这个函数，那么这次执行和之前有什么不同吗？并没有，和第一次触发更新的时候一模一样，但是在这一次更新，React 的运行时终于拥有了两颗完整的 Fiber 树 你可以会问我，到这里就没有了吗？