Vue實戰狗尾草博客後臺管理系統第七章

 

Vue實戰狗尾草博客後臺管理平臺第七章

本章內容爲藉助模塊化來闡述Vuex的進階使用。

在複雜項目的架構中，對於數據的處理是一個很是頭疼的問題。處理不當，不只對維護增長至關的工做負擔，也給開發增長巨大的壓力。

在大量的實戰開發過程當中，狗尾草總結出來的較爲友好的方式是 使用一個單獨的數據管理庫去管理數據。

這樣不會給頁面增長額外的負擔。且API的調用也屬於數據處理/獲取的部分。所以也放在數據管理下統一管理

注：本章節內容與狗尾草博客管理平臺沒有任何關係，僅做爲Vuex的進階使用來分享

對模塊化的簡單闡述

在開始時，咱們須要先對模塊對有一個清晰的定義！

這裏不扯AMD與CMD規範。

簡單論述爲：對於複雜系統的開發。製做清晰的分界。廣義上講就是將一湖的水進行"渠道化分流"。可是微觀上確實有很是多的東西，且能夠根據具體的項目進行具體的場景分析從而進行設計。

上面所說也能夠理解爲模塊的理解或者使用場景。

如何實現

在平時的開發中，咱們能夠對什麼進行模塊化？

咱們須要一個目標，這個目標做爲系統來理解。那咱們就必須知道的是，咱們的系統有哪些功能與業務。必須有一個清晰的四位導圖來支撐。

就日常的系統來說。所必需的的有不一樣功能的業務。這些業務在是實現的過程當中，又分爲：view，style，js。這些又能夠進行劃分爲：組件的抽離,樣式的抽離,工具類的抽離,靜態資源的抽離。再次基礎上一個頁面就已經能夠呈現到屏幕上了。可是他仍是靜態的，仍是由咱們Mock數據所支撐。並沒有鮮活數據的支撐。此時。咱們就能夠對數據進行抽離。

爲何要作模塊化抽離？或者說這樣作有什麼好處呢？

簡單說模塊化意義就在於數據的可視化,便捷的管理,數據的挖掘,系統的維護,系統更爲清晰的架構。固然其真實的意義與優點只有在具體的開發並實踐後纔有所呈現。且會根據不一樣系統呈現不一樣結果。你永遠不會知道這麼作會給你帶來什麼Surprise！

補充：讓開發者對系統有更好的可控性，或許這也是模塊化的意義之一。

API抽離

請求接口抽離，做爲單獨模塊進行統一的管理，對於後端接口的服務，在前端也會有更好的結構認識。同時在使用時也會更加便捷。

eg：

commons下能夠放置咱們共用的一些api模塊

modules則能夠對api再次進行模塊化劃分。

好比後端的接口服務有a服務，b服務，c服務。name咱們也就能夠按照a服務，b服務，c服務進行劃分。

可是這裏狗尾草不建議這樣來配置。由於後端所用服務並不定是咱們須要的。其命名也常常是一些生僻的單詞，嚐嚐會令新加入的developer感到無力。

這裏狗尾草提出的一個合理化的解決方案即是根據前端的項目的業務來劃分或者前端的服務來劃分。好比說用戶服務(登陸，註冊，修改，忘記密碼，權限，我的信息等)，文章服務(標題，內容，更改，刪除，草稿等等)。

固然這裏提出的合理化的解決方案不只如此，咱們也須要在項目的README.md的文件中對api模塊的劃分作出合理的解釋。這樣對於新加入項目的同事也不會有太大的困惑。

base.js的話咱們則能夠進行域名的配置。根據項目不一樣的環境進行動態的配置。開發環境的域名，測試環境的域名。預發佈環境的域名，生產環境的域名等等。這裏又能夠經過不一樣的啓動命令來動態配置。(這裏的配置由於每一個腳手架所建立項目各有所異。所以暫不作詳情說明)

api的配置結束，咱們就須要一個出口文件，供其餘模塊進行調用。index.js則是一個很好的出口。

import serverA from './modules/serverA';
import serverB from './modules/serverB';
export default {
  serverA,
  serverB
}

這樣一個api模塊，咱們就簡單的抽離了出來。剩下的至於在項目中怎麼使用，咱們就不須要過多操心。可是好的方式的掛在global下，供全局的更爲便捷的使用。

例如在Vue中，咱們即可以經過install到Vue.prototype上來實現

import api from '@/api';
const install = (Vue,opts = {}) {
  if (install.installed) return;
  Vue.prototype.$api = api;
}
export default install;

main.js

import Utils from './utils';
Vue.use(Utils);

this.$api.模塊.具體的api接口 用此方式即可更爲方便的對api進行使用。固然有一個缺點是過多的東西掛載在原型鏈上。Vue的性能則會受到影響，可是相較於系統中頻繁操做的api來言。卻能夠省略了。

