I am in charge of several B-side projects. In the process of development iteration, many repetitive codes and logic make me very upset. Therefore, I have been thinking about how to improve the development efficiency and free myself from repetition. Here are some of the questions, thoughts, and solutions I have encountered that I hope will be helpful to you.

Vscode used in@No path prompt

For convenience, we often configure @ in webpack to point to the SRC directory of the project, but vscode’s path prompt does not recognize @, resulting in no prompt when writing the lead-in path.

Solution: Download the VScode plug-in Path Intellisense and configure it in the vscode setting file as follows:

The code to introduce common components is cumbersome

Common components used every time, all need to write the introduction of code: the import Material from ‘@ / components/common/Material’

Solution: Registering common components as global components saves the effort of importing components.

// Register global public components
let context = require.context('@/components/common/'.true./\.vue$/)
context.keys().map(key= > {
  const component = context(key).default
  Vue.component(component.name, component)
})
Copy the code

The require.context is used to import all public components from the public component directory

The code for using common components is cumbersome

When we use a component, its component name, parameter passing, custom events, etc. need to be typed by hand, as follows:

<Material
title="Issue Materials"
:materials.sync="material"
:annotation.sync="annotation"
:vAuth="() = > 35"
/>
Copy the code

Solution:

  1. Common components in the code, maintain a component using demo for quick replication when used. The previous workload was reduced to just copying and changing binding values. It is highly recommended to do this in a team.

Maintain documentation, sample pages for a common component

Provides the following functions:

  1. Maintain the component’s input, input, and methods. Of course, maintaining this information takes a lot of effort, and it can easily fall behind the code.
  2. But my main purpose in creating the component documentation page is to give developers an idea of what components are already wrapped in the current project, and to visually see what it looks like and what it does. Avoid reinventing or building wheels out of ignorance and make common components more valuable.
  3. Provides the demo code copy function, quickly introduce components, reduce the workload of using components
  4. Don’t usevuepressFrameworks such as:
    • To integrate document pages into a project, rather than a separate project, it is easy to maintain and browse
    • Contrast with the framework, so that the development of convenient, self-definition is not limited

There are snippets of code that come up a lot

In the development of a project, we will find a piece of js logic, HTML, in some cases, very often, but they are already very concise and do not need to be re-wrapped, so we can use snippets of vscode to save us work. But vscode’s native snippets are pretty bad:

Not only is it a lot of work to separate the code into comma lines as input, but it’s not intuitive to code that way.

As a rule of thumb, problems you can find usually already have a solution: so I found a treasure plug-in: Snippets

It is very convenient to create, edit, insert code snippets. I won’t go into details about how to use it, but you can try it.

Using it, I maintain several common code snippets that have improved my development efficiency a lot:

Vue custom component templates

<template> 

</template>
<script>
export default {
  props: {
    abc: {
      type: Object.default: () = >{}}},data() {
    return {
      abc: {}}}.methods: {
    abc(){}}}</script>
<style lang="scss" scoped>

</style>
Copy the code

An API request to get data

abc()
    .then(res= > {
      this.abc = res.data.list || []
    })
    .catch(err= > {
      console.error('Request failed:' + err.message)
    })
Copy the code

API request after user operation

Operation success and error messages are displayed

abc({
  abc: this.abc,
})
  .then(() = > {
    this.$message({
      type: 'success'.message: 'Operation successful'
    })
  })
  .catch(err= > {
      this.failDialog(this, err)
  })
Copy the code

API requests requiring secondary validation

Contains the second confirmation pop-up window and success and failure prompts

this.$confirm('Are you sure to delete ABC? `.'tip', {
    confirmButtonText: 'sure'.cancelButtonText: 'cancel'
})
  .then(() = > {
    this.getData()
    this.$message({
      type: 'success'.message: 'Operation successful'
    })
  })
  .catch(err= > {
      this.failDialog(this, err)
  })
Copy the code

El-form form validation

this.$refs.form.validate(valid= > {
    if(! valid) {return}})Copy the code

$message

this.$message({
  type: 'warning'.type: 'success'.type: 'error'.message: 'abc! '
})
Copy the code

El-form verification rule

abc: [{
    validator(rule, value, callback) {
      if(! value) { callback(new Error('Cannot be empty'))
      }
      callback()
    },
    trigger: 'change'}].abc: [{
    required: true.message: 'Cannot be empty'.trigger: 'change'}].Copy the code

Table page template

  • HTML: search bar, tables, pages;
  • Js: get data logic, paging logic

There are plenty of snippets for open source libraries

They already help us encapsulate snippets of library code, similar to snippets of frameworks like Vue Angular React, which can be very efficient if we use certain libraries or frameworks

Common components are not packaged into third-party libraries

If they are packaged as third-party libraries, they can be shared by multiple projects

  • It must be comprehensive enough to cover a variety of details and scenarios, but the plan can’t keep up with changes, especially for business components;
  • There will inevitably be maintenance issues and costs associated with multiple versions of the library, adding to other workloads.
  • At the same time, these components are limited to our current business and are not well adapted to open source and diffusion, so the advantages of packaging into libraries are very small

So I just maintain them in our project template. All new projects will have these common logic capabilities, and since each project is maintained separately, the maintenance cost will be low.

The consequence of over-encapsulation is that code becomes unmaintainable over time. A lot of times it’s a balance between encapsulation and maintainability.

Lazy person improvement series:

Use class names for efficient flex layout

The Element-UI popover component encapsulates a minimalist solution

Simple use of business constants: Eliminate nasty find and mana values