Dear Video Edition

Blog content has been recorded corresponding video, click to jump

Limitations of components in VUE 2

To understand the composite API, we must first understand the limitations of the components in VUE 2.

Currently, you may encounter three limitations when using Vue 2:

  • Code readability issues: As components get larger, readability becomes more and more difficult.
  • Logic reuse issues: It is difficult to reuse the same code logic across multiple components
  • TSRelated issues: 对 TypeScriptSupport is not friendly (this blog will not cover itTS)

So let’s go through the first two limitations to show you in detail what the composite API solves.

Note: there is no explanation in this blogcomposition APIThe use of, only explainedcomposition APIThe meaning of existence. Want to knowcomposition APIThe use ofPlease click here

Code readability issues

Let’s start with the following code:

In the following code, we want to create two responsive pieces of data that get the name and age of the object, respectively, with the click of two buttons.

 GetName gets the name of people when we call getName and getAge gets the age of people when we call getAge
  const component = {
    data() {
      return {
       // Create an object
        people: {
          name: 'LGD_Sunday',
          age: 18
        },
        // Two responsive data
        name: ' ',
        age: ' '
      }
    },
    methods: {
     // Get the name of the object
      getName() {
        this.name = this.people.name;
      },
      // Get the age in the object
      getAge() {
        this.age = this.people.age; }}}const app = Vue.createApp(component)
  app.mount('#app')
Copy the code

This is code in the standard Options API format, and if we were to divide the business involved by color, we would get a graph like this.

Here:

The purple area is the name related code and the green area is the age related code

If your code were more complex, involving props, data, methods, computed, watch, and other attributes, your code structure would look something like this

The components of such a set of code become very difficult to read because it is difficult to figure out which code is used with which code.

This is the first problem that composite apis try to solve. Let’s look at this code.

  const component = {
    setup() {
      const people = {
        name: 'LGD_Sunday',
        age: 18
      }
      // Handle the business related to name
      const name = Vue.ref(' ')
      const getName = () => {
        name.value = people.name;
      }
      // Process age-related services
      const age = Vue.ref(' ')
      const getAge = () => {
        age.value = people.age;
      }

      return {
        name,
        getName,
        age,
        getAge
      }
    }
  }
Copy the code

Based on the code above, we should have a code view that looks like this

Now that we’ve kept the related code together, our code will be more readable and therefore more maintainable.

But?

But I’m sure many experienced developers will have a question when they see such a set of code.

That is: if our code is going to be assembled in such a way, does that mean we’re going to have a giant setup function that describes all the data, methods, computed, and watch in the component?

No, no, no, of course not.

The above code can be handled by grouping functions. Let’s look at the following code.

  const component = {
    setup() {
      const people = {
        name: 'LGD_Sunday',
        age: 18
      }
      return{... useName(people), ... useAge(people) } }, components: { componentB } }// Handle the business related to name
  function useName(people) {
    const name = Vue.ref(' ')
    const getName = () => {
      name.value = people.name;
    }
    return {
      name,
      getName
    }
  }
  // Process age-related services
  function useAge(people) {
    const age = Vue.ref(' ')
    const getAge = () => {
      age.value = people.age;
    }
    return {
      age,
      getAge
    }
  }
Copy the code

Here we create two additional methods that handle things related to name and age. The associated variables and methods are then returned in the setup function via the expansion operator.

Up to now, our code has been perfectly segmented according to its functional modules, making our code more readable.

This set of code logic can also be reused in different components.

Logic reuse problems

Let’s look at the following code:

  // If we have another component at this point, we can still reuse both methods
  const componentB = {
    setup() {
      const people = {
        name: 'Dilieba',
        age: 19
      }
      return{... useName(people), ... useAge(people) } }, template: ` <div> <p>{{name}}</p> <button@click="getName"<div> <p>{{age}}</p> <button@click="getAge"</button> </div> '}// Composition API
  const component = {
    setup() {
      const people = {
        name: 'LGD_Sunday',
        age: 18
      }
      return{... useName(people), ... useAge(people) } }, components: { componentB } }// Handle the business related to name
  function useName(people) {
    const name = Vue.ref(' ')
    const getName = () => {
      name.value = people.name;
    }
    return {
      name,
      getName
    }
  }
  // Process age-related services
  function useAge(people) {
    const age = Vue.ref(' ')
    const getAge = () => {
      age.value = people.age;
    }
    return {
      age,
      getAge
    }
  }

Copy the code

In this code, we created the componentB component and had it reuse the business logic from the useName and useAge methods.

conclusion

At this point, going back to our original logic, we solved two problems with a composite API.

  1. We let components have a much better code organization
  2. We have the same code logic fully reused in different components

This is the core value of a composite API.