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写的组件中，实现其中某个具体小逻辑的代码分散在组件中的多处（data, methods, props, computed等）,可读性极其低。
Composition Api: 一个function融合了data,methods,computed等，实现了一个小逻辑，在IDE中还可以折叠，看上去十分友好。
以下贴上官方的代码对比图：
Logic Reuse
上面也分析到了，composition Api将逻辑都封装在了一个function里，我们可以很容易的将function迁移到外部文件，然后在使用到的组件里import进来，达到逻辑的抽离和复用。
在vue2.0中有以下几种方式可以实现复用：
1.mixins
2.HOC
3.renderless components (via scoped slots)
但是以上方式都有各自的缺点
| pattern | 属性来源不清晰 | 命名冲突 | 性能消耗（需要创建组件实例） |
|---|---|---|---|
| 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 后，我们需要不断的去区分普通值和对象，这加大了我们的心理负担。
但是我们可以通过引用的命名（如xxxRef）来减少负担。另一方面，由于在代码组织方面提高了灵活性，组件逻辑被拆分成更小的function,使得本地上下文更简单并且引用的开销更容易管理。
2.由于获取值需要通过.value的方式，所以比起使用普通值，使用和操作refs将会变得更加冗长。
Ref vs Reactive
简单来说，ref使基本数据类型保持响应式，而reactive只能使引用类型（）保持响应式，并且解构后失去响应！！！在返回reactive objects的时候可以使用toRefs将对象上的每个属性转成相应的ref!
return语句的细粒度
1.IDE插件根据setup()中申明的变量自动生成return语句
2.Babel插件自动生成和插入return语句
更多的灵活性需要更多的约束
他们相信：
1.提高上限的收益大于降低下限的损失；
2.通过良好的文档和社区的指导，我们可以高效的解决代码组织问题；
3.0采用的策略
1.目前提供了@vue/composition库，提供给开发者体验新的api并收集反馈。
2.计划将api内置在3.0中，与2.0api共存。
3.对于想要使用新api的用户来说，提供了一个编译时标志位来移除2.0的option api 以减小库的体积。然而，这完全是可选的。
4.新api被定位为高级功能，旨在解决大型应用中的问题。我们不会用新的文档来覆盖当前的默认文档，取而代之的是，它会有一个专属的章节。
