The introduction

This paper records the differences between 2.* and 3.0 for the author, mainly to help the author understand 3.0, not rigorous teaching, if there are inaccurate places, please do not blame, learn from each other (nonsense or again). If you’re interested in the previous post 👏, check it out here. This post is about the author’s thoughts on how to use the Composition API.

Modular API

Coming to the topic, first of all, I hope you have a deep understanding of Vue2.* otherwise, the following content may not be the content you need to pay attention to, and the first thing you may do is to learn the grammar of 2

option api

First let’s review the configuration or methods of the Option API

// some.vue
<template>
    <! -- some dom -->
</template>
<script>
export default {
    data () {
        return {
            someData: 'someDataDefine'}},methods: {
        someFuntion () {
            // do something}}}</script>
Copy the code

This is something we would normally see in a single file component. What are the benefits of this approach? The author thinks (and only the author thinks) that when a component is a simple business component or a pure UI component, this kind of aggregation is good, so that I can clearly see all the configuration items in a component, and the state/methods /props in the component are very intuitive. But let’s try a different scenario, like this one

Thinking about?

// some.vue
<template>
    <div>
        {{dataA}}
        {{dataB}}
        <button @click="fundctionA">Change A</button>
        <button @click="fundctionB">Change the B</button>
    </div>
</template>
<script>
export default {
    data () {
        return {
            dataA: 'a'.dataB: 'b'}},methods: {
        fundctionA () {
            this.dataA = 'new a'
        },
         fundctionB () {
            this.dataB = 'delete b'}}}</script>
Copy the code

This is a very common scenario, right? And then at this point we’re going to add a C and what do we do? First I need to add a {{dataC}} and add the corresponding dataC definition in the data, then I need to add fundctionC, and then add a corresponding

I’m going to give you two minutes to think about how do we abstract encapsulation?

Extraction and coupling

In fact, the author thinks there are two modes of thinking

Methods a

The idea is that we combine the DOM and business logic we need, such as component A below

// comA.vue
<template>
    <div>
        {{dataA}}
    </div>
</template>
<script>
export default {
    data () {
        return {
            dataA: 'a',}},methods: {
        fundctionA () {
            this.dataA = 'new a'}}}</script>
Copy the code

In this case, we are tying (state/view/method) into a single cell. The advantage of this approach is that outside of the component, you don’t need to worry about managing the internal view and state. You just need to use the leaked content. Scenarios where the applicable view scenario and data state combination are relatively fixed, such as common UI component pop-ups, messages, etc., are more suitable for this approach.

Way 2

Going back to a Vue component, which we can actually think of as being made up of two parts (view layer/logic layer), we might have a scenario where our business data/business scenario/data flow/business model might be fixed. Relevant data and using our do rendering UI is uncertain, this time we expect to do the smallest unit of a business, if in our original 2. * version of what can we do, there will be a great probability several different approaches of practice, but it may be more similar, for our case, we mainly give priority to with financial services, Then we may often encounter a scenario where we need to integrate the information of financial products. At this time, there may be a unit of related product list that we need to deal with, and I may do so

Create a fund.service.js

class Fund {
    constructor () {
        this.list = []
    }
    // Get the list information
    async getList () {
        if (this.list.length === 0) {
            this.list = await api.getList()
        }
        return this.list
    }
    // Find related products
    findItem (code) {
        return this.list.find(item= > item.code === code)
    }
}
export default new Fund()
Copy the code

Page. Vue on the corresponding page component

<template>Uncertain part</template>
<script>
import fund from './fund.service.js'
export default {
    data () {
        return {
            list: []
        }
    },
    created () {
        this.getData()
    },
    methods: {
        async getData () {
            this.list = await fund.getList()
        },
        findItem: (. params) = >fund.findItem(... params) } }</script>
Copy the code

There are several problems with this. First, we need to separate the logic/method/data in the class from the unit. We can also use some corresponding pre-processing methods to solve this problem. However, as long as it is preprocessed or transformed, it is not intuitive and there is a certain starting cost. We then tried to break down the above example using the Composition API

Create a usefund.js

import { reactive, Ref } from 'vue'
export const useFund = () = > {
    const fundlist = reactive([])
    async getList () {
        const list = await api.getList()
        list.forEach(item= > {
            fundlist.push(item)
        })
    }
    findItem (code) {
        return this.list.find(item= > item.code === code)
    }
    return {
        getList,
        findItem,
        fundlist
    }
}
Copy the code

Page. Vue on the corresponding page component

<template>Uncertain part</template>
<script>
import { useFund } from './useFund.js'
export default {
    setup () {
        return {
            ...useFund()
        }
    }
}
</script>
Copy the code

We’ll find that the Composition API is written much more cleanly on the page, allowing us to focus on data interaction rather than business authoring. Conducive to do business to do packaging, do the unit

That’s all for my nonsense. Thank you for watching