Vue learning (9) - mixed in

foreword

The use of mixins is very simple. In fact, I originally planned to write plugins directly, but considering that the scope of use of plugins also includes mixins and custom instructions, I will first talk about the basic concepts of these two.

In my opinion, mixing in is to add some common properties and methods to components. For example, there are many pages in our project to display the pagination list, and the page components will include the current page, records per page, total number of records, total number of pages, etc. Many of them are exactly the same, or have certain reusability. If each page has such a big mess, not only will it be cumbersome to write, but it will also look messy. If it is developed by different people, the definition of the variable name is not the same, and the readability and maintainability will be poor. So we want something that can extract these common parts, and we need to use the concept of mix-in. You can refer to some open source background management systems for how to use them in the project. For example, the front end of jeecg uses mixins.

use mixins

First use vue-cli to build a project test_mixin. If you don't know how to build, refer to my first vue article "Vue Learning (1) - Component Basics" .

basic use

Now we assume that the created method of each component of our project calls console.log('create'), and each component has a hello method, and there are two properties current and pageSize.

Create a directory src/mixin, and create a new file mixinHello.js in this directory:

export const mixinHello = {
  data(){
    return{
      current: 1,
      pageSize: 10
    }
  },
  created: function () {
    console.log('create')
  },
  methods: {
    hello: function () {
      console.log('hello from mixin!')
      console.log('current:' + this.current)
      console.log('pageSize:' + this.pageSize)
    }
  }
}

The code is very simple, as we said at the beginning of this section, define the current, pageSize attributes, created method, and hello method. Then we create a custom button component myBtn in the src/components directory and add the mixin to it:

<template>
  <div>
    <button @click="hello">测试混入</button>
  </div>
</template>

<script>
import {mixinHello} from '@/mixin/mixinHello.js'

export default {
  mixins: [mixinHello]
}
</script>

Then we modify App.vue and introduce muBtn

<template>
  <div>
    <my-btn></my-btn>
  </div>
</template>

<script>
import myBtn from '@/components/myBtn'

export default {
  name: 'App',
  components: {
    myBtn
  },
}
</script>

Execute run server and visit localhost:8080, as shown in the figure:

 We click F12 to open the developer tool, refresh the page, and you can see that the create is printed out, which proves that the created method of mixinHello is called:

Then click the button to print out the content executed by the hello method.

Of course, if these methods and properties are only used on one component, there is obviously no need to use mixins. The meaning of mix-in is reuse. If many components need to use these methods and properties, it is just right to use mix-in.

option merge

Mixing in can save a lot of effort when reusing, but another problem arises. If we define methods or properties with the same name in the component, which one will be used during execution? We create a custom button component myBtnMerge.vue in the src/components directory

<template>
  <div>
    <button style="margin: 10px" @click="hello">测试混入合并</button>
  </div>
</template>

<script>
import {mixinHello} from '@/mixin/mixinHello.js'

export default {
  mixins: [mixinHello],
  data(){
    return{
      current: 2,
      pageSize: 30
    }
  },
  created: function () {
    console.log('create merge')
  },
  methods: {
    hello: function () {
      console.log('hello merge!')
      console.log('current:' + this.current)
      console.log('pageSize:' + this.pageSize)
    }
  }
}
</script>

Modify App.vue, comment out myBtn, add myBtnMerge

<template>
  <div>
    <!-- <my-btn></my-btn> -->
    <my-btn-merge></my-btn-merge>
  </div>
</template>

<script>
// import myBtn from '@/components/myBtn'
import myBtnMerge from '@/components/myBtnMerge'

export default {
  name: 'App',
  components: {
    // myBtn,
    myBtnMerge
  },
}
</script>

After running the project, refresh the web page, and click the button to see the output of F12:

Here we have three conclusions:

1. For hook functions, such as created, mounted, and destroyed, when the component-defined method and the mixed-in method have the same name, they will be merged, and the mixed-in method will be called before the component-defined method.

2. For the component-defined data object, after merging with the mix-in object, if there are conflicting attributes, the component-defined one takes precedence.

3. For methods, components, and directives, when there is a conflict between the component customization and the mixed-in internal key value, the component customization takes precedence.

This looks a bit like object-oriented inheritance. Hook functions are like constructors. Others are like member properties and member methods.

If you don't want to use the default merging strategy, you can also customize the merging strategy. For specific implementation, readers can search for the keyword "optionMergeStrategies" by themselves.

summary

The use of mixins seems to me a bit like inheritance in object-oriented. The advantage is that the same attributes and methods do not need to be repeated many times. Especially when doing projects, it is very cumbersome to write a bunch of methods for each page. Of course, the hook function should be used with caution, because even if the component customizes the hook function, it will not override the hook function mixed in.