原文地址：vue-composition-api-rfc.netlify.app/#summary
摘要
介绍Composition API：基于函数的APIs，允许我们灵活组合组件逻辑。
基础例子：
动机
逻辑重用 & 代码组织
我们都喜爱Vue，因为它简单易学，并使构建中小型应用变得简单。但是随着Vue使用者的增加，许多开发者同样使用Vue构建大型项目 - 需要多个开发者的团队开发，经过反复斟酌并需要维护很长时间的项目。多年来，我们看到某些项目遇到了当前Vue的API带来开发限制。这些问题可以总结为以下2类：
1.随着需求的增加，复杂组件的代码变的难以阅读。特别是在阅读别人写的代码时。根本原因在于当前的Vue API强制代码以options的方式来组织，但是在某些情况下，按照逻辑组织代码更有意义。
2.在多个组件中，缺少一种干净的、无代价的抽象和重用逻辑的机制。
这个文档中提议的APIs可以让开发者在组织组件代码时更加灵活。不再强制使用options来组织代码，现在可以通过函数来组织代码，每一个函数仅实现特定的特性。这些APIs同样可以使多组件之间的抽象和重用逻辑变得更简单，甚至组件之外的抽象和重用逻辑。我们将在【细节设计】这个部分展示这些目标是怎么实现的。
更好的类型推断
大型项目开发者的另一个普遍要求是更好的TypeScript支持。Vue当前的API对TypeScript的支持不是很友好，主要原因是Vue依赖单个的this上下文来暴露属性，同时相比于原生Javascript，this在Vue组件中的使用有一点奇怪（在methods中定义的函数，其this指向的是组件实例，而不是methods对象本身）。另外， Vue当前的API在设计之初就没有考虑类型推断，从而造成想要在Vue中友好的使用TypeScript需要添加一些其他复杂的配置。
大部分在Vue中使用TypeScript的开发者在使用vue-class-component这个库，这个库可以使组件识别为TypeScript类（通过使用装饰器来实现）。在3.0版本的设计中，我们尝试提供内建类API用来更好的支持类型问题，在之前的RFC里有提到。然而，经过我们的讨论和反复设计，我们注意到为了解决类型问题而引入内建类API，就必须依赖装饰器，但是这是一个不稳定的特性，关于它的实现细节有很多不确定的因素。这导致依次为基础的上层开发比较危险。
相比之下，当前文档中提议的APIs大部分使用天然类型友好的纯变量和函数。使用这些APIs编写的代码可以尽情享受类型推断，仅仅需要少量的人工类型提示。同时这些代码在TypeScript和原生JavaScript中看起来几乎一样，因此即使是非TypeScript的开发者也可能受益于这些类型，从而获得更好的IDE支持。
