從新開坑，在 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