I have a Vue.js project that use one method in multiple files, so I create an utility class to write this method there, something like:

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

But I know that I can do it using mixins, like:

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

Should I use mixin or an utility class?

When should I use one of them?

I have a Vue.js project that use one method in multiple files, so I create an utility class to write this method there, something like:

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

But I know that I can do it using mixins, like:

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

Should I use mixin or an utility class?

When should I use one of them?

• javascript
• vue.js
• vue-component
• es6-class

• Depends on how doSomething is used. – Estus Flask Commented Aug 27, 2019 at 15:19

3 Answers 3

This is a great question. Unfortunately, there is no precise answer but I'll provide some guidelines based on my own experience working with a large Vue codebase.

Mixins

Mixins are ideal for situations where you have a collection of interdependent non-side-effect-free code that you'd like to share between components.

In my case, I have an input mixin that defines props, some data (unique ids for input and error elements), and methods for emitting events like blur. It's ~60 lines of code, that I'd otherwise have to retype for each of nine different components.

The benefits of a mixin are similar to that of an inherited class in traditional OOP. I.e. code reuse and complexity encapsulation.

The primary disadvantage of a mixin, is that it can make your code harder to read. Imagine you come back to work on the AppTextArea component six months later, and it isn't obvious how and why certain things work or where they are defined... then you remember it uses a mixin, and then you have to dive into the mixin code... In other words it makes for implicit, rather than explicit implementations.

Shared Functions

Shared functions are ideal for situations where you can reuse units of side-effect-free code in your application.

In my case, I have a date library with a formatBySlash function which takes a Date object and returns something like "5/12/2018". I've added it as a global filter, so I can do things like {{ post.createdAt | formatBySlash }} in my templates. Additionally I can import the function and use it directly in a method or computed property.

Shared functions are flexible, easy to test, and make your code more explicit.

In summary, I'd generally recommend writing a shared function unless your use case really requires that it be a mixin.

If doSomething has a dependency on the component (it uses certain data property, or it relies on this.$el, etc...), you should think on writing it as a mixin.

Otherwise, if it can be used in another context besides a Vue component, use an utility class or function. If it's just one method you don't need to create a class. You can also export functions.

During my search for the solution, I discovered that it would be beneficial to split the code for translated Enums of the dropdown list in order to share them across various views and components. To achieve this, I created a service with a dependency on the 'Vue I18n' library, which allows me to utilize the translation function this.$t. However, I encountered an issue with reusing this library within the service. As a workaround, I attempted to create an Enum.mixin.js file, which successfully resolved the dependencies without requiring further code refactoring.