如开头提到的，time slicing 这部分内容已经在 master 分支被移除了，关于为什么废除，我特地发了 issue，可以戳这里：（天啊，我和尤终于可以和平地进行交谈了）
https://github.com/vuejs/rfcs/issues/89
简单说，就是 time slicing 的收益不大，除了 issue 中提到的，它本身的场景就少的可怜
也因为 vue 现在的实现，由于调度的基本单位是组件，所以它仍然会因为组件内部的逻辑而被阻断
比如我把用例中用于阻断的 block 函数改为 1s，就已经彻底卡死了
思考
从 issue 和源码本身，我们可以思考一些问题，同时用来凑字数
时间切片是否必须？
答案是否定的，尤的回复已经足够充分了：
大致有两点：
除了高帧率动画，其他的场景几乎都可以使用防抖和节流去提高响应性能
vue 现在的实现，粒度太大，最终的效果十分有限，不值得
那，fre 呢？
fre 的异步渲染，是否也存在这个问题，不得不承认，fre 虽然粒度很小，对于组件内部的阻断可以搞定，但是元素本身也可以被阻断
而且第一个问题也是存在的，就是没有太多适用场景
但是 fre 源码层面还是意义重大的，即便这玩意搞出来，发现它作用不大，副作用不小，但 fre 作为我个人的学习和研究的项目，它的价值从来就不是业务层面的
只是我应该停下来，异步渲染搞定了，只是向大家展示它的源码实现，未来不应该跟随 react 去搞一堆业务 API，如 useTransition 等等
关于源码？
vue3 发版当天，源码解读就放出了，但是到目前为止，所有的源码解读统统都是蹭热度的
不久的将来，vue 的源码又要烂大街了……
这种现象引起反省，我们读源码到底是为了什么？为了面试吗？为了更好的写业务？
对我而言，仅仅只是感兴趣，我对这部分源码感兴趣，我就去读，并且只读感兴趣的部分
其实大家也看到了，我很少写源码解读的文章，因为我一直反对所谓的【通读源码】
将阅读源码作为一项工作，同样的小函数，读了一遍又一遍，重复劳动
这和糊 shi 有什么区别呢？