以 Vuex 爲引，一窺狀態管理全貌

作者：楊成功

簡介：專注前端工程與架構產出

來源：SegmentFault 思否社區

衆所周知，Vuex 是 Vue 官方的狀態管理方案。

Vuex 的用法和 API 不難，官網介紹也簡潔明瞭。得益於此，將 Vuex 快速集成到項目裏非常容易。然而正因爲用法靈活，很多同學在 Vuex 的設計和使用上反而有些混亂。

其實在使用前，我們不妨暫停一下，思考幾個問題：

什麼是狀態管理？
我爲什麼要用 Vuex？
組件內部狀態和 Vuex 狀態如何分配？
使用 Vuex 會有哪些潛在問題？

如果你對這些問題模棱兩可，那麼恭喜你，這篇文章可能是你需要的。

下面請和我一起，從起源開始，以 Vuex 爲例，共同揭開狀態管理的神祕面紗。

大綱預覽

本文介紹的內容包括以下方面：

狀態與組件的誕生
需要狀態管理嗎？
單一數據源
狀態更新方式
異步更新？
狀態模塊化
模塊化的槽點
下一步

狀態與組件的誕生

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

數據驅動視圖
組件化

數據驅動視圖，使我們告別了只能依靠操作 DOM 更新頁面的時代。我們不再需要每次更新頁面時，通過層層 find 找到 DOM 然後修改它的屬性和內容，可以通過操作數據來實現這些事情。

當然了在我們前端的眼裏，數據基本可以理解爲存儲各種數據類型的變量。在數據驅動這個概念出現之後，一部分變量也被賦予了特殊的含義。

首先是普通變量，和 JQ 時代沒差，僅用來存儲數據。除此之外還有一類變量，它們有響應式的作用，這些變量與視圖綁定，當變量改變時，綁定了這些變量的視圖也會觸發對應的更新，這類變量我稱之爲狀態變量。

所謂數據驅動視圖，嚴格說就是狀態變量在驅動視圖。隨着 Vue，React 的大力普及之下，前端開發們的工作重心逐漸從操作 DOM 轉移到了操作數據，狀態變量成爲了核心。

狀態變量，現在大家似乎更願意稱之爲狀態。我們經常詞不離口的狀態，狀態管理，其實這個狀態就是指狀態變量。下文提到的狀態同樣也是指狀態變量。

有了狀態之後，組件也來了。

JQ 時代的前端一個頁面就是一個 html，沒有 “組件” 的概念，對於頁面中的公共部分，想要優雅的實現複用簡直不要太難。所幸三大框架帶來了非常成熟的組件設計，可以很容易的抽取一個 DOM 片段作爲組件，而且組件內部可以維護自己的狀態，獨立性更高。

組件的一個重要特性，就是內部的這些狀態是對外隔離的。父組件無法訪問到子組件內部的狀態，但是子組件可以訪問父組件顯示傳過來的狀態（Props），並且根據變化自動響應。

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

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

但是如果你的頁面複雜，你會發現還是有力不從心的地方。比如：

組件層級太深，需要共享狀態，此時狀態要層層傳遞。
子組件更新一個狀態，可能有多個父組件，兄弟組件共用，實現困難。

這種情況下繼續使用 “提取狀態到父組件” 的方法你會發現很複雜。而且隨着組件增多，嵌套層級加深，這個複雜度也越來越高。因爲關聯的狀態多，傳遞複雜，很容易出現像某個組件莫名其妙的更新，某個組件死活不更新這樣的問題，異常排查也會困難重重。

鑑於此，我們需要一個更優雅到方案，專門去處理這種複雜狀況下的狀態。

需要狀態管理嗎？

上一節我們說到，隨着頁面的複雜，我們在跨組件共享狀態的實現上遇到了棘手的問題。

那麼有沒有解決方案呢？當然有的，得益於社區大佬們的努力，方案還不止一個。但是這些方案都有一個共同的名字，就是我們在兩年前討論非常激烈的 ———** 狀態管理**。

狀態管理，其實可以理解爲全局狀態管理，這裏的狀態不同於組件內部的狀態，它是獨立於組件單獨維護的，然後再通過某種方式與需要該狀態的組件關聯起來。

