????首先聲明，此思路、解碼鄙人并非原創(chuàng) 而是通過(guò)短視頻平臺(tái)觀看 但此文章是鄙人原創(chuàng)?覺(jué)得是一個(gè)很好的思路 分享給在座的碼農(nóng) 鄙人還是初級(jí)程序員 歡迎大家指點(diǎn)不足

異步傳染性就是 當(dāng)某一個(gè)函數(shù)節(jié)點(diǎn)是異步的時(shí)候 那他接下來(lái)的所有函數(shù)的調(diào)用都必須是異步

鄙人在開(kāi)發(fā)過(guò)程中遇到過(guò)這個(gè)問(wèn)題 有幸看到這個(gè)demo 獲得解決思路

如圖所示

這是一個(gè)再正常不過(guò)的開(kāi)發(fā)過(guò)程中處理請(qǐng)求的方法 接收的結(jié)果也是無(wú)比的正常

問(wèn)：有什么辦法可以消除函數(shù)中的副作用，使其變成同步的函數(shù)式編程

有人會(huì)講，把a(bǔ)sync await 去掉不就好了嗎，當(dāng)然不可以因?yàn)?請(qǐng)求數(shù)據(jù)本身的操作是異步的

去掉 就返回了Promise 而不是我們想要的結(jié)果

結(jié)果 如圖所示

我在平臺(tái)學(xué)習(xí)到了一個(gè)思路 那就是 緩存+手動(dòng)報(bào)錯(cuò)?

思路：
1. 當(dāng)?shù)谝淮握?qǐng)求的時(shí)候 無(wú)論是成功或失敗 把他緩存下來(lái)
2. 重復(fù)請(qǐng)求第二次 手動(dòng)報(bào)錯(cuò) 拿取緩存中的數(shù)據(jù)
3. 函數(shù)開(kāi)始 => 請(qǐng)求數(shù)據(jù) （緩存data）=> 引發(fā)錯(cuò)誤 => 函數(shù)結(jié)束 =>手動(dòng)調(diào)用第二次函數(shù) => 請(qǐng)求數(shù)據(jù) => 拿取緩存data => 函數(shù)結(jié)束

解決：
1. 首先必須在請(qǐng)求第一個(gè)函數(shù)做處理，首先請(qǐng)求是多次的 所以我們必須用數(shù)組來(lái)接受請(qǐng)求獲得的參數(shù)，在他有緩存的時(shí)候 停止循環(huán)三次循環(huán) 直接返回緩存中的數(shù)據(jù)

這里我們重寫了fetch寫法 改變了全局fetch的功能，定義了基本的解決思路

接下來(lái)就是發(fā)送請(qǐng)求，我們需要拿到原本window的fetch來(lái)請(qǐng)求

當(dāng)手動(dòng)定義了緩存的格式，那就可以自己判定緩存的類型 來(lái)決定報(bào)錯(cuò) 還是正常返回?cái)?shù)據(jù)

1. 當(dāng)成功的時(shí)候 返回正常的data

2. 當(dāng)失敗的時(shí)候 拋出錯(cuò)誤 注意 不是retun 否則后續(xù)的try catch接收不到

接下來(lái)就是手動(dòng)報(bào)錯(cuò) 讓函數(shù)停止 并且使用try catch捕獲錯(cuò)誤 來(lái)進(jìn)行第二次返回緩存的函數(shù)請(qǐng)求

但是這里有一個(gè)弊端，不是所有的報(bào)錯(cuò) 都需要執(zhí)行第二次 我們必須用一個(gè)標(biāo)識(shí)來(lái)解決此項(xiàng)沖突

1. 手動(dòng)報(bào)錯(cuò)可以把請(qǐng)求的promise 拋出

2. 在error中判定是否屬于promise 而進(jìn)行重復(fù)第二次請(qǐng)求

?判斷error是否是promise 而進(jìn)行第二次請(qǐng)求 同時(shí)將下標(biāo)清0

此刻，我們就解決了異步的傳染性 如圖所示

總結(jié)：
1. 這是一個(gè)最小demo 只是提供一個(gè)思路 運(yùn)用到實(shí)際開(kāi)發(fā) 還有待欠缺

2. 歡迎指正討論更好更精確的解決方案 下面是全部代碼 僅供參考?