【问题标题】:Should I use mixins or an utility class?我应该使用 mixins 还是实用程序类?
【发布时间】:2019-08-27 15:06:40
【问题描述】:

我有一个 Vue.js 项目,它在多个文件中使用一种方法,所以我创建了一个实用程序类来在那里编写这个方法,类似于:

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

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

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

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

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

【问题讨论】:

  • 取决于 doSomething 的使用方式。

标签: javascript vue.js vue-component es6-class


【解决方案1】:

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

混合

Mixins 非常适用于您希望在组件之间共享一组相互依赖且无副作用的代码的情况。

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

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

mixin 的主要缺点是它会使您的代码更难阅读。想象一下,六个月后你回到 AppTextArea 组件上工作,但不清楚某些事情如何以及为什么工作或它们在哪里定义......然后你记得它使用了一个 mixin,然后你必须潜水进入 mixin 代码......换句话说,它是隐式实现,而不是显式实现。

共享函数

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

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

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


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

【讨论】:

  • 我很好奇你是如何管理 Vue 中的业务逻辑的。我看到一些 mixin 类在做网络调用,我发现它很臭。我宁愿创建最小依赖简单的 es6 Class-es 并在那里封装业务逻辑(类似于 Angular 的服务方式)。你曾经在 Mixins 中管理过业务逻辑吗?您如何管理 Vue 应用程序中的业务逻辑?
  • 我建议将更复杂的非 UI 代码移动到与组件分开的文件中。就我而言,我有一个 /lib 目录,用于存储这些函数/类。如果您有需要帮助的特定用例,我建议您提出一个新问题。
【解决方案2】:

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

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

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2012-11-13
    • 2013-02-16
    • 1970-01-01
    • 2023-03-14
    • 2010-10-25
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多