Vuex store怎么創(chuàng)建

本篇內(nèi)容主要講解“Vuex store怎么創(chuàng)建”，感興趣的朋友不妨來看看。本文介紹的方法操作簡(jiǎn)單快捷，實(shí)用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“Vuex store怎么創(chuàng)建”吧!

狀態(tài)與組件的誕生

自三大框架誕生起，它們共有的兩個(gè)能力徹底暴擊了 Jquery。這兩個(gè)能力分別是：

1. 數(shù)據(jù)驅(qū)動(dòng)視圖

2. 組件化

數(shù)據(jù)驅(qū)動(dòng)視圖，使我們告別了只能依靠操作 DOM 更新頁面的時(shí)代。我們不再需要每次更新頁面時(shí)，通過層層 find 找到 DOM 然后修改它的屬性和內(nèi)容，可以通過操作數(shù)據(jù)來實(shí)現(xiàn)這些事情。

當(dāng)然了在我們前端的眼里，數(shù)據(jù)基本可以理解為存儲(chǔ)各種數(shù)據(jù)類型的 變量。在 數(shù)據(jù)驅(qū)動(dòng) 這個(gè)概念出現(xiàn)之后，一部分變量也被賦予了特殊的含義。

首先是普通變量，和 JQ 時(shí)代沒差，僅用來存儲(chǔ)數(shù)據(jù)。除此之外還有一類變量，它們有響應(yīng)式的作用，這些變量與視圖綁定，當(dāng)變量改變時(shí)，綁定了這些變量的視圖也會(huì)觸發(fā)對(duì)應(yīng)的更新，這類變量我稱之為狀態(tài)變量。

所謂數(shù)據(jù)驅(qū)動(dòng)視圖，嚴(yán)格說就是狀態(tài)變量在驅(qū)動(dòng)視圖。隨著 Vue，React 的大力普及之下，前端開發(fā)們的工作重心逐漸從操作 DOM 轉(zhuǎn)移到了操作數(shù)據(jù)，狀態(tài)變量成為了核心。

狀態(tài)變量，現(xiàn)在大家似乎更愿意稱之為狀態(tài)。我們經(jīng)常詞不離口的狀態(tài)，狀態(tài)管理，其實(shí)這個(gè)狀態(tài)就是指狀態(tài)變量。下文提到的狀態(tài)同樣也是指狀態(tài)變量。

有了狀態(tài)之后，組件也來了。

JQ 時(shí)代的前端一個(gè)頁面就是一個(gè) html，沒有“組件”的概念，對(duì)于頁面中的公共部分，想要優(yōu)雅的實(shí)現(xiàn)復(fù)用簡(jiǎn)直不要太難。所幸三大框架帶來了非常成熟的組件設(shè)計(jì)，可以很容易的抽取一個(gè) DOM 片段作為組件，而且組件內(nèi)部可以維護(hù)自己的狀態(tài)，獨(dú)立性更高。

組件的一個(gè)重要特性，就是內(nèi)部的這些狀態(tài)是對(duì)外隔離的。父組件無法訪問到子組件內(nèi)部的狀態(tài)，但是子組件可以訪問父組件顯示傳過來的狀態(tài)（Props），并且根據(jù)變化自動(dòng)響應(yīng)。

這個(gè)特性可以理解為狀態(tài)被模塊化了。這樣的好處是，不需要考慮當(dāng)前設(shè)置的狀態(tài)會(huì)影響到其他組件。當(dāng)然了組件狀態(tài)徹底隔離也是不現(xiàn)實(shí)的，必然會(huì)有多個(gè)組件共享狀態(tài)的需求，這種情況的方案就是將狀態(tài)提取到離這些組件最近的父組件，通過 Props 向下傳遞。

上述共享狀態(tài)的方案，在通常情況下是沒有問題的，也是一種官方建議的最佳實(shí)踐。

但是如果你的頁面復(fù)雜，你會(huì)發(fā)現(xiàn)還是有力不從心的地方。比如：

• 組件層級(jí)太深，需要共享狀態(tài)，此時(shí)狀態(tài)要層層傳遞。

• 子組件更新一個(gè)狀態(tài)，可能有多個(gè)父組件，兄弟組件共用，實(shí)現(xiàn)困難。

