Composition API RFC
Why Composition APi
Vue2.0是基于options的Api, 為甚3.0使用了Composition Api呢？
主要是出于兩點考慮：
1.Code Organization
2.Logic Reuse
其他原因：
- Plugin Development
Code Organization
Options: 在一個功能復雜的組件里，基于options寫的組件中笛辟，實現(xiàn)其中某個具體小邏輯的代碼分散在組件中的多處（data, methods, props, computed等）,可讀性極其低。
Composition Api: 一個function融合了data,methods,computed等捻勉，實現(xiàn)了一個小邏輯，在IDE中還可以折疊刀森，看上去十分友好。
以下貼上官方的代碼對比圖：
Logic Reuse
上面也分析到了报账，composition Api將邏輯都封裝在了一個function里研底，我們可以很容易的將function遷移到外部文件，然后在使用到的組件里import進來透罢，達到邏輯的抽離和復用榜晦。
在vue2.0中有以下幾種方式可以實現(xiàn)復用：
1.mixins
2.HOC
3.renderless components (via scoped slots)
但是以上方式都有各自的缺點
| pattern | 屬性來源不清晰 | 命名沖突 | 性能消耗（需要創(chuàng)建組件實例） |
|---|---|---|---|
| mixins | yes | yes | no |
| HOC | no | yes | yes |
| renderless components | no | no | yes |
| Composition Api | no | no | no |
Plugin Development
2.0： 插件都是通過mixin的方式注入到this實例上，由于每個插件都要求用戶增加注入屬性的Vue類型羽圃，這使得類型推斷變得棘手.
3.0: 使用composition api 后乾胶，沒有了this,取而代之的是plugins會使用provide 和inject 并且暴露出compostion function.
缺點
refs的開銷
- 使用composition api 后，我們需要不斷的去區(qū)分普通值和對象朽寞，這加大了我們的心理負擔识窿。
但是我們可以通過引用的命名（如xxxRef）來減少負擔。另一方面脑融，由于在代碼組織方面提高了靈活性喻频，組件邏輯被拆分成更小的function,使得本地上下文更簡單并且引用的開銷更容易管理。
2.由于獲取值需要通過.value的方式肘迎，所以比起使用普通值甥温，使用和操作refs將會變得更加冗長。
Ref vs Reactive
簡單來說妓布，ref使基本數(shù)據(jù)類型保持響應式姻蚓，而reactive只能使引用類型（）保持響應式，并且解構后失去響應Ｏ徽印Ｕ病！在返回reactive objects的時候可以使用toRefs將對象上的每個屬性轉成相應的ref!
return語句的細粒度
1.IDE插件根據(jù)setup()中申明的變量自動生成return語句
2.Babel插件自動生成和插入return語句
更多的靈活性需要更多的約束
他們相信：
1.提高上限的收益大于降低下限的損失；
2.通過良好的文檔和社區(qū)的指導圆兵，我們可以高效的解決代碼組織問題跺讯；
3.0采用的策略
1.目前提供了@vue/composition庫，提供給開發(fā)者體驗新的api并收集反饋殉农。
2.計劃將api內(nèi)置在3.0中刀脏，與2.0api共存。
3.對于想要使用新api的用戶來說超凳，提供了一個編譯時標志位來移除2.0的option api 以減小庫的體積愈污。然而，這完全是可選的轮傍。
4.新api被定位為高級功能暂雹，旨在解決大型應用中的問題。我們不會用新的文檔來覆蓋當前的默認文檔创夜，取而代之的是杭跪，它會有一個專屬的章節(jié)。
