首先声明,此思路、解码鄙人并非原创而是通过短视频平台观看 但此文章是鄙人原创 觉得是一个很好的思路 分享给在座的码农 鄙人还是初级程序员 欢迎大家指点不足
异步传染性就是 当某一个函数节点是异步的时候 那他接下来的所有函数的调用都必须是异步
鄙人在开发过程中遇到过这个问题 有幸看到这个demo 获得解决思路
(资料图片仅供参考)
如图所示
这是一个再正常不过的开发过程中处理请求的方法 接收的结果也是无比的正常
问:有什么办法可以消除函数中的副作用,使其变成同步的函数式编程
有人会讲,把async await 去掉不就好了吗,当然不可以因为 请求数据本身的操作是异步的
去掉 就返回了Promise 而不是我们想要的结果
结果 如图所示
我在平台学习到了一个思路 那就是 缓存+手动报错
思路:1. 当第一次请求的时候 无论是成功或失败 把他缓存下来2. 重复请求第二次 手动报错 拿取缓存中的数据3. 函数开始 => 请求数据 (缓存data)=> 引发错误 => 函数结束 =>手动调用第二次函数 => 请求数据 => 拿取缓存data => 函数结束
解决:1. 首先必须在请求第一个函数做处理,首先请求是多次的 所以我们必须用数组来接受请求获得的参数,在他有缓存的时候 停止循环三次循环 直接返回缓存中的数据
这里我们重写了fetch写法 改变了全局fetch的功能,定义了基本的解决思路
接下来就是发送请求,我们需要拿到原本window的fetch来请求
当手动定义了缓存的格式,那就可以自己判定缓存的类型 来决定报错 还是正常返回数据
当成功的时候 返回正常的data
当失败的时候 抛出错误 注意 不是retun 否则后续的try catch接收不到
接下来就是手动报错 让函数停止 并且使用try catch捕获错误 来进行第二次返回缓存的函数请求
但是这里有一个弊端,不是所有的报错 都需要执行第二次 我们必须用一个标识来解决此项冲突
手动报错可以把请求的promise 抛出
在error中判定是否属于promise 而进行重复第二次请求
判断error是否是promise 而进行第二次请求 同时将下标清0
此刻,我们就解决了异步的传染性 如图所示
总结:1. 这是一个最小demo 只是提供一个思路 运用到实际开发 还有待欠缺
2. 欢迎指正讨论更好更精确的解决方案 下面是全部代码 仅供参考
X 关闭
今日看点:关注第七批国家药品集采:价格降了多少?如何保障用药连续性?
X 关闭
X 关闭