Liam

## setState是同步还是异步? > 基于当前最新稳定版本v16.14.0进行分析 ### 此处`同步异步`的定义 我们知道`Promise.then()`,`setTimeout`是异步执行. 从js执行来说, `setState`肯定是同步执行. 所以这里讨论的同步和异步并不是指`setState`是否异步执行, 而是指调用`setState`之后`this.state`能否立即更新. ### 分析 1. 众所周知调用`setState({item: 'new xxx'})`之后, 会将传入`setState`的参数包装成一个`update对象`并添加到`updateQueue`队列中. 2. 之后`updateQueue`队列**在什么时机被合并到`this.state`中才是本题目的关键**. 因为合并之后`this.state`必然就已经更新了. 3. state的合并是在fiber构建循环中进行的, 而fiber构建循环必然是在触发scheduler调度之后进行. 关于这一点的详细论述可以参考[react两大工作循环](https://github.com/7kms/react-illustration-series/blob/master/docs/main/workloop.md). 到这里问题转化为**调用`setState`之后, 是否立即触发scheduler调度**? - 如果立即进行scheduler调度, 那么`this.state`必然能同步获取....

从md文件的解析来看, 解析过后的`Link`组件也是相对路径: `跳转到02文章` 最终在运行时被渲染成了`跳转到02文章`, 而不是`跳转到02文章`. 这是否可能是`react-router-dom`的问题?

假设为了满足了dumi, 就应该配置成 ``` [跳转到02文章](/main/02.md) ``` 别的浏览工具, 比如直接在github上浏览, 就会造成链接404. 如果要解决的话, 是否可以在将md转换成``组件的时候将相对路径转成绝对路径.

> 关键点并非相对路径转换，还需要根据 group 和 nav 的配置去处理链接，如果有时间的话，欢迎给 dumi 提个 PR :D 思路可以再详细一点吗, 上面这一点没有理解透彻. 我理解group 和 nav 是dumi的逻辑分组, 每个分组下的页面, 都对应一个绝对路径. 按理说应该可以不用管dumi逻辑如何分组, 相对路径转换只要解析成``绝对路径是正确的, 就不会破坏dumi的路由匹配.

有可能是文件没有匹配上 ```js const babelTransformRegexp = disableTypeCheck ? /\.(t|j)sx?$/ : /\.jsx?$/; ``` `disableTypeCheck`设置为`false`只匹配`jsx?`文件. 要设置为`true`才能都匹配. 没看懂这里为什么要这样做.

What's your address in Ethereum, can it be seen in ethscan.io?

对比是在创建之前发生的 新的`fiber`创建之前，代表`新fiber`的`reactElement对象`需要和`旧fiber`进行对比。 如果可以复用，这时候就不用创建了。反之不能复用，就根据`reactElement对象`的描述，去创建一个新的fiber

所以应该不用改哈？

这里确切来讲是异常判断, `completeUnitOfWork`正常来讲就是深度优先遍历的回溯阶段会调用. 特殊情况就是在`beginWork`阶段发生异常, 也会调用, 这时候`completeWork.flags中会包含Incomplete`. 所以这里有个if判断, 不同情况下的处理不一样. 可以对照一下源码中的英文注释 https://github.com/facebook/react/blob/v17.0.2/packages/react-reconciler/src/ReactFiberWorkLoop.old.js#L1682

异常就是指出现了代码运行时错误, 会设置`completeWork.flags |= Incomplete`