| guide language is the biggest characteristic of Vue3 Composition API, can also clearly see that he is affected by the React of Hooks. This article focuses on why Vue uses a new concept to organize code.

To solve what problem?

Let’s take a look at what this new thing is meant to do with Vue 2. Common problems with current projects using Vue2:

  • The readability of the code gets worse as the component gets larger
  • In every way code is reused, there are drawbacks
  • TypeScript support is limited

Let’s take a closer look at the emergence of these problems and the solutions that the Composition API brings

Code readability gradually deteriorates

Suppose we want to write a search box component that first has a basic function – search. The code structure is as follows:After a while, the product manager says to add a sorting requirement, and the component code looks like this:So far it seems ok, until iteration after iteration, such as adding search filters, pagination, etc., blocks of code for all kinds of new functions, written in various places in the project (different components, props, computed, lifecycle functions, data, methods).

Pieces of logic scattered all over the place made our components increasingly difficult to read, often frantically swiping up and down the screen to see a feature, rummaging through blocks and making changes.

In this scenario, using the Composition API allows you to write the same code in the same area for better maintainability and readability.Obviously, if we can write the same code together, it will be more readable than if we write it separately, using the new function setup provided by Vue3. Setup is currently an optional property in Vue3 and is fully compatible with the original component writing.

When you first see this crude use of setup, a lot of people think, isn’t this about me writing a giant setup function and cramming all the component logic into it?

In fact, as long as you wrap all the different functional logic code in functions, this kind of giant setup function does not appear. These are the Composition functions, or if you want to call them “Vue Hooks.”This way of organizing code into functional chunks solves the first problem well, and we move on to the second problem that needs to be solved.

There is no perfect code reuse scheme

When it comes to code reuse, there are three common approaches in Vue2, each of which has limitations.

Vue2 code reuses 1-mixins

Advantages of Mixins: The disadvantages of Mixins can be distinguished by organizing the code functionally:

  1. There are potential conflicts, you can use properties or functions in the same name conflicts
  2. Dependencies are not clear, especially if multiple Mixins communicate.
  3. Logical reuse is not flexible enough if you need to differentiate or configure Mixins across components.

Vue2 code reuse 2-mixin Factory

Use a factory function to return the corresponding Mixin content based on the incoming configuration. The above 2 and 3 can be partially solved by using the Mixin Factory approach, but still cannot be solved:

  1. The same name hidden danger always exists.
  2. The source of the properties is still unclear, and you need to go into each Minxin file to see the exposed properties
  3. There is no run time, so Mixin factory functions cannot be generated dynamically

Vue2 code multiplexed 3-Scoped Slots

Advantages: Solves all of the above disadvantages:

  1. Configuration can only be written to the template
  2. Increased template nesting and reduced readability
  3. Exposed properties can only be used on the template
  4. Implementing the same functionality requires more components to be nested, resulting in lower performance

Vue3 code reuse

As you can see, each of the above methods of code reuse has its own disadvantages, and Vue3’s Composition API provides a fourth solution for code reuse. By pulling away reusable code, our code organization might look like this:

In this way, we can combine and configure reused logic at will and execute it inside a Setup function.

Benefits:

  1. Without discrete blocks, we can write less code, and it’s easier to pull reusable logic out of components and into functions.
  2. More flexible than the original Mixins or Slot approach

Cons: There seems to be no other cons besides using the new grammar

conclusion

Hopefully, this article gave you some insight into why you should use the Composition API.