狀態管理各有各的實現方案。Vue 有 Vuex，React 有 Redux，Mobx，當然還有其他方案。但是它們解決的都是一個問題，就是跨組件狀態共享的問題。

我記得前兩年因爲 “狀態管理” 這個概念的火熱，好像成了應用開發不可或缺的一部分。以 Vue 爲例，創建一個項目必然會引入 Vuex 做狀態管理。但是很多人不知道爲什麼用，什麼時候用，怎麼用狀態管理，只是盲目跟風，於是後來出現了非常多濫用狀態管理的例子。

看到這裏，你應該知道狀態管理不是必須的。它爲什麼出現，以及它要解決什麼問題，上面基本都說明白了。如果你還沒明白，請暫停，從開頭再讀一遍。不要覺得一個技術方案誕生的背景不重要，如果你不明白它的出現是爲了解決什麼問題，那麼你就無法真正發揮它的作用。

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

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

Vuex

Vue 在國內的應用非常廣泛，尤其是中小團隊，因此大多人接觸到的第一個狀態管理方案應該就是 Vuex。

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

創建 store

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

也許你會問：這樣做不是把狀態暴露到全局了嗎？不就徹底消除模塊化的優勢了嗎？

其實不然。Vuex 這麼做的主要目的是爲了讓所有組件都可以訪問到這些狀態，徹底避免子組件狀態訪問不了的情況。Vuex 把所有狀態數據都放在一個對象上，遵循單一數據源的原則。但是這並不代表狀態是堆砌的，Vuex 在這顆單一狀態樹上實現了自己的模塊化方案。

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

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

$ npm install --save vuex

安裝之後，我們新建 src/store 文件夾，在這裏放所有 Vuex 相關的代碼。

新建 index.js 並寫入如下代碼。這段代碼主要的作用就是用 Vue.use 方法加載 Vuex 這個插件，然後將配置好的 Vuex.Store 實例導出。

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

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

上面導出的實例我們通常稱之爲 store。一個 store 中包含了存儲的狀態（state）和修改狀態的函數（mutation）等，所有狀態和相關操作都在這裏定義。

最後一步，在入口文件將上面導出的 store 實例掛載到 Vue 上：

import store from './store'

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

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

單一數據源（state）

上一步我們用構造函數 Vuex.Store 創建了 store 實例，大家至少知道該怎麼用 Vuex 了。這一步我們來看看 Vuex.Store 構造函數的具體配置。

首先是 state 配置，他的值是一個對象，用來存儲狀態。Vuex 使用單一狀態樹原則，將所有的狀態都放在這個對象上，便於後續的狀態定位和調試。

比如說我們有一個初始狀態 app_version 表示版本，如下：

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

現在要在組件中獲取，可以這樣：

this.$store.state.app_version

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

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

爲什麼要強調這一點呢？因爲很多小夥伴以爲 Vuex 只能通過 this.$store 操作。到了非組件內，比如在請求函數中要設置某一個 Vuex 的狀態，就不知道該怎麼辦了。

事實上組件中獲取狀態還有更優雅的方法，比如 mapState 函數，它讓獲取多狀態變得更簡單。

import { mapState } from 'vuex'

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

狀態更新方式（mutation）

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

Mutation 是一個函數，第一個參數爲 state，它的作用就是更改 state 的狀態。

下面定義一個名叫** increment **的 mutation，在函數內更新 **count** 這個狀態：

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

然後在 .vue 組件中觸發** increment**：

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

這樣綁定了 count 的視圖就會自動更新。

同步更新

雖然 mutation 是更新狀態的唯一方式，但實際上它還有一個限制：必須是同步更新。

爲什麼必須是同步更新？因爲在開發過程中，我們常常會追蹤狀態的變化。常用的手段就是在瀏覽器控制檯中調試。而在 mutation 中使用異步更新狀態，雖然也會使狀態正常更新，但是會導致開發者工具有時無法追蹤到狀態的變化，調試起來就會很困難。

再有 Vuex 給 mutation 的定位就是更改狀態，只是更改狀態，別的不要參與。所謂專人幹專事兒，這樣也幫助我們避免把更改狀態和自己的業務邏輯混起來，同時也規範了函數功能。

那如果確實需要異步更新，該怎麼辦呢？

