Vue業務實例分析

這篇“Vue業務實例分析”文章的知識點大部分人都不太理解，所以小編給大家總結了以下內容，內容詳細，步驟清晰，具有一定的借鑒價值，希望大家閱讀完這篇文章能有所收獲，下面我們一起來看看這篇“Vue業務實例分析”文章吧。

寫業務，對于一個前端而言，應該是再正常不過的事了，業務對標著需求，前端 er 們根據產品的需求以及設計師的設計稿開發出相應的 web 應用，無論是一個簡單的頁面或是一套復雜的系統，或多或少摻雜著業務邏輯。然而，我們有時候寫的業務邏輯到底是為了去寫業務邏輯而寫的嗎，作為一個常年與業務抗戰的騷 nian，我認為我們寫的業務不光光是為了在排期內完成簡單的任務，而是要打磨自己寫業務的能力，并學會根據實際場景去設計一套靈活的，可維護，易理解的業務代碼。

那以上所說的 “實際場景” 到底指的是什么場景呢，答案并不唯一，往往自己實踐中碰到的難題都可以是一種場景，我們要學會理解這些場景。當然，場景不光歸結于產品的 prd，而且往往還跟后端的提供的數據結構著密切的關聯，夸張點的比喻就是，好比產品需要一道集色香味俱全的菜，前端就像是一個廚師，但手頭的廚具，以及品種不夠多的食材，但就是要烹飪一道好菜，其實就是個手藝活。廢話不多說了，直接上菜譜：

場景一

步驟框：第一步 -> 第二步 -> 第三步

這是一個常見的例子，這是一套流程，我們要做的就是串通整個流程直到結束。這種例子以表單為常見，除了順序執行，還可提供上一步按鈕，供用戶返回上一步重新填寫。

使用Vue來設計：

父組件可以是個自定義的 dialog 組件，裝著每個流程的頁面

<v-dialog>

    <step1></step1>

    <step2></step2>

    <step3></step3>

</v-dialog>

這是一套標準的教科書式寫法，哈哈哈，其實我也不介意使用 Vue 的內置 Component:

<template>

    <v-dialog>

        <keep-alive>

            <component :is="conf.component" v-bind="conf.props"

                v-on="conf.listeners">

            </component>

        </keep-alive>

    </v-dialog>

</template>

<script>

    import stepOne from './step-one'

    import stepTwo from './step-two'

    import stepThree from './step-three'

    const MAP = {

        0: stepOne,

        1: stepTwo,

        2: stepThree

    }

    export default {

        data () {

            return {

                active: 0 // 0代表第一個頁面的索引

            }

        },

        computed: {

            conf () {

                return {

                    component: MAP[this.active],

                    props: { ... },

                    listeners: { ... }

                }

            }

        }            

    }

</script>

乍一看頁面沒有很特別的地方，往往問題會從兩個方向去發展：橫向擴展和縱向擴展。

具體點說，如果這個時候產品又要往后再加一個步驟頁面呢，但從開發的角度來講，我們不能僅僅要考慮產品會這一個步驟，可能會加N個步驟（往復雜點想），當然產品如果這么玩的，這個頁面的交互還是挺差的。

當然多頁面的方式，還是更傾向于使用Vue的內置 component。

說玩設計，再來說說接口。這種表單設計，無非就是兩種操作，新增和編輯。理想情況下，編輯狀態時，前端是希望每個頁面的數據獨立獲取，這里暫且不提每個頁面之間的依賴關系，但現實往往是后端會把這幾個頁面的所有數據塞入一個對象中從接口返回。這無非是增加了前端處理的復雜度。

對于這種場景，前端的常規操作有：

這是最常規的處理方式，但如果每個頁面都需要傳遞不同的 props，那父組件會變得非常臃腫。

這個時候我們再從縱向的角度考慮下：

縱向的問題增加了 Event Emits 和 Pass Props 操作的復雜度，對于我們日常維護會有很大的困擾。這個時候或許有些人會提議使用 Vuex，Vuex 確實能夠方便我們管理狀態，并且每個組件里都能獲取到這個狀態，只要通過簡單的 mapState 即刻獲取。但 Vuex 的使用也要根據實際場景，如果僅僅是2個頁面的話，使用 Vuex 有的時候恰恰加大了工作量，這很矛盾，我們又要用最簡單的方式處理，又要考慮到擴展要不要使用 Vuex，這個時候我還是建議大家多考慮清楚，或者和產品就頁面設計的走向了解一個大概。

橫向問題和縱向問題只是個簡單的開始，現在場景要更復雜一點了，頁面之間會有依賴。

具體點，就是頁面一表單的數據更改會影響到頁面二的數據展示，頁面二的數據更改會影響到頁面三的數據展示。

其實我們也有更好的處理方式，我們需要一個 Controller。

class Manage {

    constructor () {

        this.step1 = null

        this.step2 = null

        this.step3 = null

    }

    add (step, instance) {

        this[step] = instance

    }

}

export default new Manage()

頁面級：

import manage from './Manage.js'

export default {

    name: 'Step1'

    ...

    ...

    ...

    created () {

        manage.add('step1', this)

    }

}

import manage from './Manage.js'

export default {

    name: 'Step2'

    ...

    ...

    ...

    created () {

        manage.add('step2', this)

    }

}

這樣組件之間的數據共享，可以通過 controller 去處理，獲得每個組件的實例并且直接獲取數據。

另外，我們還能夠向 controller 對象注入一個 store。

const store = new Vue({

    data () {

        return { ... }

    }

})

class Manage {

    constructor () {

        this.store = store

    }

}

這樣組件之間又可以共享一些數據。

寫業務之前首先還得多和產品撕下逼，了解產品到底想作甚，剛需，再來考慮交互實現方式，這里不得重新提下軟文我只是想在頁面上加個鏈接。寫之前還是得多從宏觀上去構建一下，而不是只著眼于細節，畢竟這樣也能減少大家重構代碼的概率。

以上就是關于“Vue業務實例分析”這篇文章的內容，相信大家都有了一定的了解，希望小編分享的內容對大家有幫助，若想了解更多相關的知識內容，請關注億速云行業資訊頻道。