這種情況下繼續(xù)使用 “提取狀態(tài)到父組件” 的方法你會(huì)發(fā)現(xiàn)很復(fù)雜。而且隨著組件增多，嵌套層級(jí)加深，這個(gè)復(fù)雜度也越來越高。因?yàn)殛P(guān)聯(lián)的狀態(tài)多，傳遞復(fù)雜，很容易出現(xiàn)像某個(gè)組件莫名其妙的更新，某個(gè)組件死活不更新這樣的問題，異常排查也會(huì)困難重重。

鑒于此，我們需要一個(gè)更優(yōu)雅到方案，專門去處理這種復(fù)雜狀況下的狀態(tài)。

需要狀態(tài)管理嗎？

上一節(jié)我們說到，隨著頁面的復(fù)雜，我們?cè)诳缃M件共享狀態(tài)的實(shí)現(xiàn)上遇到了棘手的問題。

那么有沒有解決方案呢？當(dāng)然有的，得益于社區(qū)大佬們的努力，方案還不止一個(gè)。但是這些方案都有一個(gè)共同的名字，就是我們?cè)趦赡昵坝懻摲浅＜ち业?——— 狀態(tài)管理。

狀態(tài)管理，其實(shí)可以理解為全局狀態(tài)管理，這里的狀態(tài)不同于組件內(nèi)部的狀態(tài)，它是獨(dú)立于組件單獨(dú)維護(hù)的，然后再通過某種方式與需要該狀態(tài)的組件關(guān)聯(lián)起來。

狀態(tài)管理各有各的實(shí)現(xiàn)方案。Vue 有 Vuex，React 有 Redux，Mobx，當(dāng)然還有其他方案。但是它們解決的都是一個(gè)問題，就是跨組件狀態(tài)共享的問題。

我記得前兩年因?yàn)?“狀態(tài)管理” 這個(gè)概念的火熱，好像成了應(yīng)用開發(fā)不可或缺的一部分。以 Vue 為例，創(chuàng)建一個(gè)項(xiàng)目必然會(huì)引入 Vuex 做狀態(tài)管理。但是很多人不知道為什么用，什么時(shí)候用，怎么用狀態(tài)管理，只是盲目跟風(fēng)，于是后來出現(xiàn)了非常多濫用狀態(tài)管理的例子。

看到這里，你應(yīng)該知道狀態(tài)管理不是必須的。它為什么出現(xiàn)，以及它要解決什么問題，上面基本都說明白了。如果你還沒明白，請(qǐng)暫停，從開頭再讀一遍。不要覺得一個(gè)技術(shù)方案誕生的背景不重要，如果你不明白它的出現(xiàn)是為了解決什么問題，那么你就無法真正發(fā)揮它的作用。

Redux 作者有一句名言：如果你不知道是否需要 Redux（狀態(tài)管理），那就是不需要它。

好了，如果你在用狀態(tài)管理，或需要使用狀態(tài)管理幫你解決問題，那我們繼續(xù)往下看。

Vuex

Vue 在國內(nèi)的應(yīng)用非常廣泛，尤其是中小團(tuán)隊(duì)，因此大多人接觸到的第一個(gè)狀態(tài)管理方案應(yīng)該就是 Vuex。

那么 Vuex 是如何解決跨組件狀態(tài)共享的問題的呢？我們一起來探索一下。

創(chuàng)建 store

我們上面說到，對(duì)于一般的組件共享狀態(tài)，官方建議“提取狀態(tài)到最近的父組件”。Vuex 則是更高一步，將所有狀態(tài)提取到了根組件，這樣任何組件都能訪問到。

也許你會(huì)問：這樣做不是把狀態(tài)暴露到全局了嗎？不就徹底消除模塊化的優(yōu)勢(shì)了嗎？

其實(shí)不然。Vuex 這么做的主要目的是為了讓所有組件都可以訪問到這些狀態(tài)，徹底避免子組件狀態(tài)訪問不了的情況。Vuex 把所有狀態(tài)數(shù)據(jù)都放在一個(gè)對(duì)象上，遵循單一數(shù)據(jù)源的原則。但是這并不代表狀態(tài)是堆砌的，Vuex 在這顆單一狀態(tài)樹上實(shí)現(xiàn)了自己的模塊化方案。

