说Fetch之前啊，我们不得不说一说Ajax了，以前使用最多的自然是jQuery封装的Ajax方法了，强大而且好用。
有人说了，jQuery的Ajax都已经封装得那么好了，你还整Fetch干什么，这不是多此一举嘛。实际上，在大家写业务需求的时候能够感觉到，越是复杂的业务逻辑，Ajax用起来就会显得有点费劲，因为它的异步回调机制，很容易让我们陷入嵌套循环中，业务代码就会变得非常臃肿而难以理解。而Fetch请求则可以写成同步的模式，一步一步执行，阅读起来就非常舒服。
有人又说了，Ajax也能写成同步的啊，用Promise封装一个就好了。你说得对，可那不是有点多余吗，有现成的你不用，还得搭上一个jQuery，不划算。总之，我们使用Fetch来进行请求，轻量而且方便。
题外话：你把接口写完了，是不是得了解一下接口请求是不是成功啦，请求成功率有多高呢；接口耗时怎么样啊，超时的接口又有多少；那么如何监控接口请求的性能问题，可以看下我写的前端监控系统：www.webfunny.cn 或者github搜索：webfunny_monitor 欢迎了解。
题外话说完，下边开始说干货了。
Fetch本身其实跟Ajax一样都是对XMLHttpRequest的封装，而且封装的很不错了，为什么还要封装呢，我们且看下fetch请求的写法。
// fetch原本方法的写法
fetch(url, {
method: 'GET';
}).then(res => {
res.json();
}).then(data => {
console.log(data);
}).catch(error => {
console.log(error.msg);
})
请看，上边的代码算是最简单的fetch请求方法了，写出来是这个样子的，虽然简单，但是调用链也忒长了点儿啊，我们再看下相对较复杂一点的fetch请求写法。
// fetch原本方法的写法
fetch(url, {
method: "POST",
headers: {
"Accept": "*/*",
"Content-Type": "application/json;charset=utf-8",
"access-token": "token"
}
}).then(res => {
res.json()
}).then(data => {
console.log(data)
}).catch(error => {
console.log(error.msg)
})
上边带一坨headers, 下边带一坨catch，十分恶心。像这个简单的调用方法，还没有处理超时、报错、404等，都够咱们喝一壶了，所以业务实践，Fetch方法必须要封装。
一、区分请求类型
一般请求的方式有多重类型如：PUT,POST,GET,DELETE；今天我们就以最常见的post、get为例进行封装。不管是用什么方法请求，请求所需要的参数和逻辑处理都是大致相同的，所以我们要做的就是把这些共用的部分提取出来。
我们先来解释一下它的参数，url：请求路径；param：请求参数，get、post分别用不同的方式传入；httpCustomerOpertion（自定义参数），isHandleResult：是否需要处理错误结果，比如toast错误信息，上报错误信息等等；isShowLoading：是否显示loading，每个接口请求都需要时间，是否显示loading效果；customerHead：是否使用自定义的请求头；timeout: 自定义接口超时的时间
以上参数虽然繁琐，但都是很有必要的，代码如下：
/**
* get 请求
* @param url
* @param params
* @param isHandleError
* @param httpCustomerOpertion 使用者传递过来的参数, 用于以后的扩展用户自定义的行为
* {
* isHandleResult: boolen //是否需要处理错误结果 true 需要/false 不需要
* isShowLoading: boolen //是否需要显示loading动画
* customHead: object // 自定义的请求头
* timeout: int //自定义接口超时的时间
* }
* @returns {Promise}
*/
get(url, params = {}, httpCustomerOpertion = { isHandleResult: true, isShowLoading: true }) {
if (!httpCustomerOpertion.hasOwnProperty("isHandleResult")) {
httpCustomerOpertion.isHandleResult = true
}
if (!httpCustomerOpertion.hasOwnProperty("isShowLoading")) {
httpCustomerOpertion.isShowLoading = true
}
const method = "GET"
const fetchUrl = url + CommonTool.qs(params) // 将参数转化到url上
const fetchParams = Object.assign({}, { method }, this.getHeaders())
return HttpUtil.handleFetchData(fetchUrl, fetchParams, httpCustomerOpertion)
}
/**
* post 请求
* @param url
* @param params
* @param isHandleError
* @param httpCustomerOpertion 使用者传递过来的参数, 用于以后的扩展用户自定义的行为
* @returns {Promise}
*/
post(url, params = {}, httpCustomerOpertion = { isHandleResult: true, isShowLoading: true }) {
if (!httpCustomerOpertion.hasOwnProperty("isHandleResult")) {
httpCustomerOpertion.isHandleResult = true
}
if (!httpCustomerOpertion.hasOwnProperty("isShowLoading")) {
httpCustomerOpertion.isShowLoading = true
}
const method = "POST"
const body = JSON.stringify(params) // 将参数转化成JSON字符串
const fetchParams = Object.assign({}, { method, body }, this.getHeaders())
return HttpUtil.handleFetchData(url, fetchParams, httpCustomerOpertion)
}
二、fetch请求业务逻辑封装
请求方式区分开了，接下来我们对fetch的核心内容进行封装。
1. 判断自定义请求信息，loading，header。
2. 对fetch请求再进行一次封装。
3. 放弃迟到的响应，轮询时，有可能发生这种情况，后边发出的接口请求，提前获得了返回结果，就需要放弃前一次的请求结果。
4. 统一处理返回结果，后台业务返回结果，无论结果如何，说明接口正常。业务逻辑再区分正常和异常，比如token超时，业务异常等等。
5. 接口状态判断，第4点说了，返回结果，无论结果如何，接口都是正常的；如果接口状态是非200类型的，说明接口本身出错了，如404，500等，需要单独捕获和处理。
6. 接口超时处理，由于fetch本身并不支持超时判断，所以我们需要利用promise.race方法来判断超时问题。
核心代码如下：
/** * 发送fetch请求
* @param fetchUrl
* @param fetchParams
* @returns {Promise}
*/
static handleFetchData(fetchUrl, fetchParams, httpCustomerOpertion) { // 1. 处理的第一步
const { isShowLoading } = httpCustomerOpertion
if (isShowLoading) {
HttpUtil.showLoading()
}
httpCustomerOpertion.isFetched = false
httpCustomerOpertion.isAbort = false
// 处理自定义的请求头
if (httpCustomerOpertion.hasOwnProperty("customHead")) {
const { customHead } = httpCustomerOpertion
fetchParams.headers = Object.assign({}, fetchParams.headers, customHead)
} // 2. 对fetch请求再进行一次Promise的封装
const fetchPromise = new Promise((resolve, reject) => {
fetch(fetchUrl, fetchParams).then(
response => { // 3. 放弃迟到的响应
if (httpCustomerOpertion.isAbort) {
// 3. 请求超时后，放弃迟到的响应
return
}
if (isShowLoading) {
HttpUtil.hideLoading()
}
httpCustomerOpertion.isFetched = true
response.json().then(jsonBody => {
if (response.ok) { // 4. 统一处理返回结果
if (jsonBody.status === 5) {
// token失效,重新登录
CommonTool.turnToLogin()
} else if (jsonBody.status) {
// 业务逻辑报错, 不属于接口报错的范畴
reject(HttpUtil.handleFailedResult(jsonBody, httpCustomerOpertion))
} else {
resolve(HttpUtil.handleResult(jsonBody, httpCustomerOpertion))
}
} else { // 5. 接口状态判断
// http status header <200 || >299
let msg = "当前服务繁忙，请稍后再试"
if (response.status === 404) {
msg = "您访问的内容走丢了…"
}
Toast.info(msg, 2)
reject(HttpUtil.handleFailedResult({ fetchStatus: "error", netStatus: response.status, error: msg }, httpCustomerOpertion))
}
}).catch(e => {
const errMsg = e.name + " " + e.message
reject(HttpUtil.handleFailedResult({ fetchStatus: "error", error: errMsg, netStatus: response.status }, httpCustomerOpertion))
})
}
).catch(e => {
const errMsg = e.name + " " + e.message
// console.error('ERR:', fetchUrl, errMsg)
if (httpCustomerOpertion.isAbort) {
// 请求超时后，放弃迟到的响应
return
}
if (isShowLoading) {
HttpUtil.hideLoading()
}
httpCustomerOpertion.isFetched = true
httpCustomerOpertion.isHandleResult && Toast.info("网络开小差了，稍后再试吧", 2)
reject(HttpUtil.handleFailedResult({ fetchStatus: "error", error: errMsg }, httpCustomerOpertion))
})
})
return Promise.race([fetchPromise, HttpUtil.fetchTimeout(httpCustomerOpertion)])
}
三、通用逻辑单独封装
代码里注释也非常详尽了，我就不一一赘述了
/**
* 统一处理后台返回的结果, 包括业务逻辑报错的结果
* @param result
* ps: 通过 this.isHandleError 来判断是否需要有fetch方法来统一处理错误信息
*/
static handleResult(result, httpCustomerOpertion) {
if (result.status && httpCustomerOpertion.isHandleResult === true) {
const errMsg = result.msg || result.message || "服务器开小差了，稍后再试吧"
const errStr = `${errMsg}（${result.status}）`
HttpUtil.hideLoading()
Toast.info(errStr, 2)
}
return result
}
/**
* 统一处fetch的异常, 不包括业务逻辑报错
* @param result
* ps: 通过 this.isHandleError 来判断是否需要有fetch方法来统一处理错误信息
*/
static handleFailedResult(result, httpCustomerOpertion) {
if (result.status && httpCustomerOpertion.isHandleResult === true) {
const errMsg = result.msg || result.message || "服务器开小差了，稍后再试吧"
const errStr = `${errMsg}（${result.status}）`
HttpUtil.hideLoading()
Toast.info(errStr, 2)
}
const errorMsg = "Uncaught PromiseError: " + (result.netStatus || "") + " " + (result.error || result.msg || result.message || "")
return errorMsg
}
/**
* 控制Fetch请求是否超时
* @returns {Promise}
*/
static fetchTimeout(httpCustomerOpertion) {
const { isShowLoading } = httpCustomerOpertion
return new Promise((resolve, reject) => {
setTimeout(() => {
if (!httpCustomerOpertion.isFetched) {
// 还未收到响应，则开始超时逻辑，并标记fetch需要放弃
httpCustomerOpertion.isAbort = true
// console.error('ERR: 请求超时')
if (isShowLoading) {
HttpUtil.hideLoading()
}
Toast.info("网络开小差了，稍后再试吧", 2)
reject({ fetchStatus: "timeout" })
}
}, httpCustomerOpertion.timeout || timeout)
})
}
到此，fetch请求的封装就算完成了，如此封装的fetch请求方法可以兼容很多业务场景了。
四、与后端接口的约定
当然，接口请求从来都不仅仅是前端一个人的事情，还需要跟后台的小伙伴进行约定。 比如：返回结果包含status， status = 0，说明业务逻辑正常，我们只管取结果即可； status!=0，说明业务逻辑异常，后端将异常信息放到msg字段里，前端将其Toast出来，展现给用户。
五、封装后的调用方式
export const fetchAction = (param, handleResult, handleFailResult) => {
return HttpUtil.post(HttpApi.url, param).then( response => {
handleResult(response.data)
}).catch((e) => {
handleFailResult()
console.error(e)
})
}// 调用的结果就是这样的await fetchAction1await fetchAction2await fetchAction3
结语
Fetch方法的封装说到底就为了满足更多的业务场景，而且现实的业务场景中，我在上文中基本都已经提到了。也许你不能完全理解代码中所写的东西，但是你只要能理解为什么要做这些事情，你就知道该怎么去封装这些请求方法了。