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

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

@@ -1,8 +1,6 @@
->React 从 16 开始，对底层架构做了一次重构，和 15 不同，渲染 vdom 的时候一改以往的递归执行，引入了一个新的概念，叫做 Fiber，虽然最后渲染到页面的时候还是递归，但是 Fiber 的递归是可以中断的，根据优先级由浏览器优先执行任务，保证在大量视图需要更新的时候，浏览器仍然能保证快速的响应
+>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` 触发变化并在页面上显示计数内容出现变化
+在 React 中，视图的更新使用了双缓存的方式，也就是说在 React 运行时，同时有着两棵 Fiber 树，一颗是当前视图上的 Fiber 树，叫 current，另外一棵是存在内存当中的下一次视图更新时用的叫做 workInProgress，React 在构建时会创建整个 app 唯一的根 Fiber 节点，叫做 FiberRootNode，这个节点上有一个 current 指针，指向的是当前正在页面上显示的 Fiber 树也就是 current，当 workInProgress 递归生成完毕，指针会立即指向 workInProgress ，而旧的 current 则会在下一次渲染中变成 workInProgress ，就这样循环交替完成页面的递归渲染。
 
 Fiber 递归开始首先会交由 createWorkInProgress 函数生成 WorkInProgress 的第一个 Fiber 节点，这个节点就是 FiberNode，所以我们也从 createWorkInProgress 函数开始讲解 React 中 Fiber 递归的流程，**这个函数的主要工作就是根据传入的 Fiber 节点的判断复用 Fiber 节点还是创建新的 Fiber 节点**，而这个判断的条件就是传入的 Fiber 节点的 alternate 属性是否存在。
 
@@ -48,15 +46,8 @@ completeWork 负责深度优先遍历中的回溯阶段，**它执行在递归
 
 和 beginWork 中相同，completeWork 的主要逻辑也是一个巨大的 switch，根据 Fiber 节点的类型进入不同的处理逻辑 [[React 的深入探索 - completeWork]]
 
-如果最终回溯到了 Fiber 的起始节点，那么整个首屏渲染的 Fiber 递归渲染逻辑就完成了，最后会交由 commitRoot 函数进入 commit 阶段将其渲染到页面上
+如果最终回溯到了 Fiber 的起始节点，那么整个首屏渲染的 Fiber 递归渲染逻辑就完成了，最后会交由 commitRoot 函数进入 commit 阶段将其渲染到页面上：[[React 的流程解析 - commit阶段]]
 
 这里你可以会有一个疑惑，在 Fiber 递归阶段也就是 reconciler 阶段，会深度优先遍历找出所有的存在变化的 Fiber 节点，并将其打上对应的 effectTag，**那么进入 commit 阶段后，也需要再次进行一次深度优先遍历找出这些存在 effectTag 的 Fiber 节点吗？**
 
-其实是不需要的，因为这样的效率太低了，在深度优先遍历的回溯阶段也就是 completeWork 的执行逻辑中，会将所有存在 effectTag 的 Fiber 节点通过单项链表的形式连接起来，这样在 commit 阶段的时候只需要遍历这一条链表就能快速的找到发生了变化的 Fiber 节点：[[effectList 的生成]]
-
-[[React 的流程解析 - commit阶段]]
-
-## 第一次触发更新
-
-
-你可以会问我，到这里就没有了吗？，是的没有了，这就是一个简单例子下 `React Fiber` 递归的全部流程，从 `beginWork` 到 `completeWork`，从首屏渲染到触发更新，没有涉及到新增节点和删除属性的情况，但是简单的递归逻辑已经是到这里就结束了，后边还会写更加详细的单个 render 阶段函数的详细解析和 commit 阶段的流程解析
+其实是不需要的，因为这样的效率太低了，在深度优先遍历的回溯阶段也就是 completeWork 的执行逻辑中，会将所有存在 effectTag 的 Fiber 节点通过单项链表的形式连接起来，这样在 commit 阶段的时候只需要遍历这一条链表就能快速的找到发生了变化的 Fiber 节点：[[effectList 的生成]]

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

@@ -10,4 +10,75 @@ createInstance 会调用 createElement 方法创建一个 DOM 实例，并调用
 函数首先会判断 WorkInProgress 的 child 属性是否为空，如果不为空就进入 while 循环，因为这里是首屏渲染的第一次 completeWork 所以进入到一定是最小的子组件，不会存在 child 属性，所以会跳过循环，也就会跳过插入逻辑，回到 completeWork 的调用栈中
 
 然后回到 completeWork 的调用栈，它会将处理完毕的 DOM 示例插入到 WorkInProgress 的 stateNode 属性中，然后会调用 inalizeInitialChildren ，这个函数会为创建的 DOM 元素，插入已有的 props，内部也根据 Fiber 节点的 tag 区分不同的处理逻辑，还有对 props 是否合法的校验，甚至根据 props 的属性也做了不同逻辑的处理，最后会返回一个 Boolean 用于判断是否进入 markUpdate 逻辑，这个函数会把 Fiber 打上 Update 标记
-最后再执行 bubbleProperties 进行一些处理，~~不谈~~ 整个 completeWork 的流程就走完了
+最后再执行 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 逻辑结束