vault backup: 2022-05-08 17:28:09

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

@@ -4,8 +4,6 @@
 
 本次源代码解读的 DEMO 只用了最简单的 `useState` 做计数器修改触发页面刷新，并没有新增新的 DOM 节点之外的其他操作，第一次和第二次和之后页面刷新实际上都只是 `useState` 触发变化并在页面上显示计数内容出现变化
 
-## React 17
-
 Fiber 递归开始首先会交由 createWorkInProgress 函数生成 WorkInProgress 的第一个 Fiber 节点，这个节点就是 FiberNode，所以我们也从 createWorkInProgress 函数开始讲解 React 中 Fiber 递归的流程，**这个函数的主要工作就是根据传入的 Fiber 节点的判断复用 Fiber 节点还是创建新的 Fiber 节点**，而这个判断的条件就是传入的 Fiber 节点的 alternate 属性是否存在。
 
 在第一次进入到这个函数时也就是首屏渲染中传入的 FiberNode 是不存在这个属性的，所以会进入到 createFiber 函数：即执行创建新 Fiber 节点的逻辑。
@@ -60,91 +58,5 @@ 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` 属性
-- 当找到特殊属性 `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 逻辑结束
-
 
 你可以会问我，到这里就没有了吗？，是的没有了，这就是一个简单例子下 `React Fiber` 递归的全部流程，从 `beginWork` 到 `completeWork`，从首屏渲染到触发更新，没有涉及到新增节点和删除属性的情况，但是简单的递归逻辑已经是到这里就结束了，后边还会写更加详细的单个 render 阶段函数的详细解析和 commit 阶段的流程解析

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

@@ -34,3 +34,16 @@ updateHostRoot 函数中首先会执行 pushHostRootContext 方法，这个方
 最终调用 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 流程执行结束

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

@@ -5,3 +5,7 @@
 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` 开始正式的递归
+
+### createWorkInProgress
+
+还是交由 createWorkInProgress 这个函数，这个函数会从 current 中取出 alternate 属性，用于判断是否已经存在 WorkInProgress 树，在本次更新，当前的 current 就是上一次渲染的 WorkInProgress，首屏渲染完成之后，实际上只渲染完成了一棵树，但是这次的 WorkInProgress 并不会走等于 null 的逻辑，因为在首屏渲染的时候，那个还是 current 的 WorkInProgress 实际上已经有一个 Fiber 节点了，那就是 FiberNode ，所以在这次渲染，它也还是有那一个 FiberNode 的，所以会走不为空的逻辑：复用现有的 Fiber 节点，其他和首屏渲染是一样的，这里不多赘述