Some suggestions on Vue code readability

Preface:

I recently got into a Vue project and felt like I had fallen into a mountain of ancestral shit. The readability is extremely poor, not to mention the maintainability. Therefore, I would like to use this column to make some suggestions on the readability of Vue code. If you think the suggestions are useful, please like them. If you think the suggestions are unreasonable, please comment and criticize them. If you have better suggestions, please comment and add them.

1. Make good use of components to make the code more organized

Never put all the implementation code of a page in a .vue file. Unless the page is very simple, the code in this .vue file will be long and smelly.

The purpose of Vue providing components is not only for reuse, but also can be used to split code, and even make good use of components to optimize the rendering and updating speed of the page. This is because when the Vue page rendering is updated, the components in the page will not be updated unless the data referenced by the component's props or slot changes.

You can follow the steps below to split a Vue page into components to make the code more organized.

1. Extract UI components

How to define UI components? I personally recommend distinguishing UI components from business components based on whether they process server-side data. For example, loading pop-up windows, secondary confirmation pop-up windows, message prompt boxes, etc. are UI interaction components.

After extracting the UI components, the UI interaction code and the business interaction code can be separated. Remember not to write business code in UI components, otherwise the UI components will not be reusable.

To give a counterexample, adding the business code to be processed after the second confirmation in the second confirmation pop-up window will make the UI component unable to be reused. We can imitate the call of the secondary confirmation pop-up window in ElementUI to implement a secondary confirmation pop-up window component.

this.$confirm(message, title, options)
  .then(res =>{})
  .catch(err =>{})

In this way, the business code can be written in the callback function of then. The core implementation code of the component is as follows:

//confirm.vue
<template>
  <div v-show="show">
    //...
    <div @click="ok"></div>
    <div @click="cancel"></div>
  </div>
</template>
<script>
export default {
  data() {
    return {
      show: false,
    }
  },
  methods: {
    ok() {
      this.show = false;
      this.resolve();
    },
    cancel() {
      this.show = false;
      this.resolve();
    },
  }
}
</script>

//index.js
import Vue from 'vue';
import options from './confirm.vue';
const Confirm = Vue.extend(options);
let confirm = undefined;
const ConfirmInit = (options = {}) => {
  return new Promise((resolve, reject) => {
    options.resolve = resolve;
    options.reject = reject;
    confirm = new Confirm({
      el: document.createElement('div'),
      data: options
    })
    document.body.appendChild(confirm.$el);
    Vue.nextTick(() => {
      if (confirm) confirm.show = true;
    })
    return confirm;
  })
}
Vue.prototype.$confirm = ConfirmInit;

//main.js
import 'components/confirm/index.js'; //Global registration of secondary confirmation pop-up confirm component

2. Extract business components by module

A page can be divided into multiple areas, such as header, footer, sidebar, product list, member list, etc. Each area can be used as a module to extract business components.

3. Extract functional components by function

After extracting business components by module, the business components may still be very large, so it is necessary to further extract functional components by function.

Functions vary in size, and there are several principles to be aware of when extracting them:

Overly simple functions are not extracted:

For example, a collection function can be completed by requesting an interface. Functions like this should not be extracted. Only functions with logical operations of a certain complexity can be extracted.

The function should be single:

A functional component handles only one business.

For example, a file reader component has a requirement to automatically collect the file after opening it. So where should the collection logic code be written?

Perhaps you wrote the collection logic code in the method that listens for successful file opening in the component without thinking. After a while, the requirement changed to adding it to the reading record before clicking the collection button. When you went to modify the code in the component, you found that another page also referenced this component, so you had to add an extra parameter to the component to distinguish the business scenarios. As the requirements changed, the business scenarios were superimposed, and various judgment logics were added to the component code, which became long and boring over time. Obviously, this approach is not acceptable.

The correct approach is to customize an event on-fileOpen-success on the component tag and use the handleFileOpenSuccess function to listen to this event.

<fileReader 
  @on-fileOpen-success="handleFileOpenSuccess"
>
</fileReader>

In the component's method for listening for successful file opening, execute this.$emit('on-fileOpen-success',data) to trigger this event. data can pass the file information out, and the handleFileOpenSuccess function can handle business interactions such as collection or adding history records and then collecting them. This approach makes the file reader component monolithic.

Functional components should contain as little UI as possible, and the UI part should be passed in through slots, which makes the components purer and more reusable.

For example, it is impossible to add an upload icon to the upload component as the UI design draft changes. In this case, you can use the slot to pass in the upload icon.

//upload.vue
<template>
  <div>
    <slot name="icon"></slot>
  </div>
</template>

//index.vue
<template>
  <div>
    <upload>
      <template #icon>
        //Upload icon</template>
    </upload>
  </div>
</template>

2. Use v-bind to make component properties more readable

If you want to pass all properties of an object as prop to componentA , you can use v-bind without parameters. For example, for a given object params :

params: {
  id: 1,
  name: 'vue'
}

Before optimization:

<componentA :id="params.id" :name="params.name"></componentA>

