从新开坑，在 react 中使用 composition API

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 再渲染

就是个闭包

实现

github.com/yisar/qox/b…

代码在这里，整个代码其实就是劫持了一下

缺陷

1. composition API 的缺陷

不多有人提这个，你们都在提 hooks 的缺点，可是 composition API 的缺陷也很明显，好比解构问题，闭包问题，面条代码问题

2. 源码级别的缺陷

我我的的话，实际上是不怎么关注业务级别的缺陷的，无所谓业务上的心智负担，也无所谓业务上的边界问题

在源码层面，composition API 的实现是彻底独立雨框架外的，它能提供的好处比较有限，可是任何框架均可以实现它，我不认为这会称为 vue3 的核心竞争力

当时我就说，just API，这么说的理由是正常人一看就知道这个 API 不难实现

可是使用了依赖收集，也意味着丧失了 Concurrent 的可能，毕竟依赖收集这玩意，一不能重复收集，二不能收集不完

固然，这也不算缺点了，毕竟 vue 等 react15-like 框架的递归遍历条件，自己就不适合回退行为

因此重点是，即使我如今能够简单的在 react 中实现对等的 API，它的源码级别的缺陷也是对等的，意味着也将失去 Concurrent 的可能

是的……就是这么绝望::>_<::

辩证

因此究竟是 hooks API 仍是 composition API？

究竟是心智负担仍是丧失 Concurrent？

仁者见仁吧，反正……你们辩证认识，自行选择吧！

至于 qox，我如今正在寻找一个很好的方式植入 watch，computed 等特性，有空就来更新下，哈哈

这样也算填了 smox 的坑::>_<::不要说我坑品很差了！

最后放上 github 地址，有人要接手吗？？

github.com/yisar/qox