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 或许是个选择，若是你只是从头开始开发一个小程序，原生开发也何尝不可。说到底，一系列小程序框架的出现无非是原生开发体验太差，可是我相信，以微信的能力，假以时日可以把小程序原生开发的体验作好。