mpvue 初體驗之改寫【車標速查】

前文 說到我開發了一個簡單的小程序叫作 車標速查（代碼以及二維碼詳見 這裏），本文簡單講講如何將這個小程序轉爲 mpvue 開發（最終 成果 ）

mpvue 官網的 文檔 真的是很是簡單，不，應該說是簡潔，由於依託 Vue，因此不少語法不須要贅述，直接去看 Vue 的文檔就行了。mpvue 這個名字真的是不忍吐槽，起名也太不上心了吧 ... 反正我我的以爲很差聽

mpvue 的入門很是簡單，能夠看這個 quickstart。生成的模版目錄結構和 Vue 開發很像，可是有區別，爲了使之構建出符合小程序項目結構的代碼格式： json/wxml/wxss/js 文件。src 是開發目錄，dist 是最後 build 的目錄，也就是小程序的代碼

簡單看一下 src 的代碼結構：

├── App.vue
├── data
│   └── data.js
├── main.js
├── pages
│   ├── about
│   │   ├── index.vue
│   │   └── main.js
│   ├── detail
│   │   ├── index.vue
│   │   └── main.js
│   └── index
│       ├── index.vue
│       └── main.js
└── utils
    └── index.js

App.vue 最後會被編譯成 app.js/app.wxss，一些全局相關的樣式和鉤子函數會被放在這裏（好比說 onLaunch，可是在 mpvue 裏咱們能夠用 created 代替）。main.js 會被編譯成 app.json，一些全局相關的配置放在這裏（好比頁面入口，tabbars 等）

pages 目錄即爲每一個頁面，以 index 目錄爲例，index.vue 會被編譯成 main.js/main.wxml/main.wxss，而 main.js 能夠放置針對單個頁面的配置，最後會被編譯成 main.json（若是沒有填入配置項，則不會生成該文件）

而後來簡單過下開發過程當中踩的一些坑：

• pages 目錄下新增入口，須要從新 npm start 啓動，由於新建了 webpack 的 entry
• 關於 navigator。index 頁面點擊圖標須要去詳情頁，這就有了導航需求。小程序有原生的 navigator 組件，如今用 mpvue 開發，那麼能不能用 Vue-Router 呢？答案是並不能夠，參考 這個 faq。因此最後仍是用了小程序原生的 navigator 組件
• detail 頁面的 onLoad 鉤子會有一個 options 參數，若是在這個頁面用 created，是獲取不到的，能夠看下 mpvue 的 生命週期。由於 mpvue 不建議使用小程序的生命週期鉤子，因此比較好的方式是在 mounted 的時候用 this.$root.$mp.query 去獲取 options
• .vue 文件須要加上 style／script 標籤後才能被正確編譯，這點不難理解，script 裏的內容被編譯成 js 文件，而 style 裏的內容被編譯成 wxss 文件，一個小程序的頁面須要它們支撐
• filters 仍是不能用
• 關於富文本。看了下 v-html 指令是能夠用的，可是是被編譯成 rich-text 組件，並不符合個人要求，最後用的是 mpvue-wxParse，仍是不錯的，跟 wxParse 功能基本同樣
• 關於 scroll-view。由於有個側邊導航點擊跳轉的功能，仍是用了 scroll-view 去實現，並無更好的辦法
• {{}} 中小程序原生不支持的語法，mpvue 一樣沒法支持，好比一些複雜的計算，好比函數等
• 全部頁面裏面的 created 生命週期函數都會在小程序加載的時候， 一次性執行，而不是每進入一個頁面執行一次（能夠用 mounted 或者 onLoad 或者 onReady 代替）

總的來講，我從入門 mpvue 到用其改寫這個小程序，也就不過一天時間，因而可知 mpvue 上手真的很是快，可是它給個人整體感受是有點雞肋，一方面多是我這個項目有點簡單（不須要用到 Vuex 以及組件化），另外一方面可能還不是很瞭解 mpvue

官網歸納的它的主要能力：

• 完全的組件化開發能力：提升代碼複用性
• 完整的 Vue.js 開發體驗
• 方便的 Vuex 數據管理方案：方便構建複雜應用
• 快捷的 webpack 構建機制：自定義構建策略、開發階段 hotReload
• 支持使用 npm 外部依賴
• 使用 Vue.js 命令行工具 vue-cli 快速初始化項目
• H5 代碼轉換編譯成小程序目標代碼的能力

我以爲目前主要的亮點在於 Vuex 的可引入以及組件化開發，可是愈來愈以爲隨着原生小程序開發的改善，這些功能都會被補充進去。因此，最大的賣點可能仍是在於 多端統一

我以爲有點雞肋的另外一個重要緣由是，使用 mpvue 開發並不能徹底忽略小程序的 API 或者組件，好比這個小程序，仍是要用 navigator 組件以及 scroll-view 組件去實現一些功能（固然隨着 mpvue 生態的發展，徹底有可能出現 navigator／scroll-view 的 mpvue 組件，可是這樣造輪子是否值得？），並且可能還有其餘一些 API。而類比 jQuery 和 js，jQuery 徹底不用去考慮原生的 dom 操做方式，從而更加 「傻瓜式」。mpvue 的開發模式註定不會是這樣的結局（由於並非從小程序底層去開發）

另一點，用 mpvue 開發，增長了一層 vue->小程序 編譯環節，因此 reload 的速度應該會比原生開發慢一點

魯小夫 在 如何看待美團開源的 mpvue ? 這個問題下的答案很是值得思考：

不過咱們也該思考一下，爲何你們對微信小程序自帶的機制有這麼多意見，爲何你們對 vue 這麼認同，爲何多端兼容這個事情這麼重要，爲何微信小程序沒有擁抱開源，爲何微信小程序的技術棧沒能作到標準化通用化。爲了兼容微信小程序，前端工程師作了這麼多工做，弄了那麼多框架，到底獲得的是什麼。

之前看到過一句話，大概意思是，微信小程序有太多滿分的開源框架能夠借鑑，最後卻造了個負分的輪子。

all in all，個人見解是，若是你恰好熟悉 Vue 或者須要多端統一開發，那麼 mpvue 或許是個選擇，若是你只是從頭開始開發一個小程序，原生開發也何嘗不可。說到底，一系列小程序框架的出現無非是原生開發體驗太差，可是我相信，以微信的能力，假以時日可以把小程序原生開發的體驗作好。