betasu / big-react Goto Github PK

请可以运行这个例子，https://codesandbox.io/s/relaxed-ace-m9x292?file=/App.js 点击后组件的destory执行顺序为
。

而在本项目中执行顺序与官方实现不一致，下图为本项目中的打印顺序为

官方实现在没有标记的ChildDeletion的组件会先执行 commitPassiveUnmountEffects_complete()， 从而执行destory方法。并不是像我们实现的直接先执行所有要删除组件的destory。

如果更新一个高优先级的任务，那么会触发update,执行ensureRootIsScheduled，在里面已经加入了performConcurrentWorkOnRoot。
然后在图中也就是上一次的performConcurrentWorkOnRoot又执行了一次ensureRootIsScheduled。那么performConcurrentWorkOnRoot是不是被重复添加了两次？

如题，reconciler模块架构思路应该介绍下，要不然懂的人懒得看，不懂的人一头雾水，比如我

当前项目应该是17版本之前的实现方式
17版本之后是 合成事件捕获 =》 原生事件捕获 =〉 原生事件冒泡 =》 合成事件冒泡。

https://github.com/BetaSu/big-react/blob/master/packages/react-reconciler/src/updateQueue.ts
大佬这个文件中processUpdateQueue目前计算时， basicStateReducer(baseState, action) 感觉地方不应该用baseState而是我们计算出的新的newState

如题，是不是应该先介绍下整体架构和思路，让大家有个了解

Hey, stumbled upon this repo.
This looks fantastic, as I went through the website a bit with a translator.
I think, lots of people would benefit from learning all of these concepts.
Is there English version planned for this?
Went through some of the forks -- could not find one.

不然每次更新都是整个应用的重新渲染有些不合理呀，想知道下react到底什么情况下可以跳过render，感谢大佬！！！

function updateState(): [State, Dispatch] {
// ...
let baseQueue = current.baseQueue;
// ...
}
let baseQueue = current.baseQueue;
应该改成
let baseQueue =hook.baseQueue;

https://github.com/qdleader/qdleader

https://github.com/BetaSu/big-react/blob/master/packages/react-reconciler/src/updateQueue.ts文件下，测试的组件就为批处理那节所写的组件，num初始值为100，click事件里有三个setNum，传入一个函数，返回num+1。在我测试的时候结果是101，按理来说是103，查看了一下processUpdateQueue，发现每次传进来的baseState都为100，应该在每次处理完update后将newState赋值给baseState，供下一个update的使用，这样结果就是103。请大佬指点一下，是我理解错了还是应该是这样的。