mpvue 在前端項目的應用設計

前端開發，在有些朋友描述中可能就是畫畫界面、獲取界面數據、調接口、顯示數據，而後一直重複着這個過程，就算使用了一些主流框架，也只是更好、更快的畫界面、獲取界面數據、調接口、顯示數據。其實，簡單（初級）的前端也好像真是這樣，要是真這麼理解，那人活着也多沒勁呀，總體就是吃、睡，哈哈哈~

其實自從前端開發宣佈獨立後，「階級矛盾」好像也就變成了業務邏輯的前置仍是後置的矛盾。尤爲是在一些「大前端」的實踐中，固然，我也有幸在其餘地方看到過，整個後端服務就是一個簡單的CRUD服務了。問：後端服務主要作什麼用？答：爲前端開發提供數據庫訪問接口。 哈哈，好像也不是沒有道理，站在安全的角度考慮，我一直建議業務邏輯後置的，前端儘可能迴歸純數據展、交互就行。

0x01 鬼知道我怎麼想的
三個前端項目同步進行開發，那麼必然將會有大部分的工做量是重疊的。相信作開發的朋友應該也都瞭解，前端界面開發、模擬數據交互等工做都是能夠直接人工堆出來了。可是，碰到接口聯調，再附加上業務聯調，多數會由於設計的不完善而形成改改改，在工期上通常會比較耗時。那麼此次就想着將三個項目的接口聯調給統一化。因此，爲了達到統一，首先就須要解決的是微信小程序和web的接口請求了。

這裏不打算詳細介紹微信小程序技術，可是也放張圖(來自網上)出來，先了解一下爲何要達到一統。
微信小程序本質也是一種Hybird App，因而乎熟悉的window、document對象被消失了，固然，也找不到XMLHttpRequest了，還Ajax個鬼。因此，也只能經過官方的wx.request接口來發起網絡請求。咱們的目標是統一化，因此只能代碼對wx.request 和 XMLHttpRequest進行兼容了。這裏順帶推薦一個開源項目Fly.js來做爲HttpClien使用。

Fly.js的設計恰好符合咱們現階段的需求，很好的將API請求邏輯和具體的請求執行(引擎)進行了分離，開發人員只須要調用.get()、.post()等函數發起請求，至因而使用wx.request仍是XMLHttpRequest，就是咱們底層的配置了，與具體業務代碼就沒有半點關聯了，對上層的請求調用邏輯，很好的屏蔽了底層的請求執行。

閒白：在之前的PC時代，曾一直喜歡桌面端工具開發，喜歡作一些小工具給你們玩兒。從C#的純桌面開發到WinFrom + WebKit，再到Silverlight、WPF，微軟一直不放棄的更新，但是總感受一直在學習，從未被應用，哈哈哈，難道是我離坑太遠了？ 一直到如今的Nodejs跨平臺技術，移動端的WebView等跨平臺技術，其實思想多數都是同樣的，只是一直在更新優化。

0x02 猶抱琵琶半遮面
瞭解過微信小程序開發的同窗，應該都比較熟悉setData函數，是的，和其餘框架的setState啥的都是一個做用，都是用來主動觸發渲染引擎的update操做，最終執行效果是會通知框架渲染邏輯進行數據更新展現。

很好的一個函數，但是你見過滿屏幕的setData邏輯麼？哈哈，我有看到過。setData的濫用確實比較嚴重，一大段邏輯代碼中，動不動就來一個setData，尤爲是再涉及到數據中key的N層嵌套問題，看着就發燥，是否是很懷念其餘框架中的XXX.key = value方式。

其實否則，就像有這麼一句話：當你感受到輕鬆（方便）的時候，是由於有人在幫你承擔壓力。從編碼方式來看，直接賦值確實簡潔一些，可是相應帶來的倒是框架在一直監聽着你的set操做，從性能上考慮的話，我尚未作過具體的測試，會有多大影響，這個說很差。可我就喜歡直接賦值的方式，哈哈哈，任性。

到不徹底是我的緣由，而是從其餘方面考慮。說了這麼多，這裏爲何要先吐槽微信小程序的setData呢，其實主要緣由是，微信小程序自身目前並無很好的狀態管理容器，多數狀況須要本身去實現簡易的管理，或者直接不使用。因此爲了快速、方便的開發，必需要集成成熟的redux或者vuex來實現狀態管理。

因爲PC版的技術優先肯定了下來，須要使用iview-admin框架來開發，那麼開發人員使用vue來作。那麼，考慮爲了實現微信小程序項目與PC版的一些組件最大限度的複用，WePy仍是mpvue的選擇上也就沒啥爭議了，管他什麼親兒子的，直接就肯定mpvue了，由於都是vue全家桶，哈哈，也要相應的考慮下開發人員的學習成本。

至此，總體的前端技術方案也就明確了下來：

小程序開發：mpvue
PC版開發：iview-admin
狀態管理：vuex
請求框架：Fly.js

接下來，對總體的技術方案進行下介紹。

閒白：叨叨了這麼久纔算進入正題？列位也別嫌我絮叨，在家歇着每天一我的，就話多，哈哈。在之前的C#和Java Swing的開發中，各種組件處理數據展現，尤爲是在多線程的狀況下，UI主線程的控件同步訪問等問題，都是比較煩人的。記得那時有討論提出要將窗體繪製、數據展現、業務數據處理進行分離，應以數據爲主線，數據的變動來驅動界面展現，而不該該是用界面邏輯來驅直接處理數據，應該是業務數據在某一個狀態應該由哪一個界面來展現。記得當時還專門實現了一套基於插件模式開發的框架，將項目的UI模塊做爲一個顯示插件來使用，經過數據綁定來完成渲染展現。如今想來，也算比較符合當前的Flux思想。

