我应该使用 mixins 还是实用程序类?

问题描述 投票:0回答:3

我有一个 Vue.js 项目,在多个文件中使用一种方法,因此我创建一个实用程序类来在那里编写此方法,例如:

export class Util{
  doSomething(){
    return 'something'
  }
}

但我知道我可以使用 mixins 来做到这一点,例如:

export const myMixin = {
   methods: {
     doSomething(){
       return 'something'
     }
   }
}

我应该使用 mixin 还是实用程序类?

我什么时候应该使用其中之一?

javascript vue.js vue-component es6-class
3个回答
12
投票

这是一个很好的问题。不幸的是,没有准确的答案,但我将根据我自己使用大型 Vue 代码库的经验提供一些指南。

混合

Mixin 非常适合您拥有一组相互依赖的非无副作用代码并希望在组件之间共享的情况。

就我而言,我有一个

input
mixin,它定义了
props
、一些
data
(输入和错误元素的唯一 ID)以及用于发出
blur
等事件的方法。这大约有 60 行代码,否则我必须为九个不同的组件中的每一个组件重新输入。

mixin 的好处与传统 OOP 中继承类的好处类似。 IE。代码重用和复杂性封装。

mixin 的主要缺点是它会让你的代码更难阅读。想象一下,六个月后你回来处理

AppTextArea
组件,并且某些东西如何工作、为什么工作或者它们的定义位置并不明显......然后你记得它使用了 mixin,然后你必须深入研究进入 mixin 代码...换句话说,它是隐式的,而不是显式的实现。

共享功能

共享函数非常适合您可以在应用程序中重用无副作用代码单元的情况。

就我而言,我有一个带有

date
函数的
formatBySlash
库,它接受
Date
对象并返回类似
"5/12/2018"
的内容。我已将其添加为全局过滤器,因此我可以在模板中执行诸如
{{ post.createdAt | formatBySlash }}
之类的操作。此外,我可以导入该函数并直接在方法或计算属性中使用它。

共享函数灵活,易于测试,并使您的代码更加明确。


总之,我通常建议编写一个共享函数,除非您的用例确实需要它是一个 mixin。


5
投票

如果

doSomething
对组件有依赖(它使用某些数据属性,或者依赖于
this.$el
等),你应该考虑将其编写为 mixin。

否则,如果它可以在 Vue 组件之外的其他上下文中使用,请使用实用程序类或函数。如果它只是一种方法,则不需要创建类。您还可以导出函数。


0
投票

在寻找解决方案的过程中,我发现分割下拉列表的翻译枚举的代码以便在各种视图和组件之间共享它们是有益的。为了实现这一目标,我创建了一个依赖于“Vue I18n”库的服务,它允许我利用翻译函数 this.$t。但是,我在服务中重用该库时遇到了问题。作为解决方法,我尝试创建一个 Enum.mixin.js 文件,该文件成功解决了依赖关系,而无需进一步进行代码重构。

© www.soinside.com 2019 - 2024. All rights reserved.