After optimization:

<componentA v-bind="params"></componentA>

3. Use attrs and attrs and listeners to encapsulate third-party components

1. $attrs

When encapsulating third-party components, you often encounter a problem: how to use the properties and events of the third-party components themselves through the encapsulated components.

For example, encapsulate an Input box component myInput in an elementUi component, and display an error prompt below the input box when incorrect content is entered.

The myInput component code is as follows:

<template>
  <div>
    <el-input v-model="input"></el-input>
    <div>{{errorTip}}</div>
  </div>
</template>
<script>
export default {
  props: {
    value: {
      type: String,
      default: '',
    },
    errorTip: {
      type: String,
      default: '',
    }
  },
  data() {
    return {
    }
  },
  computed: {
    input: {
      get() {
        return this.value
      },
      set(val) {
        this.$emit('input', val)
      }
    }
  }
}
</script>

The myInput component is called like this, where errorTip is a hint of input error in the input box.

<myInput v-model="input" :errorTip="errorTip"></myInput>

If you want to add a disabled attribute to myInput component to disable the input box, how do you achieve it? Most students would do this.

<template>
  <div>
    <el-input v-model="input"
      :disabled="disabled"></el-input>
    <div>{{errorTip}}</div>
  </div>
</template>
<script>
export default {
  props: {
    //...
    disabled:
      type: Boolean,
      default: false
    }
  },
  //...
}
</script>

After a while, you need to add other attributes of el-input component to the myInput component. There are more than 27 el-input components in total. What should you do? Should you pass them in one by one with prop ? This is not only unreadable but also cumbersome. You can use $attrs to do it in one step. Let's take a look at the definition of attrs first.

$attrs: Contains attribute bindings (except class and style ) that are not recognized (and retrieved) as prop in the parent scope. When a component does not declare any prop , all parent scope bindings (except class and style ) are included here, and can be passed to the inner component via v-bind="$attrs "

v<template>
  <div>
    <el-input v-model="input"
      v-bind="$attrs"></el-input>
    <div>{{errorTip}}</div>
  </div>
</template>

This is not enough, you also have to set the inheritAttrs option to false . Why? Take a look at the definition of inheritAttrs option and you will understand.

By default, parent-scoped attribute attribute bindings that are not recognized as props will "fall back" and be applied as normal HTML attribute on the child component's root element. When writing components that wrap a target element or another component, this may not always be the expected behavior. By setting inheritAttrs to false , this default behavior will be removed. These attribute can be made effective through $attrs and can be explicitly bound to non-root elements through v-bind . Note: This option does not affect class and style bindings.

Simply put, set inheritAttrs to false and v-bind="$attrs " will take effect.

<template>
  <div>
    <el-input v-model="input"
      v-bind="$attrs"></el-input>
    <div>{{errorTip}}</div>
  </div>
</template>
<script>
export default {
  inheritAttrs: false,
  props: {
    value: {
      type: String,
      default: '',
    },
    errorTip: {
      type: String,
      default: '',
    }
  },
  data() {
    return {
    }
  },
  computed: {
    input: {
      get() {
        return this.value
      },
      set(val) {
        this.$emit('input', val)
      }
    }
  }
}
</script>

In this way, the properties of the el-input component can be clearly distinguished from the properties of the myinput component, and the readability of props option of the component is greatly improved.

2. $listeners

So how do you implement a custom event on the el-input component on the myIpput component? Your first reaction may be this.$emit。

<template>
  <div>
    <el-input v-model="input"
      v-bind="$attrs"
      @blur="blur">
    </el-input>
    <div>{{errorTip}}</div>
  </div>
</template>
<script>
export default {
  //...
  methods: {
    blur() {
      this.$emit('blur')
    }
  }
}
</script>

<myInput 
  v-model="input"
  :errorTip="errorTip"
  @blur="handleBlur">
</myInput>

el-input component has 4 custom events, which is not too many. What should we do if we encounter a third-party component with more custom events? Should we add them one by one? This will not only add a bunch of unnecessary methods , but also make them difficult to read and easily mixed with myInput own methods . In fact, you can use $listeners to achieve the goal in one step. Let's first look at the definition of $listeners .

$listeners: Contains v-on event listeners in the parent scope (without the .native modifier). It can be passed into inner components via v-on="$listeners" .

<template>
  <div>
    <el-input v-model="input"
      v-bind="$attrs"
      v-on="$listeners">
    </el-input>
    <div>{{errorTip}}</div>
  </div>
</template>
<script>
export default {
  //...
}
</script>

<myInput 
  v-model="input"
  :errorTip="errorTip"
  @blur="handleBlur">
</myInput>

In the myInput component, as long as you add v-on="$listeners " to el-input component, you can use the customized events of el-input component on the myInput component.

This concludes this article about some suggestions on Vue code readability. For more relevant Vue code readability content, please search 123WORDPRESS.COM's previous articles or continue to browse the following related articles. I hope everyone will support 123WORDPRESS.COM in the future!