從左向右來看

微信小程序基於mpvue開發，PC版使用iview-admin開發，分別來完成界面的開發和數據的交互。vue經過綁定Store中的數據來提供給界面渲染使用。
Store爲Vuex的狀態(數據)管理，經過actions和mutations提供相應的業務邏輯處理。在actions中調用Services的模塊服務來完成API請求。
Services中的模塊服務調用Fly.js來完成API請求執行。

這裏有一個地方在實際應用的時候須要考慮一下，那就是Store和Services的拆分。

其實這裏也有是一些顧慮的，若是拆分兩層的話，在開發工做量上會有所增長，如何合併都到Store中也是能夠的，直接在Store經過HttpClient(fly.js)來請求接口，而後完成響應數據解析處理，也不是不可。最後決定仍是進行拆分，主要是不但願Store中有太多的響應數據解析邏輯，應該更專一業務數據的邏輯處理，這樣也能夠經過在Services層中來模擬數據來進行快速測試，將Services層做爲一個輕薄的數據訪問(協議)層。

具體的示例代碼來一下。

[JavaScript] 純文本查看 複製代碼
?

//Services中的Article模塊
import config from '../config'
import http from '../util/HttpClient'
//導入接口配置
const {

list

} = config.article;
//模塊代碼開始
export default {

//聲明查詢接口
async query(params){
    //POST參數，獲取響應數據
    const {status,content} =await http.post(list, params)
    //過濾掉接口參數，只返回業務數據
    if (http.isOk(status)) {
        return content
    }
    throw http.error(status);
}

}

//Store中對服務調用
import articleService from '../../service/ArticleService'
//Vuex state
const state = {
listData: []
}
//actions聲明
const actions ={

/**
* 查詢列表
*/
async query ({commit, dispatch, state}, {op = 0}){
    //調用服務獲取數據
    const queryResult = await articleService.query(state.query);
    //...
}

}

//vue組件使用
export default {

computed: {
    listData () {
        return this.$store.state.article.listData
    }
}

}

能夠看到，咱們將Store放在了每一個項目中來進行初始化，而後經過Vuex的Module模式，來按照須要的業務模塊能夠進行自由組合。

在小程序A示例代碼中的Store片斷：

i
[JavaScript] 純文本查看 複製代碼
?

mport Vue from 'vue'
import Vuex from 'vuex'
//導入vuex modules
//項目自有模塊，必需要和其餘項目共享
import UserModule from './modules/user'
//公共模塊，可與其餘項目共享
import Activity from 'XXXX/store/modules/activity'
import Article from 'XXXX/store/modules/article'
import EnumModule from 'XXXX/store/enum'
//
Vue.use(Vuex)
//小程序A的Store建立，組合須要的模塊
export default new Vuex.Store({

modules: {
    user: UserModule,
    activity: Activity,
    article: Article,
    enum: EnumModule
}

})

能夠看出，這裏主要分爲三個主項目（上層）和兩個支撐項目（下層）。支持的項目爲公共項目，分別是XXXX-front-api和mp-common，以npm module方式被小程序A、小程序B、Web管理平臺來進行依賴引用。
XXXX-front-api：該項目主要爲業務公共項目，包括共用的Vuex Module、各模塊的Services、Fly.js的封裝以及經常使用的Utils等。
mp-common：該項目主要對微信小程序項目開發，對小程序的API進行封裝，將小程序API的success回調轉換爲Promise方式，用以支持async/await方式。提供共用的小程序組件、樣式、工具類等。

接下來還要介紹下在項目搭建中要注意的問題，nodejs項目的建立這裏就很少說了，具體的npn init或相關框架的腳手架了解下，方便的很。

git中子項目使用

首先，使用git來建立咱們規劃的五個項目，其中有兩個公共模塊項目，因此須要使用git submodule的方式來在主項目中進行管理，結構以下：

[JavaScript] 純文本查看 複製代碼
?

主項目-小程序A

/mp-a.git

/xxx-front-api.git
/mp-common.git

主項目-小程序B

/mp-b.git

/xxx-front-api.git
/mp-common.git

主項目PC版管理

/mc.git

/xxx-front-api.git

nodejs的本地模塊使用

在nodejs項目中，又涉及到公共模塊項目的引用，在java maven中，一般使用mvn install來完成本地模塊的安裝，而在nodejs項目中，主要使用node_modules文件放置依賴，因此咱們能夠經過系統的軟鏈接或者直接使用npm link來完成本地模塊的軟鏈接建立。這樣在三個主項目中任意一個項目中對依賴項目的修改可讓其餘項目達到同步使用。

npm 安裝本地項目

npm link ./mp-common

在nodejs項目中使用模塊

npm install mp-common 或者 yarn add mp-common

項目中就能夠直接使用模塊了

前面主要介紹了小程序選型mpvue、跨平臺的API請求、基於vuex的項目設計，以及項目在搭建過程當中須要注意的地方，此次主要以設計爲主，具體mpvue在開發中的使用與問題，我們且聽下回分解。更多技術資訊可關注：gzitcast