现在每次我谈论构图时

ruhul11

这纯粹是附加的，朋友们。这只是一个很好的功能。你可以使用它，你不能使用它，你没有义务。只是……它存在。

德鲁：如果 Composition API 是一个可以帮助他们摆脱问题的新事物，那么有人可能会遇到什么样的问题？它解决什么问题？

娜塔莉亚：想象一下内部有一些功能的组件。假设它是搜索和排序。假设我们搜索某个列表并尝试对其进行排序。这已经是两个不同的功能，Vue 组件的特点是，它们是根据选项而不是逻辑进行拆分的。想象一下您的搜索可能有一个查询，因为您需要进行查询来搜索和结果数组。这是两个反应性属性。就您的组件而言，您将它们放入称为数据的选项中。显然你需要一些方法来执行排序。也许是单击按钮，也许是其他东西，运行搜索的东西。您创建该方法。对于排序，您需要在排序选项上构建一些东西，这是另一个反应性属性。然后执行一些计算来对结果进行排序。

娜塔莉亚：在 Vue 中，为此，您还可以使用计算属性，这是另一种 B2C 电子邮件列表 选择。最后，你的组件变得非常支离破碎。想象一下我是一名开发人员，我的任务只负责搜索部分。我现在无法拆分该组件，因为这两个功能在某种程度上是交叉的。我搜索一些结果并对它们进行排序。我需要从数据跳转到方法，从方法跳转到计算，最后很难切换上下文。特别是当组件变得非常大时。

娜塔莉亚：Vue 2.0 中有哪些选项？第一个选项称为 mixins，mixin 只是一个对象，它可以包含组件可以具有的相同属性，我们将它们与组件混合在一起。听起来不错，我可以将所有搜索移到那里，有什么问题吗？有几个。首先，这完全不灵活。如果我想搜索某个端点并将其移动到 mixin，这将是我可以搜索的唯一端点。Mixin 不接受参数。我创建了一个mixin，它是完全静态的。第二个问题是混合了 mixin，这意味着对于某些属性来说，它就像合并一样发生。例如，如果您创建了挂钩，它将被合并。mixin 组件的生命周期钩子中的所有逻辑都合并在一起。但如果你有一个数据属性，mixin 中的冷查询，如果您在组件中也有相同的查询，则组件具有优先级。它将被覆盖。您不会收到任何警告。绝对地。它就会发生，而你不会知道它发生了。

德鲁：所有范围完全混合？

娜塔莉亚：是的，完全如此。你不可能看到，而且 mixin 的来源也很不清楚。您只需导入带有名称的 mixin 并将其放入查看组件属性 mixin 即可。这是非常含蓄的，我是从我自己的经历来看的。我们在 GitLab 中有一个逻辑，其中一个组件包含两个 mixin，并且这两个 mixin 中的每一个都包含另一个 mixin。就这样，这是您需要检查的属性，但它不在组件中。让我们更深入地了解第一级 mixin。这个不包含它，这个也不包含它。在哪儿？你潜入很深的地方，只是为了找到这个属性，而测试也变成了一场噩梦。

娜塔莉亚：让我说，Mixin 是一种非常愚蠢的提取逻辑的方法。很简单，很清楚，很容易得到。如果你想在高级水平上使用它，它会给你带来很多问题。Vue 2.0 中抽象逻辑的下一个方法是无渲染组件。在 Vue 中，组件可以包含插槽。基本上是一个可以放置父组件中任何内容的部分。一个小窗口，实际上是一个槽。还有一个作用域插槽的想法。想象一下，可以将自己的范围公开给父级的子组件，并且槽内容将可以访问它。想象一下，我有一个带有插槽的组件，并且组件执行有关搜索的所有逻辑，假设搜索的终点是过去的参数。我们的子组件，例如搜索，然后将其范围的这一部分暴露给父组件。这些是搜索结果。享受。听起来不错。听起来绝对比 mixins 好。我们可以测试参数。这里的逻辑很明确，我们正在返回一些东西。问题？有几个。