先說兩句
官方已經有教程了，為什么還要寫這個教程呢？說實話，還真不是我閑著蛋疼，官方的教程真的是太官方了，對于剛入門 Vuex 的童鞋來說，想必看官方的教程，很多地方就如同看圣經一樣，比如「歐瑪尼瑪尼牙」，所有的字都認識，就是不知道說些什么玩意，不信，你可以戳進去看看，
當然，對于大神級別一看就懂的，那就不用說了，肯定是看官方的更權威，還有，如果對 Flux、Redux、The Elm Architecture 比較熟悉的話，也可以移步官方，因為官方也說了，Vuex 的套路基本上都是從那邊吸取整合后，過渡而來的，只不過，Vuex 只鐘情于 Vue.js 罷了，
我之所以寫這個教程，主要是因為自己剛剛開始和 Vuex 打交道的時候，痛過了、苦過了、傷過了，所以痛定思痛，為了能讓自己更好的駕馭 Vuex，也為了不讓新來的童鞋們被 Vuex 調戲過后無處訴苦，所以方才決定把官方的這些抽象的文字和概念，用連你身后的鼓勵師小姐姐都能看懂的語言，分享出來，助你在前端的道路上越走越順，順利的找到一份有鼓勵師陪伴的作業，
再說一句
Vuex 是 Vue.js 的座駕，所以，如果還不懂Vue.js 的話，那還是先把 Vue.js 勾搭上了再帶過來一起坐坐吧，當然，既然能夠溜達到這里，想必跟 Vue.js 起碼也已經是朋友了吧，
有點啰嗦，不要嫌棄，寫教程也需要有點前戲，畢竟是第一次，
安裝
關于 Vuex 的具體安裝，就不在這里說了，這個官方還是比較清晰的，戳此進入，但是需要注意兩點：
-
在一個模塊化的打包系統中，您必須顯式地通過 Vue.use() 來安裝 Vuex，比如：
import Vue from 'vue' import Vuex from 'vuex' Vue.use(Vuex) // 必須呼叫此函式來注入 Vuex -
當使用全域 script 標簽參考 Vuex 時，就不用那么麻煩了，直接參考進來就好，但要注意參考的先后順序，如下：
// 在 Vue 之后引入 vuex 會進行自動安裝 <script src="https://www.cnblogs.com/path/to/vue.js"></script> <script src="https://www.cnblogs.com/path/to/vuex.js"></script>
雖然 script 的方式看起來比較自動化，但是接觸得多了，你就會明白模塊化其實才是我們的最佳姿勢，
揭開 Vuex 的神秘面紗
拿到一個工具，我們第一時間需要弄明白的，就是這個工具到底能夠幫助我們解決什么問題，比如錘子，砸得了雞蛋打得了電話，比如蘋果，不但能吃還能玩，那么 Vuex 呢，如果把 Vue.js 比喻成路人（走路的人）的話，那么 Vuex 就是他的桑塔納，如果他想去隔壁買包煙，那走過去就行了，開個車過去反而是一種負擔，但是如果他想去幾十公里的學校采花，那桑塔納就得派上用場了，不然等他走過去，可能花兒都謝了，
當然，類比只是為了告訴我們 Vuex 的價值所在，那么在具體在實際的應用中，它能干什么？什么時候才需要翻它的牌呢？
我們先來看一段官方代碼：
new Vue({
// state 資料源
data () {
return {
count: 0
}
},
// view 視圖
template: `
<div>{{ count }}</div>
`,
// actions 事件
methods: {
increment () {
this.count++
}
}
})
這是一個很簡單的增長型計數功能頁面，和 Vue.js 有一腿的，應該秒懂，通過事件 increment，實作 count 增長，然后渲染到界面上去，
這種方式其實就跟走路買煙一樣，屬于短途效應，官方稱作為「單向資料流」，很好理解，
但是，情況變了，現在有兩個頁面 A 和 B，還有以下兩個要求：
- 要求它們都能對 count 進行操控，
- 要求 A 修改了 count 后，B 要第一時間知道，B 修改后，A 也要第一時間知道，
怎么辦？稍微有點開發經驗的，就能夠很容易的想到，把資料源 count 剝離開來，用一個全域變數或者全域單例的模式進行管理，這樣不就在任何頁面都可以很容易的取到這個狀態了，
是啊，這尼瑪就是 Vuex 背后的思想啊，它干的就是這個事情，是不是有一種被 Vuex 這個高大上的名號所坑害的感覺，不就是全域模型嗎，不用它也同樣可能搞定嘛，
是的，也可以搞定，就像沒有桑塔納，你也可以去學校看花一樣，只是經歷的程序不一樣了，
Vuex 的目的是為了管理共享狀態，為了達到這個目的，它制定了一系列的規則，比如修改資料源 state、觸發 actions 等等，都需要遵循它的規則，以此來達到讓專案結構更加清晰且易于維護的目的，
那么我們再來看看官方的描述：
Vuex 是一個專為 Vue.js 應用程式開發的狀態管理模式，它采用集中式存盤管理應用的所有組件的狀態，并以相應的規則保證狀態以一種可預測的方式發生變化，
有沒有瞬間清晰多了，
什么時候翻 Vuex 的牌
其實了解了 Vuex 要干的活以后，什么時候翻牌，那就容易選擇得多了，就像前面的類比一樣，去隔壁買包煙，你還開個桑塔納，找停車位的時間，煙都抽完了，
所以，我們要根據專案的需要，來衡量短期和長期的效益，如果不打算開發大型的單頁應用，那 Vuex 可能還是你的一個負擔，對于一些不大不小的專案，自己又懶得走，開車又覺得麻煩，那你騎個共享單車過去也行嘛，
這里的共享單車指代的是官方中的一個簡單的 store 模式，其實就是一個單純的全域物件，
關于全域物件和 Vuex 之間的區別，官方寫得還是比較通俗易懂的：
Vuex 和單純的全域物件有以下兩點不同：
- Vuex 的狀態存盤是回應式的，當 Vue 組件從 store 中讀取狀態的時候，若 store 中的狀態發生變化，那么相應的組件也會相應地得到高效更新，
- 你不能直接改變 store 中的狀態，改變 store 中狀態的唯一途徑就是顯式地提交 (commit) mutation，這樣使得我們可以方便地跟蹤每一個狀態的變化，從而讓我們能夠實作一些工具幫助我們更好地了解我們的應用，
簡單示例
// 如果在模塊化構建系統中，請確保在開頭呼叫了 Vue.use(Vuex)
const store = new Vuex.Store({
state: {
count: 0
},
mutations: {
increment (state) {
state.count++
}
}
})
每一個 Vuex 應用的核心就是 store（倉庫），store 基本上就是一個容器，它包含著你的應用中大部分的狀態 (state)，
注意：如果 mutations 不知道是什么，沒關系，后面會專門講解到，可以單純的理解為只能用它里面的方法來修改 state 中的資料，
store.commit('increment') // 呼叫 mutations 中的方法
console.log(store.state.count) // -> 1
為什么要這樣設計的，官方也給出了具體的原因：
我們通過提交 mutation 的方式，而非直接改變 store.state.count，是因為我們想要更明確地追蹤到狀態的變化，這個簡單的約定能夠讓你的意圖更加明顯，這樣你在閱讀代碼的時候能更容易地解讀應用內部的狀態改變，此外，這樣也讓我們有機會去實作一些能記錄每次狀態改變，保存狀態快照的除錯工具，有了它，我們甚至可以實作如時間穿梭般的除錯體驗，
由于 store 中的狀態是回應式的，在組件中呼叫 store 中的狀態簡單到僅需要在計算屬性中回傳即可，觸發變化也僅僅是在組件的 methods 中提交 mutation，
如果最后一句話沒看懂，沒關系，下一章馬上就會講到，
PS
來點正經的，到這里，第一篇其實就已經寫完了，當然，這里的內容都是我看了官方的教程后，自己的一個理解，如果有理解不到位的地方，歡迎拍磚，
轉載宣告：
作者：大宏說
原文鏈接: https://www.jianshu.com/p/120eaf50331c
后記
以上就是胡哥今天給大家分享的內容，喜歡的小伙伴記得點贊、收藏呦，關注胡哥有話說，學習前端不迷路，歡迎多多留言交流...
胡哥有話說，一個有技術，有情懷的胡哥！現任京東前端攻城獅一枚，
胡哥有話說，專注于大前端技術領域，分享前端系統架構，框架實作原理，最新最高效的技術實踐！
轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/118304.html
標籤：JavaScript