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