思考 fre 重构 about fre HOT 9 CLOSED

但是如果是大量数据提高响应能力，那也不需要 fiber ，直接 requestIdleCallback 就可以，不用弄一个链表的遍历

我觉得你可能需要去了解一下 fiber 的来源和目的。如果只是为了拓展控制流（你说的 suspense等），那用 异常控制流可以实现（当然 return value 需要全局设置一下）。一个很直接的例子就是 vue 没有 fiber，但是不妨碍他实现 hooks，hooks 是 algebraic effects 上的抽象，fiber 就是 algebraic effects 的在 react 中的体现。

但是在大量数据下的交互相应，就必须要能够精准地往返于 work 之间，而 requestIdleCallback 只是延迟运算，不是拆分运算，只要运算很密集，那响应就不会那么及时。所以问题的关键除了需要利用 idle 片段，还必须合理拆分计算。react 的 fiber 是以 vnode 为单位做拆分的，这种拆分最终也很好地降低了单次运算时间，将运算开销分摊开。

还有个佐证就是 Dan 的 这个对比视频。

当然，我们也不能否认 fiber 对于控制流的拓展性带来的抽象提升，但是何为主何为次我保留态度了。

from fre.

react like vdom 下场景的性能瓶颈主要来源于 reconcile 和 patch(commit) 这两个过程，fiber 的 commit 也是不能打断的，所以性能无法更好优化。

而 didact 的 vdom diff 算法很有问题，比如说在做 sibling diff 的时候不会中断，会一直运行，这种 diff 算法在长列表场景极其吃亏，而有意思的是这种复杂场景按理来说应该是 fiber 的重要场景。

from fre.

fiber 本就无法提高性能，它的核心场景也不是大量数据渲染，任何时候，一股脑渲染大量数据都是不可取的

fiber 确实无法提高性能，但是大量数据渲染确实是有很多 case 的，比如说可视化。fiber 的场景应该是为复杂数据挑战下的高响应性提供支持，而「可重入性」是 fiber 这种结构的一个特点罢了。

难道没有 fiber 就无法实现 susponse？很明显不，利用异常控制流也很容易实现，fiber 的「可重入性」在异步上的作用可能并没有分段 reconcile 重要，很直接的就是，一个只是开发习惯上的改变，而另一个则是实打实的富交互性能体验上的提升。

from fre.

1. vue-hooks 的实现是错误的，它起不到 hooks 的作用

1.你所谓的 hooks 的作用是什么呢？

2.光 ric 为什么可以处理大量数据计算呢？一个计算任务需要10s，那么不论放在哪里执行，都会影响页面响应。应该做的是把任务拆分成 100 个，一个 0.1s，然后挨个执行，在执行之中如果需要响应交互，可以方便地暂停计算任务，转而响应交互。

3.我不认为 vue 的 hooks 「实现」是错误的。因为 hooks 的本质是语义正确而不是实现正确，为什么会有 「实现错误」这种说法呢？

from fre.

react like vdom 下场景的性能瓶颈主要来源于 reconcile 和 patch(commit) 这两个过程，fiber 的 commit 也是不能打断的，所以性能无法更好优化。

而 didact 的 vdom diff 算法很有问题，比如说在做 sibling diff 的时候不会中断，会一直运行，这种 diff 算法在长列表场景极其吃亏，而有意思的是这种复杂场景按理来说应该是 fiber 的重要场景。

和性能无关，commit 不应该被打断的另一种说法就是我所说的【高优先级】
fiber 本就无法提高性能，它的核心场景也不是大量数据渲染，任何时候，一股脑渲染大量数据都是不可取的

fiber 的核心场景应该是 susponse 这种暂停、恢复等异步场景

至于第二点，diff 算法，我会考虑重构，会进行 keyed

from fre.

fiber 本就无法提高性能，它的核心场景也不是大量数据渲染，任何时候，一股脑渲染大量数据都是不可取的

fiber 确实无法提高性能，但是大量数据渲染确实是有很多 case 的，比如说可视化。fiber 的场景应该是为复杂数据挑战下的高响应性提供支持，而「可重入性」是 fiber 这种结构的一个特点罢了。

难道没有 fiber 就无法实现 susponse？很明显不，利用异常控制流也很容易实现，fiber 的「可重入性」在异步上的作用可能并没有分段 reconcile 重要，很直接的就是，一个只是开发习惯上的改变，而另一个则是实打实的富交互性能体验上的提升。

我不太了解数据可视化，也不太了解异常控制流
但是如果是大量数据提高响应能力，那也不需要 fiber ，直接 requestIdleCallback 就可以，不用弄一个链表的遍历
对于场景，可能我也有认知不足

换回 fre 的话，我觉得我最多搞 keyed，其他的优化不打算搞了，主要是一方面是我能力问题，另一方面是代码尺寸，引入过多的优化很容易超 1kb
但是我觉得我可以开放接口，让对性能要求高的，用上社区内第三方的 diff 库，如 petit、inferno 等的 diff方案

from fre.

但是如果是大量数据提高响应能力，那也不需要 fiber ，直接 requestIdleCallback 就可以，不用弄一……

1. vue-hooks 的实现是错误的，它起不到 hooks 的作用，建议你自己读它的源码，但是 vue 确实有参考价值，它利用 proxy + requestIdleCallback 实现了时间切片，按照我的说法，同样可以提高大量数据的响应能力，完全不需要使用链表
2. 我不认为大量数据的响应能力，链表是个优解，传统的递归我一样可以做到

不过这一切，都不适用于 fre
fre 的 fiber，不打算趋向 react，fiber 在 fre 中扮演的角色，暂时只是替代 diff 算法，循环替代递归

如果是你所说的大量数据的情况，我建议参考 vue，使用 proxy+ric

from fre.

第一个问题和第三个问题，我就不回答了，就算抛开内部实现，你也可以自己试着去使用，试试手感再来谈，根本不是一个东东

关于第二个问题，多说无益，我这周六放假发一个小库，用来复现 vue 的时间切片，同时也解决你所说的【大量数据的响应问题】

世界切片和 fiber 无关，时间切片就是 ric ，你使用了 ric ，那它就是切片的

from fre.

已经实现了 keyed diff，fiber 架构也重构了
优先级调度还是不好搞，需要继续研究
T﹏T

from fre.