Vue3-compositionAPI大多数前端VUE开发者都会有一个疑问，为什么要使用CompositionAPI。什么时候用，怎么用，能给我们带来什么好处。本教程解决了上述思路。要解决这个问题，我们首先要了解VUE2的不足之处。也可以说，VUE2的以下局限性导致了组合API的产生：基于Vue2的大型组件难以维护。基于Vue2封装的组件逻辑很难复用。Vue2对TypeScript的支持有限。下面我们着重讨论前两个问题。只要我们把前两个问题讨论清楚，我们就会明白组合API解决了什么问题。基于Vue2选项API封装的大型组件难以维护。为了说明这个问题，我们以一个搜索组件为例，它主要完成搜索网站商品的功能。为了更形象地说明问题，我们采用所需功能逐渐增加的方法来描述。该组件使用标准的Vue2语法封装，如下图所示。当产品经理让我们再增加一个查询结果排序的功能时，我们的逻辑可能会变成这样：从上面两个简单的功能来看，代码还算不错，但是当我们在这个组件中继续增加功能需求时，比如添加搜索过滤和分页结果。我们相同的逻辑代码会被解包在不同的选项（components,props,data,computed,methods,andlifecyclemethods）中，导致我们的逻辑关注点分散，导致难以很好的理解组件，降低可读性.如果我们用颜色标记相同的逻辑（如下图红色标记），我们可以清楚地看到代码是多么分散，并且很难理解哪些代码与哪些功能逻辑相关。正如我们想象的那样（上图绿色部分），如果我们可以将相同的逻辑代码放在一起，那么我们的代码将更具可读性，从而更易于维护。那么如果这个例子使用compositionAPI来组合代码，就会是这样的：如上图所示，我们需要使用Vue3的compositionAPI。setup()中的代码是一种新方法，我将在本教程后面介绍。值得注意的是，这种新方法是完全可选的，编写Vue组件的可选接口方法仍然完全有效。一些开发者第一次看到这个setup的时候可能会想“我们会不会把所有的逻辑代码都写在setup方法中，这样代码逻辑会不会变得更难理解和阅读”。这个问题就像vue3刚开源的时候很多抱怨一样。抱怨的根源是他们中的大多数人说他们不了解设置的本质。当我们真正按照官方要求将复用逻辑封装到组合函数中，然后在setup中引用时，就不会出现上面的问题，如下整理代码。既然我们已经看到了ComponentsAPI如何让大型组件更易读和可维护，那么我们来谈谈Vue2的第二个限制，基于Vue2optionAPI封装的组件逻辑很难复用。当谈到跨组件重用代码时，在Vue2中有3个很好的解决方案来实现这一点，但每个都有其局限性。让我们通过我们的示例来逐一介绍。我们先来看看mixins。如下图所示，使用mixins的好处有：mixins可以按照逻辑关注点来组织代码。使用mixin的缺点也很明显：它们容易发生冲突，最终可能导致属性名称冲突。目前还不清楚mixin元素是如何工作的。混合组件属性不方便在其他组件中重用。对于最后一项，让我们看看Mixin工厂，返回自定义Mixins的函数。从上图可以看出，混合工厂允许我们通过配置命名空间来自定义混合，使其可以在多个组件中使用。这种方法的优点是我们现在可以通过定义名称空间轻松实现重用。多路复用方法之间的关系更加明确。但同时它也有以下缺点：命名空间需要严格规范，保证不冲突。仍然无法避免隐式属性，这意味着我们必须查看mixin内部以找出它公开了哪些属性。运行时没有对应的实例可访问，所以无法动态生成Mixin工厂。幸运的是，还有另一种解决方案，就是我们常用的作用域插槽：使用插槽有以下优点：它解决了Mixins几乎所有的缺点。但也有一个缺点：您的配置最终在模板中，理想情况下应该只包含我们想要呈现的内容。它们增加了模板的缩进，从而降低了可读性。公开的属性仅在模板中可用。由于我们使用3个组件而不是1个，因此性能会降低。正如我们所见，每个解决方案都有局限性。Vue3的组合API为我们提供了第四种组织代码重用的解决方案，如下图所示：现在，我们将使用组合API内部的函数来创建组件，这些组件将在我们的setup()方法中导入并使用。组合API的优点：由于是基于函数的，比上面的方案写的代码少，更容易将组件中的功能部分提取成函数。由于您已经熟悉函数编写，因此它建立在您现有技能的基础上，并且更容易上手。它比Mixins和Scoped槽更灵活，因为它们只是函数。对代码编辑器更加友好，结合强类型，可以实现智能提示，编写代码的体验大大提升。事情并不完美，也有缺点：需要学习新的低级API来定义组合API。现在有两种编写组件的方法，而不仅仅是标准语法。上面解释了为什么应该使用组合API。接下来引用官方文章做一个总结：1.更好的逻辑复用和代码组织我们都喜欢Vue，因为它简单易学。它使构建中小型应用程序变得轻而易举。简单的。但是随着Vue的影响力越来越大，很多用户也开始使用Vue来构建更大的项目。这些项目通常由多个开发人员组成的团队长期迭代和维护。多年来，我们目睹了其中一些项目遇到了Vue当前API强加的编程模型的限制。这些问题可以分为两类：随着功能的增长，复杂组件的代码变得越来越难以阅读和理解。当开发人员阅读他人编写的代码时，这种情况尤为常见。根本原因是Vue现有的API迫使我们通过选项来组织代码，但有时通过逻辑关系来组织代码更有意义。目前缺乏一种干净且低成本的机制来跨多个组件提取和重用逻辑。CompositionAPI在组织组件代码方面提供了更大的灵活性。现在我们可以将代码组织到处理特定功能的函数中，而不是总是按选项组织代码。这些API还可以更轻松地提取和重用组件之间甚至组件外部的逻辑。2.越来越好的类型推导大型项目开发者的另一个普遍要求是更好的TypeScript支持。Vue目前的API在集成TypeScript时遇到了很多麻烦。主要原因是Vue依赖于一个简单的this上下文来暴露属性。我们现在使用它的方式更加微妙。（例如，methods选项下函数的this指向组件实例，而不是methods对象）。换句话说，Vue现有的API在设计时并未考虑类型推断，这使得对TypeScript的适配变得复杂。目前，大多数使用TypeScript的Vue开发人员都是通过vue-class-component库将组件编写为TypeScript类（带有装饰器）。我们在设计3.0的时候，有一个废弃的提案，希望提供一个内置的ClassAPI来更好的解决类型问题。然而，在讨论和迭代其具体设计时，我们注意到，如果要通过ClassAPI解决类型问题，就必须依赖装饰器——一个非常不稳定的stage2提案，在实现细节上有很多未知数。基于它是极其危险的。CompositionAPI编写的代码将完美享受类型推导，不需要做太多额外的类型注解。这也意味着你写的JavaScript代码几乎就是TypeScript代码。即使是非TypeScript开发人员也会受益于更好的IDE类型支持。
