How the Vue Composition API Replaces Vue Mixins

How the Vue Composition API Replaces Vue Mixins css-tricks.com3 months ago in #Dev Love43

Looking to share code between your Vue components? If you’re familiar with Vue 2, you’ve probably used a mixin for this purpose. But the new Composition API, which is available now as a plugin for Vue 2 and an upcoming feature of Vue 3, provides a much better solution. In this article, we’ll take a look at the drawbacks of mixins and see how the Composition API overcomes them and allows Vue applications to be far more scalable. Mixins in a nutshell Let’s quickly review the mixins pattern as it’s important to have it top-of-mind for what we’ll cover in the next sections. Normally, a Vue component is defined by a JavaScript object with various properties representing the functionality we need — things like data, methods, computed, and so on. // MyComponent.js export default {   data: () =({     myDataProperty: null   }),   methods: {     myMethod () { … }   }   // … } When we want to share the same properties between components, we can extract the common properties into a separate module: // MyMixin.js export default {   data: () =({     mySharedDataProperty: null   }),   methods: {     mySharedMethod () { … }   } } Now we can add this mixin to any consuming component by assigning it to the mixin config property. At runtime, Vue will merge the properties of the component with any added mixins. // ConsumingComponent.js import MyMixin from “./MyMixin.js”; 
 export default {   mixins: [MyMixin],   data: () =({     myLocalDataProperty: null   }),   methods: {     myLocalMethod () { … }   } } For this specific example, the component definition used at runtime would look like this: export default {   data: () =({     mySharedDataProperty: null     myLocalDataProperty: null   }),   methods: {     mySharedMethod () { … },     myLocalMethod () { … }   } } Mixins are considered “harmful” Back in mid-2016, Dan Abramov wrote “Mixins Considered Harmful” in which he argues that using mixins for reusing logic in React components is an anti-pattern, advocating instead to move away from them. The same drawbacks he mentions about React mixins are, unfortunately, applicable to Vue as well. Let’s get familiar with these drawbacks before we take a look at how the Composition API overcomes them. Naming collisions We saw how the mixin pattern merges two objects at runtime. What happens if they both share a property with the same name? const mixin = {   data: () =({     myProp: null   }) } 
 export default {   mixins: [mixin],   data: () =({     // same name!     myProp: null   }) } This is where the merge strategy comes into play. This is the set of rules to determine what happens when a component contains multiple options with the same name. The default (but optionally configurable) merge strategy for Vue components dictates that local options will override mixin options. There are exceptions though. For example, if we have multiple lifecycle hooks of the same type, these will be added to an array of hooks and all will be called sequentially. Even though we shouldn’t run into any actual errors, it becomes increasingly difficult to write code when juggling named properties across multiple components and mixins. It’s especially difficult once third-party mixins are added as npm packages with their own named properties that might cause conflicts. Implicit dependencies There is no hierarchical relationship between a mixin and a component that consumes it. This…

Like to keep reading?

This article first appeared on If you'd like to keep reading, follow the white rabbit.

View Full Article

Leave a Reply