Vue3 combined API


Vue3 combined API

Most front-end Vue developers will have a question why they use the composition API. When to use it, how to use it, and what benefits can it bring us. This tutorial aims to solve the above problem. To solve this problem, let’s start with understanding the shortcomings of vue2. It can also be said that the following limitations of vue2 have led to the generation of composite API:

  • Large vue2 based components are difficult to maintain.
  • It is difficult to reuse component logic based on vue2 encapsulation.
  • Vue2 has limited support for typescript.

Let’s focus on the first two problems. As long as we discuss the first two problems clearly, we will understand what problems the composite API solves.

Large components encapsulated by vue2 optional API are difficult to maintain

To illustrate this problem, we take a search component as an example, which mainly completes the function of searching products on the website. In order to illustrate the problem more vividly, we describe it by gradually increasing the demand function.
Vue3 combined API
The component is encapsulated with standard vue2 syntax, as shown in the following figure
Vue3 combined API
When the product manager asks us to add another function to sort query results, our logic may become as follows:
Vue3 combined API
From the above two simple functions, the code is not bad, but when we continue to increase functional requirements in this component, such as adding search filtering and result paging. Our same logic code will be unpacked in different options (components, props, data, computed, methods, and lifecycle methods), resulting in scattered logic concerns, poor understanding of components, and reduced readability. If we mark the same logic with color (such as subscript red), we can see how scattered the code is, and it is difficult to understand which codes are related to which functional logic.
Vue3 combined API
As we can imagine (the green part of the icon above), if we can keep the same logical code together, our code will be more readable and easier to maintain. In this example, if the code is combined using the composition API, it will be as follows:
Vue3 combined API
As shown in the figure above, we need to make vue3’s composition API. The code in setup () is the new method I will talk about in a later tutorial. It is worth noting that this new method is completely optional, and the optional interface method of writing Vue components is still fully effective.

When some developers see this setup for the first time, they may think, “will we write all the logic code in the setup method, so will the code logic become more difficult to understand and read?”. This question is just like vue3 make complaints about just a lot of open source. The root of Tucao is that most of them do not make complaints about the nature of setup. When we really encapsulate the reuse logic into the composite function according to the official requirements, and then reference it in the setup, the above problems will not occur. The following organization code.

Vue3 combined API

Now that we have seen how component APIs make large components more readable and maintainable, we will discuss the second limitation of Vue 2.

It is difficult to reuse component logic based on vue2 optional API encapsulation.

When it comes to reusing code across components, there are three good solutions in Vue 2 to achieve this, but each has its limitations. Let’s use our examples to explain them one by one. First take a look at mixins, as shown in the following figure
Vue3 combined API

The advantages of hybrid mode are as follows:

  • Mixins can organize code according to logical concerns

The disadvantages of using mixed mode are also obvious:

  • They are prone to conflicts, which may eventually lead to attribute name conflicts.
  • It’s not clear how mixed elements work
  • The mixed component properties are not easy to reuse in other components.

For the last item, let’s look at the mixin factory. These functions return custom mixins.

Vue3 combined API

As can be seen from the above figure, the mixing Factory allows us to customize the mixing by configuring the namespace, so that it can be used in multiple components. This method has the following advantages:

  • Now we can easily achieve reuse by defining namespaces.
  • The relationship between reuse methods is more clear.

However, it also has the following disadvantages:

  • Namespaces need to be strictly standardized to ensure that they do not conflict.
  • Implicit properties still cannot be avoided, which means that we must look inside mixin to find the properties it exposes.
  • No corresponding instance is accessible at runtime, so the mixin factory cannot be generated dynamically.

Fortunately, there is another solution, that is, our common – scope slot:
Vue3 combined API

The slot scheme has the following advantages:

  • It solves almost all the shortcomings of mixins.

But there are also disadvantages:

  • Your configuration eventually appears in the template. Ideally, the template should contain only what we want to present.
  • They increase the indentation of the template and reduce readability.
  • Exposed properties are only available in templates.
  • Since we use three components instead of one, the performance is reduced.

As we can see, each solution has limitations. The composition API of Vue 3 provides us with the fourth scheme for organizing reusable code, as shown in the following figure:

Vue3 combined API

Now, we will use the functions inside the composition API to create components, which will be imported and used in our setup () method.

Advantages of combined API:

  • Because it is based on functions, it is easier to extract functional parts from components into functions than the above scheme.
  • Since you are already familiar with function writing, it is easier to start based on your existing skills.
  • It is more flexible than mixins and scoped slots because they are just functions.
  • It is more friendly to the code editor. Combined with strong types, it can realize intelligent prompts, and greatly increase the code writing experience.

Things are not perfect, but there are also disadvantages:

  • You need to learn a new low-level API to define the composition API.
  • There are now two ways to write components, not just standard syntax.

The above explains why the composition API is used. Next, let’s make a summary by quoting the official article:

1. Better logic reuse and code organization

We all love Vue because it’s easy to learn. It makes it easy to build small and medium-sized applications. However, with the growing influence of Vue, many users also began to use Vue to build larger projects. These projects are usually composed of teams of multiple developers, which are constantly iterated and maintained over a long period of time. Over the years, we have seen some of these projects encounter the limitations of the programming model brought about by Vue’s current API. These problems can be divided into two categories:

  1. With the growth of function, the code of complex components becomes more and more difficult to read and understand. This is particularly common when developers read code written by others. The root cause is that Vue’s existing API forces us to organize code through options, but sometimes it makes more sense to organize code through logical relationships.
  2. At present, there is a lack of a concise and low-cost mechanism to extract and reuse the logic between multiple components.

The composition API provides greater flexibility for the organization of component code. Now we don’t need to always organize the code through options, but we can organize the code into functions that handle specific functions. These APIs also make it easier to extract and reuse logic between and even outside components.

2. Better type derivation

Another common requirement from developers of large projects is better typescript support. Vue’s current API encounters a lot of trouble when integrating typescript. The main reason is that Vue relies on a simple this context to expose properties. The way we use this now is more subtle( For example, this of the function under the methods option points to the component instance instead of the methods object). In other words, Vue’s existing API does not take into account type derivation at the beginning of design, which makes adapting typescript complex.

At present, most Vue developers using typescript are writing components as typescript classes through the Vue class component library (with the help of decorator). We had an abandoned proposal when designing 3.0, hoping to provide a built-in class API to better solve the type problem. However, when discussing and iterating over its specific design, we noticed that if we want to solve the type problem through the class API, we must rely on decorator, a very unstable stage 2 proposal with many unknowns in implementation details. Based on it, there are great risks.

The code written by the composition API will enjoy type derivation perfectly without too many additional type annotations. This also means that the JavaScript code you write is almost typescript code. Even non typescript developers will benefit from better ide type support.

Recommended Today

C # regular implementation of UBB parsing class code

The parsed code can pass XHTML   one   Strict verification;It includes title, link, font, alignment, picture, reference, list and other functions  Ubb.ReadMe.htm UBB code description title [H1] title I [/ H1] Title I [H2] Title II [/ H2] Title II [H1] Title III [/ H1] Title III [H4] Title IV [/ H4] Title IV […]