異步更新

異步更新狀態是一個非常常見的場景，比如接口請求回來的數據要存儲，那就是異步更新。

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

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

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')
        }
      })
    }
  }
})

在組件中觸發 action：

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

這些就是 action 的使用方法。其實 action 最主要的作用就是請求接口，拿到需要的數據，然後觸發 mutation 修改狀態。

其實這一步在組件中也可以實現。我看過一些方案，常見的是在組件內寫一個請求方法，當請求成功，直接通過 this.$store.commit 方法觸發 mutation 來更新狀態，完全用不到 action。

難道 action 可有可無嗎？

也不是，在特定場景下確實需要 action 的，這個會在下一篇說。

狀態模塊化（module）

前面講過，Vuex 是單一狀態樹，所有狀態存放在一個對象上。同時 Vuex 有自己的模塊化方案，可以避免狀態堆砌到一起，變的臃腫。

Vuex 允許我們將 store 分割成模塊（module），每個模塊擁有自己的 state、mutation、action。雖然狀態註冊在根組件，但是支持模塊分割，相當於做到了與頁面組件平級的 “狀態組件”。

爲了區分，我們將被分割的模塊稱爲子模塊，暴露在全局的稱爲全局模塊。

我們來看基礎用法：

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

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

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

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

action 與 mutation 原理一致，不細說。

命名空間

上面說到，子模塊觸發 mutation 和 action 與全局模塊一致，那麼假設全局模塊和子模塊中都有一個名爲 setName 的 mutation。在組件中觸發，哪個 mutation 會執行呢？

經過試驗，都會執行。官方的說法是：爲了多個模塊能夠對同一 mutation 或 action 作出響應。

其實官方做的這個兼容，我一直沒遇到實際的應用場景，反而因爲同名 mutation 導致誤觸發帶來了不少的麻煩。可能官方也意識到了這個問題，索引後來也爲 mutation 和 action 做了模塊處理方案。

這個方案，就是命名空間。

命名空間也很簡單，在子模塊中加一個 namespaced: true 的配置即可開啓，如：

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

開啓命名空間後，觸發 mutation 就變成了：

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

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

模塊化的槽點

上面我們介紹了 Vuex 的模塊化方案，將單一狀態樹 store 分割成多個 module，各自負責本模塊狀態的存儲和更新。

模塊化是必要的，但是這個模塊的方案，用起來總覺得有點彆扭。

比如，總體的設計是將 store 先分模塊，模塊下在包含 state，mutation，action。

那麼按照正常理解，訪問 user 模塊下 state 應該是這樣的：

this.$store.user.state.uname

但是實際 API 卻是這樣的：

this.$store.state.user.uname

這個 API 彷彿是在 state 中又各自分了模塊。我沒看過源碼，但從使用體驗上來說，這是彆扭一。

除 state 外，mutation，action 默認註冊在全局的設計，也很彆扭。

首先，官方說的多個模塊對同一 mutation 或 action 作出響應，這個功能暫無找到應用場景。並且未配 namespace 時還要保證命名唯一，否則會導致誤觸發。

其次，用 namespace 後，觸發 mutation 是這樣的：

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

這個明顯是將參數單獨處理了，爲什麼不是這樣：

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

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

爲什麼吐槽

上面說的槽點，並不是爲了吐槽而吐槽。主要是感覺還有優化空間。

比如 this.$store.commit 函數可以觸發任何 mutation 來更改狀態。如果一個組件複雜，需要操作多個子模塊的狀態，那麼就很難快速的找出當前組件操作了哪些子模塊，當然也不好做權限規定。

我希望的是，比如在 A 組件要用到 b, c 兩個子模塊的狀態，不允許操作其他子模塊，那麼就可以先將要用到模塊導入，比如這樣寫：

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

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

下一步

前面我們詳細介紹了狀態管理的背景以及 Vuex 的使用，分享了關於官方 API 的思考。相信看到這裏，你已經對狀態管理和 Vuex 有了更深刻的認識和理解。

然而本篇我們只介紹了 Vuex 這一個方案，狀態管理的其他方案，以及上面我們的吐槽點，能不能找到更優的實現方法，這些都等着我們去嘗試。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/74PGR0ZUYLLbPcVw2efzrA