別急，我們一步步來，先看看如何使用 Vuex。

Vuex 是作為 Vue 的插件存在的，首先 npm 安裝：

$ npm install --save vuex

安裝之后，我們新建 src/store 文件夾，在這里放所有 Vuex 相關(guān)的代碼。

新建 index.js 并寫入如下代碼。這段代碼主要的作用就是用 Vue.use 方法加載 Vuex 這個(gè)插件，然后將配置好的 Vuex.Store 實(shí)例導(dǎo)出。

import Vue from 'vue'
import Vuex from 'vuex'
// 安裝插件
Vue.use(Vuex)

export default new Vuex.Store({
  state: {},
  mutations: {},
  actions: {},
  modules: {}
})

上面導(dǎo)出的實(shí)例我們通常稱之為 store。一個(gè) store 中包含了存儲(chǔ)的狀態(tài)（state）和修改狀態(tài)的函數(shù)（mutation）等，所有狀態(tài)和相關(guān)操作都在這里定義。

最后一步，在入口文件將上面導(dǎo)出的 store 實(shí)例掛載到 Vue 上：

import store from './store'

new Vue({
  el: '#app',
  store: store
})

注意：掛載這一步不是必須的。掛載這一步的作用只是為了方便在 .vue 組件中通過 this.$store 訪問我們導(dǎo)出的 store 實(shí)例。如果不掛載，直接導(dǎo)入使用也是一樣的。

單一數(shù)據(jù)源（state）

上一步我們用構(gòu)造函數(shù) Vuex.Store 創(chuàng)建了 store 實(shí)例，大家至少知道該怎么用 Vuex 了。這一步我們來看看 Vuex.Store 構(gòu)造函數(shù)的具體配置。

首先是 state 配置，他的值是一個(gè)對(duì)象，用來存儲(chǔ)狀態(tài)。Vuex 使用 單一狀態(tài)樹 原則，將所有的狀態(tài)都放在這個(gè)對(duì)象上，便于后續(xù)的狀態(tài)定位和調(diào)試。

比如說我們有一個(gè)初始狀態(tài) app_version 表示版本，如下：

new Vuex.Store({
  state: {
    app_version: '0.1.1'
  }
}

現(xiàn)在要在組件中獲取，可以這樣：

this.$store.state.app_version

但這并不是唯一的獲取方式，也可以這樣：

import store from '@/store' // @ 表示 src 目錄
store.state.app_version

為什么要強(qiáng)調(diào)這一點(diǎn)呢？因?yàn)楹芏嘈』锇橐詾?Vuex 只能通過 this.$store 操作。到了非組件內(nèi)，比如在請(qǐng)求函數(shù)中要設(shè)置某一個(gè) Vuex 的狀態(tài)，就不知道該怎么辦了。

事實(shí)上組件中獲取狀態(tài)還有更優(yōu)雅的方法，比如 mapState 函數(shù)，它讓獲取多狀態(tài)變得更簡(jiǎn)單。

import { mapState } from 'vuex'

export default {
  computed: {
    ... // 其他計(jì)算屬性
    ...mapState({
      version: state => state.app_version
    })
  }
}

狀態(tài)更新方式（mutation）

Vuex 中的狀態(tài)與組件中的狀態(tài)不同，不能直接用 state.app_version='xx' 這種方式修改。Vuex 規(guī)定修改狀態(tài)的唯一方法是提交 mutation。

Mutation 是一個(gè)函數(shù)，第一個(gè)參數(shù)為 state，它的作用就是更改 state 的狀態(tài)。

下面定義一個(gè)名叫 increment 的 mutation，在函數(shù)內(nèi)更新 count 這個(gè)狀態(tài)：

new Vuex.Store({
  state: {
    count: 1
  },
  mutations: {
    increment(state, count) {
      // 變更狀態(tài)
      state.count += count
    }
  }
})

然后在 .vue 組件中觸發(fā) increment：

this.$store.commit('increment', 2)

這樣綁定了 count 的視圖就會(huì)自動(dòng)更新。

同步更新

