最近在写uniapp,发现执行网络请求的时候经常要处理Loading效果。
比如,在发送网络请求之前,触发Loadng;无论请求成功还是失败都要关闭Loading;请求失败的时候我们还要给用户一个友好的提示,比如“服务器打了个盹”。
每次都要手动处理,真的很麻烦;而且处理Loading的逻辑跟业务逻辑混在一起,也不便于维护。
因此,我打算把这个需求封装成要一个方法,就叫loadingRun
。
这个方法并不是一蹴而就的,经历了几个版本的迭代。我强烈建议你看完这篇文章,你一定能有所收获。
在封装之前,我们先看看封装之前代码长啥样:
uni.showLoading({
mask: true
})
uniCloud.database().collection('orders').doc(props.orderId).get({getOne: true}).then(res => {
Object.assign(order, res.result.data)
uni.hideLoading()
}).catch(_ => {
uni.hideLoading().then(_ => uni.showToast({
icon: "fail",
title: "服务器打了个盹"
}))
}).finally(_ => uni.hideLoading())
有些小伙伴可能不熟悉uniapp,所以我们解释一下部分代码:
uniCloud.database().collection('orders').doc(props.orderId).get({getOne: true})
这是uniapp的uniCloud的操作,执行的是网络请求,返回的是一个promise。uni.showLoading()
uniapp 提供的显示Loading的api。uni.hideLoading()
uniapp 提供的关闭Loading的api。uni.showToast()
uniapp 提供的显示Toast提示api。这些你都可以想象成自己熟悉的UI框架的操作。
我们需要把这个方法抽成一个通用的loadingRun
方法,首先不管三七二十一,我们先把这个方法写出来:
function loadingRun() {
uni.showLoading({
mask: true
})
uniCloud.database().collection('orders').doc(props.orderId).get({getOne: true}).then(res => {
Object.assign(order, res.result.data)
uni.hideLoading()
}).catch(_ => {
uni.hideLoading().then(_ => uni.showToast({
icon: "fail",
title: "服务器打了个盹"
}))
}).finally(_ => uni.hideLoading())
}
然后我们就想,有哪些操作是可以提取出来,作为loadingRun
的参数。
最容易想到的就是Object.assign(order, res.result.data)
这行代码,这行代码是promise解决之后处理逻辑,我们可以把它提取成一个resolve参数:
function loadingRun(resolve) {
uni.showLoading({
mask: true
})
uniCloud.database().collection('orders').doc(props.orderId).get({getOne: true}).then(res => {
resolve(res)
uni.hideLoading()
}).catch(_ => {
uni.hideLoading().then(_ => uni.showToast({
icon: "fail",
title: "服务器打了个盹"
}))
}).finally(_ => uni.hideLoading())
}
还有什么可以提取的呢?uniCloud.database().collection('orders').doc(props.orderId).get({getOne: true})
这个操作我们可以提取,因为的网络操作是不固定的。它是一个promise,我们先不管三七二十一,先用一promise来接收:
function loadingRun(promise, resolve) {
uni.showLoading({
mask: true
})
promise.then(res => {
resolve(res)
uni.hideLoading()
}).catch(_ => {
uni.hideLoading().then(_ => uni.showToast({
icon: "fail",
title: "服务器打了个盹"
}))
}).finally(_ => uni.hideLoading())
}
还能再抽吗?貌似toast提醒的文案可以抽出来,不过我们整站的提示都是统一的,所以就不抽了。
现在就可以了吗?显然不是,它还有问题,有大问题,我们接着聊。
我们前面讲了封装loadingRun
的思路,就是“抽”、“抽”、“抽”,先不管合理不合理,先抽再说。这样可以让我们最快的得到一个基本的骨架:
function loadingRun(promise, resolve) {
uni.showLoading({
mask: true
})
promise.then(res => {
resolve(res)
uni.hideLoading()
}).catch(_ => {
uni.hideLoading().then(_ => uni.showToast({
icon: "fail",
title: "服务器打了个盹"
}))
}).finally(_ => uni.hideLoading())
}
看着不错,实际有大问题,你知道是啥问题吗?
问题就是loadingRun
直接接收了一个promise实例。
为啥直接接收就有问题呢?因为promise是创建时立即执行的,所以loadingRun
执行的时候,promise可能已经执行完了,网络请求可能都返回了,此时在才显示Loading,黄瓜菜都凉了。
所以loadingRun
不能从外部接收一个promise,我们需要在loadingRun
内部创建这个promise。
我们可以让外部传入一个方法promiseGenerator
,这个方法执行会产生一个promise:
function loadingRun(promiseGenerator, resolve) {
uni.showLoading({
mask: true
})
promiseGenerator().then(res => {
resolve(res)
uni.hideLoading()
}).catch(_ => {
uni.hideLoading().then(_ => uni.showToast({
icon: "fail",
title: "服务器打了个盹"
}))
}).finally(_ => uni.hideLoading())
}
至此我们获得了V1版本的loadingRun
,我们前面代码可以用loadingRun
来重构一下:
loadingRun(_ => uniCloud.database().collection('orders')
.doc(props.orderId).get({getOne: true}),
res => Object.assign(order, res.result.data))
看起来没那么清晰对吧,我们再改进一下:
// 把获取订单的操作封装到一个方法中
function getOrderAsync(id) {
return uniCloud.database().collection('orders')
.doc(id).get({getOne: true})
}
// 封装处理逻辑
function reactiveSetOrder(res) {
Object.assign(order, res.result.data)
}
现在的loadingRun
就清晰了:
loadingRun(getOrderAsync(props.id), reactiveSetOrder)
当然后面这个封装,不属于我门今天讨论的范畴。
什么,还有V2版本,loadingRun
还可以再优化吗?
还真是!现在的loadingRun
接收一个promiseGenerator
,promiseGenerator
产生一个promise实例。
如果我有一个很耗时的方法,但是它不返回promise,它也想用loadingRun
怎么办呢?
现在V1版本还不够通用,我们需要让它变得更加通用。
我们可以这么处理,我们把promiseGenerator
参数,换成更通用的func
参数。如果它的结果是一个promise,那么就走原来的逻辑;否则,我们把func
的执行结果用Promise.resolve
封装成一个promise,走之前的逻辑。
这个叫参数归一化!
我们先定一个方法判断变量是不是一个promise:
function isPromiseLike(value) {
return value != null
&& (typeof value === 'object' || typeof value === 'function')
&& typeof value.then === 'function'
}
这里并不是直接用instanceof Promise
判断,而是判断变量是不是满足Promise A+规范。
接下来我们改造loadingRun
:
function loadingRun(func, resolve) {
uni.showLoading({
mask: true
})
let ret = func()
let promise = isPromiseLike(ret) ? ret : Promise.resolve(ret)
promise.then(res => {
resolve(res)
uni.hideLoading()
}).catch(_ => {
uni.hideLoading().then(_ => uni.showToast({
icon: "fail",
title: "服务器打了个盹"
}))
}).finally(_ => uni.hideLoading())
}
现在我们可以用loadingRun
处理耗时的非promise操作了,比如计算斐波那契数列:
loadingRun(_ => fibonacciRecursive(100000), val => console.log(`计算结果:${val}`))
啊!还能再优化吗?
还真实。现在的loadingRun
已经够用了,但是还有一个场景满足不了。
比如,当网络请求或者耗时操作报错了,我希望除了提示Toast,还要执行一个其他的操作,现在就没办法,因为promise实例没有返回出来。
因此改造也很简单,只需要把promise返回出来就行了。
function loadingRun(func, resolve) {
uni.showLoading({ mask: true })
let ret = func()
let promise = isPromiseLike(ret) ? ret : Promise.resolve(ret)
promise.then(res => {
resolve(res)
uni.hideLoading()
}).catch(_ => {
uni.hideLoading().then(_ => uni.showToast({
icon: "fail",
title: "服务器打了个盹"
}))
}).finally(_ => uni.hideLoading())
return promise
}
然后我们就可以这样处理:
loadingRun(getOrderAsync(props.id), reactiveSetOrder)
.catch(_ => doSomething())
Game Over !!!
再更新一波!
后面用的时候发现,操作成功的时候我也想提示Toast,所以我需要先关闭Loading。因此需要把resolve放到Loading关闭之后执行。
function loadingRun(func, resolve) {
uni.showLoading({ mask: true })
let ret = func()
let promise = isPromiseLike(ret) ? ret : Promise.resolve(ret)
promise.then(res => {
uni.hideLoading().then(_ => resolve(res))
}).catch(_ => {
uni.hideLoading().then(_ => uni.showToast({
icon: "fail",
title: "服务器打了个盹"
}))
}).finally(_ => uni.hideLoading())
return promise
}
另外,我发现我是真的需要区分失败的原因的。比如“创建失败”,“修改失败”。所以错误的文档还是提取一个参数吧,为了兼容之前的调用,我们这里就用默认参数。
function loadingRun(func, resolve, tips = '服务器打了个盹') {
uni.showLoading({ mask: true })
let ret = func()
let promise = isPromiseLike(ret) ? ret : Promise.resolve(ret)
promise.then(res => {
uni.hideLoading().then(_ => resolve(res))
}).catch(_ => {
uni.hideLoading().then(_ => uni.showToast({
icon: "fail",
title: tips
}))
}).finally(_ => uni.hideLoading())
return promise
}