杂乱无章

当前位置:首页 > 技术世界 > 杂乱无章

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

转载说明:欢迎转载本站所有文章,如需转载请注明来源于《绝客部落》。

本文链接:https://juehackr.net/zawen/129.html

相关内容

文章评论

表情

共 0 条评论
  • 这篇文章还没有收到评论,赶紧来抢沙发吧~