雖然 mutation 是更新狀態(tài)的唯一方式，但實(shí)際上它還有一個(gè)限制：必須是同步更新。

為什么必須是同步更新？因?yàn)樵陂_發(fā)過程中，我們常常會(huì)追蹤狀態(tài)的變化。常用的手段就是在瀏覽器控制臺(tái)中調(diào)試。而在 mutation 中使用異步更新狀態(tài)，雖然也會(huì)使?fàn)顟B(tài)正常更新，但是會(huì)導(dǎo)致開發(fā)者工具有時(shí)無法追蹤到狀態(tài)的變化，調(diào)試起來就會(huì)很困難。

再有 Vuex 給 mutation 的定位就是更改狀態(tài)，只是更改狀態(tài)，別的不要參與。所謂專人干專事兒，這樣也幫助我們避免把更改狀態(tài)和自己的業(yè)務(wù)邏輯混起來，同時(shí)也規(guī)范了函數(shù)功能。

那如果確實(shí)需要異步更新，該怎么辦呢？

異步更新

異步更新狀態(tài)是一個(gè)非常常見的場(chǎng)景，比如接口請(qǐng)求回來的數(shù)據(jù)要存儲(chǔ)，那就是異步更新。

Vuex 提供了 action 用于異步更新狀態(tài)。與 mutation 不同的是，action 不直接更新狀態(tài)，而是通過觸發(fā) mutation 間接更新狀態(tài)。因此即便使用 action 也不違背 “修改狀態(tài)的唯一方法是提交 mutation” 的原則。

Action 允許在實(shí)際更新狀態(tài)前做一些副作用的操作，比如上面說的異步，還有數(shù)據(jù)處理，按條件提交不同的 mutation 等等。看一個(gè)例子：

new Vuex.Store({
  state: {
    count: 1
  },
  mutations: {
    add(state) {
      state.count++
    },
    reduce(state) {
      state.count--
    }
  },
  actions: {
    increment(context, data) {
      axios.get('**').then(res => {
        if (data.iscan) {
          context.commit('add')
        } else {
          context.commit('reduce')
        }
      })
    }
  }
})

在組件中觸發(fā) action：

this.$store.dispatch('increment', { iscan: true })

這些就是 action 的使用方法。其實(shí) action 最主要的作用就是請(qǐng)求接口，拿到需要的數(shù)據(jù)，然后觸發(fā) mutation 修改狀態(tài)。

其實(shí)這一步在組件中也可以實(shí)現(xiàn)。我看過一些方案，常見的是在組件內(nèi)寫一個(gè)請(qǐng)求方法，當(dāng)請(qǐng)求成功，直接通過 this.$store.commit 方法觸發(fā) mutation 來更新狀態(tài)，完全用不到 action。

難道 action 可有可無嗎？

也不是，在特定場(chǎng)景下確實(shí)需要 action 的，這個(gè)會(huì)在下一篇說。

狀態(tài)模塊化（module）

前面講過，Vuex 是單一狀態(tài)樹，所有狀態(tài)存放在一個(gè)對(duì)象上。同時(shí) Vuex 有自己的模塊化方案
，可以避免狀態(tài)堆砌到一起，變的臃腫。

Vuex 允許我們將 store 分割成模塊（module），每個(gè)模塊擁有自己的 state、mutation、action。雖然狀態(tài)注冊(cè)在根組件，但是支持模塊分割，相當(dāng)于做到了與頁面組件平級(jí)的“狀態(tài)組件”。

為了區(qū)分，我們將被分割的模塊稱為子模塊，暴露在全局的稱為全局模塊。

我們來看基礎(chǔ)用法：

new Vuex.Store({
  modules: {
    user: {
      state: {
        uname: 'ruims'
      },
      mutation: {
        setName(state, name) {
          state.name = name
        }
      }
    }
  }
})

上面定義了 user 模塊，包含了一個(gè) state 和一個(gè) mutation。在組件中使用方法如下：

// 訪問狀態(tài)
this.$store.state.user.uname
// 更新狀態(tài)
this.$store.commit('setName')

大家發(fā)現(xiàn)了，訪問子模塊的 state 要通過 this.$store.state.[模塊名稱] 這種方式去訪問，觸發(fā) mutation 則與全局模塊一樣，沒有區(qū)別。

