尽管小程序的网络请求已经算是封装好的（类似通过函数对ajax的一层封装），但是当同时涉及多个请求时还是会出现多个回调函数嵌套的情况，因此青睐于链式调用的，可以考虑用Promise再对wx.request封装一次。
最简单的封装方式可能如下：
/**
* 通过Promise对wx.request封装
*
* @param {any} {method, url, option} // 一个包含method, url, option 三个Key的对象
* @returns 返回一个Promise实例
*/
const request = ({ method, url, option }) => {
if (!method || !url) {
throw new Error('an url and a method are both required')
}
return new Promise((resolve, reject) => {
wx.request({
method,
url,
...option,
header: {
'content-type': 'application/json',
Accept: 'application/json',
// 可以在这里加一些其他的头部，比如token什么的
},
success (res) {
let statusCode = res.statusCode
if (statusCode >= 200 && statusCode < 300) {
resolve(res.data)
} else {
reject(res.data)
}
},
fail (errMsg) {
reject(errMsg)
}
})
})
}
当然，上面只是最简单的情况，实际业务中碰到的情况可能要复杂一些，比如上面header里要加token时会涉及到token过期的情况，此时我们的处理逻辑是，对于每次服务器返回的我们通过request封装发出的请求的回复，首先会验证是否有token过期的情况，如果有，首先处理token过期的问题，然后再依据实际场景进行下一步操作；如果没有，处理返回的数据。
一般处理token过期的方法可能就是将页面跳转到登录界面，让用户重新登录，然后去让其自己手动去执行之前的操作（这也是我一直以来的处理方法，token过期了让用户自己重新登录，对于登陆之前用户想要做的操作就让用户自己再重复操作一遍就好了。其实仔细想想应该可以做的更好，至于怎样做的更好，我们先往后看），但是对于有些没有显示登录的情况，比如微信小程序通过微信就可以唯一确定一个用户，服务器通过openId返回给客户端token，客户端以此token作为登录凭证，一切登录流程都在用户无法感知的情况下进行，那么此时就无法只简单粗暴地跳到Login的界面就能完事了。我们需要「偷偷地」进行一次重新登录，在登录完成后，重新发送一遍刚才用户的请求。
对应的代码可能像下面这样：
success (res) {
let statusCode = res.statusCode
if (statusCode >= 200 && statusCode < 300) {
resolve(res.data)
} else if (/**token过期的情况**/) {
login().then(() => {/**继续原来的请求**/})
} else {
reject(res.data)
}
}
在完善上面代码中login()和后面then()里的代码之前，我们先看下Promise.resolve()这个静态方法。
描述：静态方法 Promise.resolve返回一个解析过的Promise对象.
语法：
- Promise.resolve(value);
- Promise.resolve(promise);
- Promise.resolve(thenable);
返回值：返回一个解析过带着给定值的Promise对象，如果返回值是一个promise对象，则直接返回这个Promise对象。
Promise.resolve(value)可以看成是
const resolve = value => new Promise(resolve => resolve(value))
的快捷形式，其中value的值可以为js中一切的合法值，可以分三类：promise对象、一个包含then方法的普通对象、其他值。三种情况的返回值都是一个promise对象，即都可以在其后链式调用then方法。此处我们主要说下resolve(promise)的情形，当传进的参数是一个promise对象，那么Promise.resolve()方法会直接返回这个promise对象。例如：
let prom0 = Promise.resolve('hahaha')
var promise1 = new Promise((resolve, reject) => {
setTimeout(() => {
let prom01 = resolve(prom0)
console.log(prom01, prom0)
console.log(prom0===prom01)
}, 1000)
})
let prom2 = Promise.resolve(promise1)
console.log(promise1 === prom2)
prom2.then(console.log)
promise1 = Promise.resolve('lalala')
prom2 = Promise.resolve(promise1)
console.log(promise1 === prom2)
prom2.then(console.log)
> undefined Promise {<resolved>: "hahaha"}
> false
> true
> true
> "lalala"
> "hahaha"
可以看到被Promise.resolve()的promise其结果不变，作用前和作用后都一致，到这里我才发现我想要探究的是new Promise((resolve, reject) => {resolve()})里的resolve，但是问题不大，起先我以为这个resolve()于Promise.resolve()的作用是一致的，但是我console.log(prom0 === resolve(prom0))发现是false的，然后console.log(resolve(prom0))的结果是undefined才想起来这个resolve应该是没有返回值的，他的作用是把传给它的值再传给后面then()，当然要给它弄个返回值而且返回值的机制与Promise.resolve()一样的话应该也无伤大雅，但更多的可能是多此一举，因为倘若resolve()有与Promise.resolve()一样的返回值的话，那么可能会导致下面这样的写法：
var promise1 = new Promise((resolve, reject) => {
setTimeout(() => {
resolve(prom0).then(...)
}, 1000)
})
在构造promise的对象时候，直接就把对应的then()方法给写好了，这样一来就与Promise链式调用的设计理念冲突了吧？
现在让我们补充login().then(() => {/**继续原来的请求**/})里的代码，继续原来的请求应该怎么写呢？在之前我们已经将request请求需要的参数都传好了，现在只用再在里面递归调用一次就好了：request({ method, url, option })，但是需要注意的是，上面语句执行完的结果是返回一个promise对象，如果我们不调用这个对象的then()方法的话，等于什么也得不到。那应该怎么做呢？直接在后面调用then()么？显然这是行不通的，先不说直接调用会有回调嵌套的麻烦，直接调用的话，那么在调用的then()里面应该执行什么样的逻辑判断才能做到通用呢？所以直接调用肯定是行不通的。其实如果对Promise理解还可以的话，应该很自然就能想到怎么处理那个Promise对象： 把它resolve()出去，然后在每个特定请求后调用的then()里面写各自的处理逻辑。
login().then(() => {
resolve(request({ method, url, option }))
})
下面是login.js的部分：
import {
SECRET,
GRANTTYPE,
APPID,
WX_LOGIN,
BASE_URL,
LOGIN_STRING
} from './config.js'
import bus from '@/bus.js'
const WXLogin = () =>
new Promise((resolve, reject) => {
wx.login({
success (res) {
resolve(res.code)
},
fail (res) {
reject(res.errMsg)
}
})
})
const login = () =>
WXLogin().then(
code =>
new Promise((resolve, reject) => {
wx.request({
method: 'POST',
url: `${BASE_URL}${WX_LOGIN}`,
data: {
SECRET,
GRANTTYPE,
APPID,
CODE: code
},
header: {
'content-type': 'application/json',
Accept: 'application/json'
},
success (res) {
let statusCode = res.statusCode
if (statusCode >= 200 && statusCode < 300) {
bus.setToken(res.data.Data.Token)
resolve(LOGIN_STRING)
} else {
reject(res.Message)
}
}
})
})
)
export default login
到此就封装的基本可以满足要求了。当然，还可以在
const request = ({ method, url, option }) => {...}里把method单独抽出来：
const requestGenerator = method => ({url, option}) => {
...
login().then(() => {
resolve(requestGenerator(method)({ url, option }))
})
...
}
export const Get = requestGenerator('GET')
export const Post = requestGenerator('POST')
这个就全凭个人喜好。
最后说一下前面说的
一般处理token过期的方法可能就是将页面跳转到登录界面，让用户重新登录，然后去让其自己手动去执行之前的操作（这也是我一直以来的处理方法，token过期了让用户自己重新登录，对于登陆之前用户想要做的操作就让用户自己再重复操作一遍就好了。其实仔细想想应该可以做的更好，至于怎样做的更好，我们先往后看）
怎样做的更好呢？其实看完上面的应该就有个答案了，既然request可以做一层封装让他能统一处理token过期时的情况，那么login也可以封装一下，让他可以处理不同的login场景，正常的login和token过期的导致的re-login，可以通过是否往里面传一些额外参数来控制，当没有额外参数时视之为普通login，登录成功后跳到主界面即可；当有额外参数时，除了跳到主界面之外还需要做进一步的操作，比如跳到re-login前的页面再执行对应的网络请求。我想这些应该是可以通过将re-login前的上下文信息保存起来传到login里当额外参数实现的吧。