固然API的抽離也僅僅是繁多模塊化開發中的一個。

Pages抽離

Pages抽離其實並沒有特殊的意義，理解成本意就好。頁面的抽離

這裏的頁面的抽離，咱們則不能經過功能來進行拆分了，咱們須要根據業務來走啦。

給你們一個最直觀的理解：你們能夠看看管理系統的菜單欄部分。一級菜單，二級菜單等等。你們的業務的流程即可以根據這些來走。

每一個一級菜單做爲一個大的pages來抽離

頁面的設計架構咱們即可以如此進行：

pages

pages1

components

data

router.js

static

pages2

components

data

router.js

static

簡單闡述就是多個大型的業務模塊。具體拆分爲多個頁面模塊，此多個頁面模塊的路由在此業務下統一管理，常量資源，業務的Private Component,數據的管理也都在此模塊下作統一處理。

其意義直觀上來看，多個業務之間並無任何的耦合。並不會形成業務邏輯樣式等得污染。

Router抽離

建立主路由並建立攔截，以攔截作出路由的主出口。

在此基礎上對各個業務模塊進行單獨的路由拆分，以達到模塊抽離的各個方面，並將模塊使用到其餘項目中，也依然可使用。

eg:

Router/index.js主路由

import Vue from 'vue';
import Router from 'vue-router';
import { Route as RouterA } from '@/pages/xxx';
import { Route as RouterB } from '@/pages/xxx';
Vue.use(Router);
export const constantRouterMap = [
 路由的配置
  ...RouterA,
  ...RouterB,
]

模塊化中的路由拆分，咱們則能夠認爲模塊化中的路由爲此模塊的入口

eg: 某模塊的入口

Modeal/index.js

export const Route = [
  {
    xxx：xxx路由配置
  }
]

入口已配置，剩下的就在上述的代碼中操做加入總的路由中，在後續路由的更改時，只須要在相應的模塊中修改便可。減小了很大程度上的耦合。

基本的模塊的開發就如上述那樣，循規蹈矩，卻又加入項目場景，通過深思熟慮作出合理魔窟阿化！

下來也就是本章的另外一個重點。Vuex的進階使用。

數據的統一管理之Vuex的進階使用

基礎的東西很少作解釋，大佬們都懂得。Vuex爲Vue提供了很好的數據管理方式。

Vuex is a state management pattern + library for Vue.js applications.

在使用以前，咱們必須先思考，咱們用它能夠幹什麼？

簡單舉例來講明：

若是沒有這樣的一個數據的管理庫，那麼咱們在開發時，不可避免的要經歷這樣的過程。n多頁面之間共享數據，或組件間數據的傳遞。a傳b，b傳c，c傳d，甚至會更加複雜。

從數據管理的第三方庫出來後，咱們便不須要這種的方式進行數據的傳輸。

Vue中的Vuex，React中的Redux。

Vuex的簡單的流程

State： 數據的存儲

Getters：state中數據的過濾，更便捷的獲取

Mutations： state中數據的操做

Actions：異步請求的操做，能夠理解爲數據的init

modules：狀態庫的模塊化管理

使用的流程串起來簡單說就是 view 讀取state數據並進行render。交互操做時，經過mutations對state數據進行更新。頁面初始化派發action請求獲取初始化數據。

多個頁面之間須要共享數據時，只須要從store中取值就好。

當項目複雜程度較小時，咱們能夠在根目錄下經過store/modules的結構來拆分狀態庫，經過index.js來提供主出口便可。

前幾篇文章中使用到的store的使用就是如此。

可是當項目複雜度提高時，咱們就必須設計插拔式管理。

import Vue from 'vue';
import Vuex from 'vuex';
import storeA from '@pages/xxx/store';
Vue.use(Vuex);
export default new Vuex.Store({
  xxx,
  xxx,
  xxx,
  xxx,
  modules: {
    ...storeA
  }
})

將store的管理也進行拆分管理。對組件化，模塊化更深層次的配置。使各個模塊在互相不依賴的狀況下，也依舊不影響使用。低耦合，高複用！

若是須要對store作一個總結的話，那就是每一個Pages模塊擁有本身的狀態管理庫，本身的常量配置，本身的私有組件，在任何狀況下，每一個模塊都能獨立運行。無疑是對高複用，低耦合的很好的實現.

具體使用場景以下：

eg:

import { mapGetters,mapActions, mapMutations } from 'vuex';  
computed: {
  ...mapGetters('模塊名',['state1','state2'])
},// state的映射，在不一樣模塊中，取出不一樣的模塊下的數據
...mapActions('模塊名',['request1','request2']),//映射出相關模塊下對應的異步請求，並在須要的時候派發出去。
...mapMutations('模塊名',['stateopt1','stateopt2']);//對state的操做也能夠在頁面中進行。可是通常不建議在頁面中對state進行操做。