Composition API RFC

Composition API RFC

Why Composition APi

Vue2.0是基于options的Api, 为甚3.0使用了Composition Api呢？
主要是出于两点考虑：
1.Code Organization
2.Logic Reuse
其他原因：

1. Plugin Development

Code Organization

Options: 在一个功能复杂的组件里，基于options写的组件中，实现其中某个具体小逻辑的代码分散在组件中的多处（data, methods, props, computed等）,可读性极其低。

Composition Api: 一个function融合了data,methods,computed等，实现了一个小逻辑，在IDE中还可以折叠，看上去十分友好。

以下贴上官方的代码对比图：

1576576863827.jpg

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的开销

1. 使用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被定位为高级功能，旨在解决大型应用中的问题。我们不会用新的文档来覆盖当前的默认文档，取而代之的是，它会有一个专属的章节。