emmm大家好，那个，虽然最近新型肺炎，搞的人心惶惶，没啥动力写码
其实我也没啥可写的了，但是闲着也是闲着，然后记起来 smox 弃坑了还有一堆星星，想着怎么重新开坑
背景
smox 弃坑，不是我任性，而是 hooks 的出现后，真的不需要 class 和状态管理了
这两者我认为不是互补的，他俩完全可以独立存在，所以我写了 fre，弃了 smox
但是社区也好，写 fre 遇到的问题也好，hooks 确实也有一些问题
问题
hooks 的问题其实总结来说就是【心智负担】
hooks 的好处是 Concurrent，Concurrent 本质是宏任务循环，除了 hooks 现在的机制，没有可以替代的方案
所以 fre 不可能舍弃现在的 API，但是！
vue-next 提出的 composition API，是一个完全独立存在的一组 API，它和 vue 本身并没有耦合性
说白了就是在任何框架，劫持一下，就可以实现这组 API
react 也不例外
使用
import { setup, reactive } from 'qox'
import { render } from 'react-dom'
const App = setup(() => {
const data = reactive({ count: 0 })
return () => (
<div>
<div>{data.count}</div>
<button onClick={() => data.count++}>+</button>
</div>
)
})
render(<App />, document.body)
我可以很轻松的在 react 中实现这组 API，使用方法就是使用 setup 包裹一个 composition 的组件，返回一个普通组件
我们看到，composition 组件返回的不是 jsx 而是一个 render function
这也解决了 hooks 的本质问题——重复渲染，组件本身只渲染一次，剩下的渲染行为都是 render function 再渲染
就是个闭包
实现
代码在这里，整个代码其实就是劫持了一下
缺陷
- composition API 的缺陷
很少有人提这个，大家都在提 hooks 的缺点，但是 composition API 的缺陷也很明显，比如解构问题，闭包问题，面条代码问题
- 源码级别的缺陷
我个人的话，其实是不怎么关注业务级别的缺陷的，无所谓业务上的心智负担，也无所谓业务上的边界问题
在源码层面，composition API 的实现是完全独立雨框架外的，它能提供的好处比较有限，但是任何框架都可以实现它，我不认为这会称为 vue3 的核心竞争力
当时我就说，just API，这么说的理由是正常人一看就知道这个 API 不难实现
但是使用了依赖收集，也意味着丧失了 Concurrent 的可能，毕竟依赖收集这玩意，一不能重复收集，二不能收集不完
当然，这也不算缺点了，毕竟 vue 等 react15-like 框架的递归遍历条件，本身就不适合回退行为
所以重点是，即便我现在可以简单的在 react 中实现对等的 API，它的源码级别的缺陷也是对等的，意味着也将失去 Concurrent 的可能
是的……就是这么绝望::>_<::
辩证
所以到底是 hooks API 还是 composition API？
到底是心智负担还是丧失 Concurrent？
仁者见仁吧，反正……大家辩证认识，自行选择吧！
至于 qox，我现在正在寻找一个很好的方式植入 watch，computed 等特性，有空就来更新下，哈哈
这样也算填了 smox 的坑::>_<::不要说我坑品不好了！
最后放上 github 地址，有人要接手吗？？
