Summary of Vue3 combined with TypeScript project development practice

Overview

Vue3 has been out for a while. In the team, we have carried out a lot of business practices and also had some thoughts of our own.

In general, Vue3 has made great progress both in the underlying principles and in the actual development of the business.

Using proxy instead of the previous Object.defineProperty API has better performance and solves the previous defects of Vue in processing objects and arrays; in the diff algorithm, the static tag method is used, which greatly improves the execution efficiency of Vue.

At the usage level, we changed from options API to composition API, and gradually in actual business, we abandoned the original isolated writing style of data, methods, and computed. The compositon API is more focused and emphasizes the aggregation of related businesses. At the same time, in the composition API, in order to prevent overly heavy business logic, it provides a way to separate concerns, which greatly improves the readability of our code.

It fully supports TypeScript, and type verification has become a quality assurance for Vue3 to develop large-scale projects in the future. At the same time, it is also facing the trend - the future of the front-end is TypeScript!

1. Compositon API

The essence of the compositon API is reflected in the code, which is a setup function. In this setup function, the returned data will be used in the template of the component. The returned object, to a certain extent, represents the data attribute in the previous vue2.

import { defineComponent, ref } from 'vue';
export default defineComponent({
    name: 'Gift',
    setup() {
        const counter = ref(0);
        return {
            counter
        }
    }
})

At this time, for most beginners, the possible doubt is, can I define the writing method of options Api, such as data, computed, watch, methods, etc.

What I need to make clear here is that Vue3 is fully compatible with Vue2's options API writing method, but in theory, the setup method is more recommended to write our components. The reasons are as follows: The existence of Vue3 itself is to solve the problems of Vue2. The problem with Vue2 is that it lacks aggregation, which will cause the code to become more and more bloated! The setup method can aggregate data, method logic, dependencies, etc. together, making maintenance easier.

In other words, we should try not to write separate data, computed, watch, methods, etc. in the future. It is not that Vue3 does not support it, but it goes against the concept of Vue3.

The components property, that is, the subcomponents of a component, has little difference between Vue2 and 3. Vue3 still uses it the same way as Vue2.

1. What is the difference between ref and reactive?

In terms of functionality, both ref and reactive can realize responsive data!
At the grammatical level, there are differences between the two. The responsive data defined by ref needs to be changed using [data].value; the data defined by reactive needs to be changed using [data].[prpoerty].

const actTitle: Ref<string> = ref('Activity name');

const actData = reactive({
    list: [],
    total: 0,
    currentPage: 1,
    pageSize: 10
});

actTitle.value = 'Activity Name 2';

actData.total = 100;

However, there are still differences at the application level. Generally speaking, for a single common type of data, we use ref to define the responsiveness. In form scenarios, reactive is used to describe objects such as key:value of a form. In some scenarios, a set of data of a module is also defined in a reactive way.

So, do objects have to be defined using reactive? Actually, no, both are fine. You should analyze specific problems according to your own business scenarios! ref emphasizes the change of the value of a data, while reactive emphasizes the change of a property of the defined object.

2. Periodic functions

In Vue3, periodic functions are used separately as follows:

import { defineComponent, ref, onMounted } from 'vue';
export default defineComponent({
    name: 'Gift',
    setup() {
        const counter = ref(0);
        onMounted(() => {
            // Process business, generally make data requests})
        return {
            counter
        }
    }
})

3. Store usage

In Vue2, you can actually get it directly through this.$store, but in Vue3, there is actually no concept of this, and the usage is as follows:

import { useStore } from "vuex";
import { defineComponent, ref, computed } from 'vue';
export default defineComponent({
    name: 'Gift',
    setup() {
        const counter = ref(0);
        const store = useStore();
        const storeData = computed(() => store); // Cooperate with computed to get the value of store.
        return {
            counter,
            storeData
        }
    }
})

4. Use of router

In Vue2, functional programming of routing is done through this.$router, but in Vue3, it is used like this:

import { useStore } from "vuex";
import { useRouter } from "vue-router";
import { defineComponent, ref, computed } from 'vue';
export default defineComponent({
    name: 'Gift',
    setup() {
        const counter = ref(0);
        const router = useRouter();
        const onClick = () => {
            router.push({ name: "AddGift" });
        }
        return {
            counter,
            onClick
        }
    }
})

2. Separation of concerns

Separation of concerns should be divided into two meanings: the first meaning is that Vue3's setup itself puts related data and processing logic together, which is a kind of aggregation of concerns, making it easier for us to read business codes.

The second meaning is that when the setup becomes larger, we can extract a related piece of business within the setup and achieve the second level of separation of concerns.

import { useStore } from "vuex";
import { useRouter } from "vue-router";
import { defineComponent, ref, computed } from 'vue';
import useMerchantList from './merchant.js';
export default defineComponent({
    name: 'Gift',
    setup() {
        const counter = ref(0);
        const router = useRouter();
        const onClick = () => {
            router.push({ name: "AddGift" });
        }
        // In this example, we separate the business of getting the merchant list. That is the following merchant.ts
        const {merchantList} = useMerchantList();
        return {
            counter,
            onClick,
            merchantList
        }
    }
})

merchant.ts

import { getMerchantlist } from "@/api/rights/gift";
import { ref, onMounted } from "vue";

export default function useMerchantList(): Record<string, any> {
  const merchantList = ref([]);
  const fetchMerchantList = async () => {
    let res = await getMerchantlist({});
    merchantList.value = res?.data?.child;
  };

  onMounted(fetchMerchantList);

  return {
    merchantList
  };
}

3. TypeScript support

This part of the content, to be precise, is the content of TS, but it is closely related to the development of the Vue3 project, so if we really want to use Vue3, we still have to understand the use of TS.

However, in this part, I will not introduce the basic syntax of TS, but mainly how to organize TS in business scenarios.

When using TS for business development, a core idea is to focus on the data structure first, and then develop the page based on the data structure. The previous front-end development model was to write the page first and then focus on the data.

For example, if we want to write a gift list page, we may need to define some interfaces. In short, what we need to pay attention to are: the interface of the page data, the data type returned by the interface, the input parameter type of the interface, and so on.

// Each item in gift creation, editing, and list will be of this data type.
interface IGiftItem {
  id: string | number;
  name: string;
  desc: string;
  [key: string]: any;
}

// Global corresponding type definition // And generally speaking, we are not sure what the type returned by the interface is (it may be null, it may be an object, or it may be an array), so we use the generic type to define the interface
interface IRes<T> {
    code: number;
    msg: string;
    data: T
}
//Interface return data type definition interface IGiftInfo {
    list: Array<IGiftItem>;
    pageNum: number;
    pageSize: number;
    total: number;
}

In a common interface request, we generally use TS to define a data request, the req type of the data request, and the res type of the data request.

export const getGiftlist = (
  params: Record<string, any>
): Promise<IRes<IGiftInfo>> => {
  return Http.get("/apis/gift/list", params);
};

This concludes this article on the practice summary of Vue3 combined with TypeScript project development. For more relevant Vue3 TypeScript development content, please search for previous articles on 123WORDPRESS.COM or continue to browse the following related articles. I hope everyone will support 123WORDPRESS.COM in the future!