action 與 mutation 原理一致，不細(xì)說。

命名空間

上面說到，子模塊觸發(fā) mutation 和 action 與全局模塊一致，那么假設(shè)全局模塊和子模塊中都有一個(gè)名為 setName 的 mutation。在組件中觸發(fā)，哪個(gè) mutation 會(huì)執(zhí)行呢？

經(jīng)過試驗(yàn)，都會(huì)執(zhí)行。官方的說法是：為了多個(gè)模塊能夠?qū)ν?mutation 或 action 作出響應(yīng)。

其實(shí)官方做的這個(gè)兼容，我一直沒遇到實(shí)際的應(yīng)用場(chǎng)景，反而因?yàn)橥?mutation 導(dǎo)致誤觸發(fā)帶來了不少的麻煩?？赡芄俜揭惨庾R(shí)到了這個(gè)問題，索引后來也為 mutation 和 action 做了模塊處理方案。

這個(gè)方案，就是命名空間。

命名空間也很簡(jiǎn)單，在子模塊中加一個(gè) namespaced: true 的配置即可開啟，如：

new Vuex.Store({
  modules: {
    user: {
      namespaced: true,
      state: {}
    }
  }
})

開啟命名空間后，觸發(fā) mutation 就變成了：

this.$store.commit('user/setName')

可見提交參數(shù)由 '[mutation]' 變成了 '[模塊名稱]/[mutation]'。

模塊化的槽點(diǎn)

上面我們介紹了 Vuex 的模塊化方案，將單一狀態(tài)樹 store 分割成多個(gè) module，各自負(fù)責(zé)本模塊狀態(tài)的存儲(chǔ)和更新。

模塊化是必要的，但是這個(gè)模塊的方案，用起來總覺得有點(diǎn)別扭。

比如，總體的設(shè)計(jì)是將 store 先分模塊，模塊下在包含 state，mutation，action。

那么按照正常理解，訪問 user 模塊下 state 應(yīng)該是這樣的：

this.$store.user.state.uname

但是實(shí)際 API 卻是這樣的：

this.$store.state.user.uname

這個(gè) API 仿佛是在 state 中又各自分了模塊。我沒看過源碼，但從使用體驗(yàn)上來說，這是別扭一。

除 state 外，mutation，action 默認(rèn)注冊(cè)在全局的設(shè)計(jì)，也很別扭。

首先，官方說的多個(gè)模塊對(duì)同一 mutation 或 action 作出響應(yīng)，這個(gè)功能暫無找到應(yīng)用場(chǎng)景。并且未配 namespace 時(shí)還要保證命名唯一，否則會(huì)導(dǎo)致誤觸發(fā)。

其次，用 namespace 后，觸發(fā) mutation 是這樣的：

this.$store.commit('user/setName')

這個(gè)明顯是將參數(shù)單獨(dú)處理了，為什么不是這樣：

this.$store.user.commit('setName')

總體感受就是 Vuex 模塊化做的還不夠徹底。

為什么吐槽

上面說的槽點(diǎn)，并不是為了吐槽而吐槽。主要是感覺還有優(yōu)化空間。

比如 this.$store.commit 函數(shù)可以觸發(fā)任何 mutation 來更改狀態(tài)。如果一個(gè)組件復(fù)雜，需要操作多個(gè)子模塊的狀態(tài)，那么就很難快速的找出當(dāng)前組件操作了哪些子模塊，當(dāng)然也不好做權(quán)限規(guī)定。

我希望的是，比如在 A 組件要用到 b, c 兩個(gè)子模塊的狀態(tài)，不允許操作其他子模塊，那么就可以先將要用到模塊導(dǎo)入，比如這樣寫：

import { a, b } from this.$store
export default {
  methods: {
    test() {
      alert(a.state.uname) // 訪問狀態(tài)
      a.commit('setName')// 修改狀態(tài)
    }
  }
}

這樣按照模塊導(dǎo)入，查詢和使用都比較清晰。

到此，相信大家對(duì)“Vuex store怎么創(chuàng)建”有了更深的了解，不妨來實(shí)際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！