Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Should I use mixins or an utility class?

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?

like image 746
Fernando Paz Avatar asked Aug 27 '19 15:08

Fernando Paz


People also ask

Should you use Mixins in Vue?

js Anymore. Mixins were the go-to way of sharing reusable logic between components in Vue 2. But now with the availability of the Composition API, we can achieve code reusability in a much cleaner way.

What is the benefit of using Mixins in Vuejs?

Mixins are a flexible way to distribute reusable functionalities for Vue components. A mixin object can contain any component options. When a component uses a mixin, all options in the mixin will be “mixed” into the component's own options.

Why do we use Mixins?

Mixins encourage code reuse and can be used to avoid the inheritance ambiguity that multiple inheritance can cause (the "diamond problem"), or to work around lack of support for multiple inheritance in a language. A mixin can also be viewed as an interface with implemented methods.

Can a mixin use another mixin?

A mixin can pass arguments to its content block the same way it would pass arguments to another mixin by writing @content(<arguments...>) . The user writing the content block can accept arguments by writing @include <name> using (<arguments...>) .


2 Answers

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.

like image 105
David Weldon Avatar answered Sep 21 '22 10:09

David Weldon


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.

like image 32
fixmycode Avatar answered Sep 21 '22 10:09

fixmycode