Using Mixins in Vue.js

Avatar of Sarah Drasner
Sarah Drasner on (Updated on )

It’s a common situation: you have two components that are pretty similar, they share the same basic functionality, but there’s enough that’s different about each of them that you come to a crossroads: do I split this component into two different components? Or do I keep one component, but create enough variance with props that I can alter each one?

Neither of these solutions is perfect: if you split it into two components, you run the risk of having to update it in two places if the functionality ever changes, defeating DRY premises. On the other hand, too many props can get really messy very quickly, and force the maintainer, even if it’s yourself, to understand a lot of context in order to use it, which can slow you down.

Enter mixins. Mixins in Vue are useful for writing in a functional style because ultimately, functional programming is about making code understandable by reducing moving parts. (There’s a great quote by Michael Feathers about this). A mixin allows you to encapsulate one piece of functionality so that you can use it in different components throughout the application. If written correctly, they are pure- they don’t modify or change things outside of the function’s scope, so you will reliably always receive the same value with the same inputs on multiple executions. This can be really powerful.

Basic example

Let’s say we have a couple of different components whose job it is to toggle a state boolean, a modal and a tooltip. These tooltips and modals don’t have a lot in common except for that functionality: they don’t look the same, they’re not used the same, but the logic is similar.

//modal
const Modal = {
  template: '#modal',
  data() {
    return {
      isShowing: false
    }
  },
  methods: {
    toggleShow() {
      this.isShowing = !this.isShowing;
    }
  },
  components: {
    appChild: Child
  }
}

//tooltip
const Tooltip = {
  template: '#tooltip',
  data() {
    return {
      isShowing: false
    }
  },
  methods: {
    toggleShow() {
      this.isShowing = !this.isShowing;
    }
  },
  components: {
    appChild: Child
  }
}

We could extract the logic here and create something that can be reused:

const toggle = {
  data() {
    return {
      isShowing: false
    }
  },
  methods: {
    toggleShow() {
      this.isShowing = !this.isShowing;
    }
  }
}

const Modal = {
  template: '#modal',
  mixins: [toggle],
  components: {
    appChild: Child
  }
};

const Tooltip = {
  template: '#tooltip',
  mixins: [toggle],
  components: {
    appChild: Child
  }
};

See the Pen Mixin by Sarah Drasner (@sdras) on CodePen.

This example was intentionally kept small and simple for purposes of legibility- examples of mixins I’ve found useful in real life applications are included but not limited to: getting dimensions of the viewport and component, gathering specific mousemove events, and base elements of charts. Paul Pflugradt has a nice repo of Vue Mixins, but it’s worth mentioning that they’re written in coffeescript.

Usage

This Pen doesn’t really show how we would set this up in a real application, so let’s look at that next.

You can set up your directory structure any way that you like, but I like to create a mixin directory in order to stay organized. The file we’d create would have a .js extension (as opposed to .vue, like our other files), and we’d export an object for the mixin:

directory structure shows mixins in a folder in components directory

And then in Modal.vue we would now have access to it by importing the toggle like this:

import Child from './Child'
import { toggle } from './mixins/toggle'

export default {
  name: 'modal',
  mixins: [toggle],
  components: {
    appChild: Child
  }
}

It’s important to understand that even though we’re using an object and not a component, lifecycle methods are still available to us. We could hook into mounted() here and it would be applied to the component’s lifecycle, which makes this way of working really flexible and powerful.

Merging

Looking at the last example, we can see that not only do we have our functionality, but also lifecycle hooks available to us from the mixin, so when applying it to a component with overlapping processes, ordering matters. By default, mixins will be applied first, and the component will be applied second so that we can override it as necessary. The component has the last say. This only really becomes important when there is a conflict and the component has to “decide” which one wins out, otherwise everything will be placed in an array to execute and the mixin will be pushed first, the component second.

//mixin
const hi = {
  mounted() {
    console.log('hello from mixin!')
  }
}

//vue instance or component
new Vue({
  el: '#app',
  mixins: [hi],
  mounted() {
    console.log('hello from Vue instance!')
  }
});

//Output in console
> hello from mixin!
> hello from Vue instance!

If the two conflict, we can see how the Vue instance or component will win:

//mixin
const hi = {
  methods: {
    sayHello: function() {
      console.log('hello from mixin!')
    }
  },
  mounted() {
    this.sayHello()
  }
}

//vue instance or component
new Vue({
  el: '#app',
  mixins: [hi],
  methods: {
    sayHello: function() {
      console.log('hello from Vue instance!')
    }
  },
  mounted() {
    this.sayHello()
  }
})

// Output in console
> hello from Vue instance!
> hello from Vue instance!

You may notice that we have two console.logs for the Vue instance string instead of one here- that’s because the first function that was called wasn’t destroyed, it was overridden. We’re still calling both of the sayHello() functions here.

Global Mixins

When we use the term global in reference to mixins, we are not referring to being able to access them on every component, like we are with something like filters. We can already access our mixins in a component with mixins: [toggle].

Global mixins are literally applied to every single component. For this reason, the use case for them is extremely limited and they should be considered with great caution. One use I can think of that makes sense is something like a plugin, where you may need to gain access to everything. But again, even in this instance, I would be wary about what you’re applying, especially when you’re extending functionality to applications that might be a black box for you.

To create a global instance, we would place it above the Vue instance. In a typical Vue-cli build, this would go in your main.js file.

Vue.mixin({
  mounted() {
    console.log('hello from mixin!')
  }
})

new Vue({
  ...
})

Again, use this with caution! That console.log would now appear in every single component. This isn’t so bad in this case (aside from all the noise in the console) but you can see how potentially harmful that could be if used incorrectly.

Conclusion

Mixins can be useful to encapsulate a small piece of functionality that you’d like to reuse. They are certainly not the only option available to you: higher order components, for example, allow you to compose similar functionality, this is just one way of working. I like mixins because we’re not having to pass state around, but this pattern can certainly be abused as well, so take care to think through which option makes the most sense for your application.