VUX 单页微信开发的那些事

网上已有很多SPA单页做微信开发碰到的那些坑，这里就自己最近经验总结一些我踩过的一些坑，整理记录一下

VUX是微信推出的WeUI的非官方VUE的非官方实现，主要针对移动端微信前端开发，属于个人项目，目前在GitHub已有8k star，使用webpack 2以及扩展了vue-loader，好用是好用，但是和其他前端UI框架一样，只适用一般开发，方便快速，但是如果要配合公司UI设计师设计符合公司的统一UI风格，几乎所有组件都需要定制，这也是没办法的事，别人都做了，要你何用呢，但是亲身试验，的确可以提高部分开发效率，给作者点个赞。

正文开始

1. SPA我就不多做解释了，如果只从表面看，和普通web应用的不同在于url上，最后会增加一个#，其实就代表url路由不经过后端，只在前端渲染，针对微信开发最大的一个坑就在于这儿，微信API都需要对当前url做签名，但是Android和iOS的取值不一致，比如我从/#/list地址进入微信跳转到/#/list/detail地址再到/#/list/detail/2地址，Android能够正确的取到当前地址，但是ios永远取到的是进入的地址也就是/#/list，签名出错那么微信API就废了，针对以上问题，结合网上资料有以下方案目前可用（不代表以后有用）
   • 重写url地址加上?，比如/?#/list，代码

function onHashChange () {
        let paths = window.location.href.split('#')
        paths[1] = paths[1] || '/'

        if (paths[1].charAt(0) === '!') {
            paths[1] = paths[1].substr(1)
        }
        let url = `${paths[0]}#${paths[1]}`
        if (window.location.href !== url) {
            window.location.href = url
        }
}
window.addEventListener('hashchange', onHashChange)
onHashChange()

* 以上情况针对微信分享和微信支付又需要做不同处理，微信分享的签名链接需要是`window.location.href.split('#')[0]`，而支付签名需要是`window.location.href`

• 上面说到微信签名，因为单页应用不经过后台，需要在每次url变化时向后台服务请求签名config，建议hashchange的时候同时异步使用promise获取签名信息，一定要注意promise的用法，很容易写错，而不知道错在哪里

this.$wechat.ready(() => { // 这里的$wechat是vux自动注入到vue的，不得不说简直不要太方便，不然需要做很多对接API的工作
        this.$wechat.onMenuShareTimeline({
              ...
        })
})

同时微信分享的链接不能像以前一样取当前地址，需要统一传入后端再进行redirect，比如/wechat/share?to=' + encodeURIComponent(uri)

1. 微信API的success函数使用() => {}箭头函数，this指向是不到vue组件的，建议提前赋值使用let _this = this
2. 遇到的一个小坑，如果使用cnpm安装会有各种依赖问题，建议使用npm install --registry=https://registry.npm.taobao.org或者yarn
3. 小项目vuex还是不要用了，给自己找不痛快，复杂的还是建议用上吧，全局比如共享的路由信息、用户信息、滚动等会方便不少
4. vue-resource配合vue 2已经不太好用了，建议换成axios
5. 最后，单页应用对于做微信授权个人觉得是最大的坑，因为单页应用一般不经过后端，但是微信授权必须跳转到微信授权地址再返回，但是如果url里有#带参数，回调地址会各种不对，因为微信要提前对url做处理，所以建议统一授权回调方式，还是和上文类似的方案，经过一层重写跳转即可，可以在前端做，比如新建一个oauth.html的静态文件，所有页面先跳转到此页面从后台获取原地址再跳转到想要去的地址，第二种方案是直接回调到后台再经过redirect到前台，无论哪种方案，在用户体验上都会有一种卡卡的感觉，暂时没找到更好的解决方案。

暂时只想到这几个，微信API文档真不好用，没办法，谁叫人家用户多呢，总结，我决定下次还是使用服务端渲染方案吧，暂定使用next.jshttps://github.com/zeit/next.js/，到时再和大家分享。