关于异步:处理可能超时的异步操作

自从 ECMAScript 的 Promise ^ES2015 和 async/await ^ES2017 个性公布当前，异步在前端界曾经成为特地常见的操作。异步代码和同步代码在解决问题程序上会存在一些差异，编写异步代码须要领有跟编写同步代码不同的“意识”，为此我还专门写了一篇「异步编程须要“意识”」，不过看的人不多，可能的确“无趣”。

本文要聊的问题可能依然“无趣”，但很事实 —— 如果一段代码久久不能执行实现，会怎么样？

如果这是同步代码，咱们会看到一种叫做“无响应”的景象，或者艰深地说 ——“死掉了”；然而如果是一段异步代码呢？可能咱们等不到后果，但别的代码仍在持续，就如同这件事件没有产生个别。

当然事件并不是真的没产生，只不过在不同的状况下会产生不同的景象。比方有加载动画的页面，看起来就是始终在加载；又比方应该进行数据更新的页面，看不到数据变动；再比方一个对话框，怎么也关不掉 …… 这些景象咱们统称为 BUG。但也有一些时候，某个异步操作过程并没有“回显”，它就默默地死在那里，没有人晓得，待页面刷新之后，就连一点陈迹都不会留下。

当然，这不是小说，咱们得聊点“闲事”。

Axios 自带超时解决

应用 Axios 进行 Web Api 调用就是一种常见的异步操作过程。通常咱们的代码会这样写：

try {const res = await axios.get(url, options);
    // TODO 失常进行后续业务
} catch(err) {// TODO 进行容错解决，或者报错}

这段代码个别状况下都执行良好，直到有一天用户埋怨说：怎么等了半天没反馈？

而后开发者意识到，因为服务器压力增大，这个申请曾经很难刹时响应了。思考到用户的感触，加了一个 loading 动画：

try {showLoading();
    const res = await axios.get(url, options);
    // TODO 失常业务
} catch (err) {// TODO 容错解决} finally {hideLoading();
}

然而有一天，有用户说：“我等了半个小时，竟然始终在那转圈圈！”于是开发者意识到，因为某种原因，申请被卡死了，这种状况下应该重发申请，或者间接报告给用户 —— 嗯，得加个超时查看。

侥幸的是 Axios 的确能够解决超时，只须要在 options 里增加一个 timeout: 3000 就能解决问题。如果超时，能够在 catch 块中检测并解决：

try {...}
catch (err) {
    if (err.isAxiosError && !err.response && err.request
        && err.message.startsWith("timeout")) {
        // 如果是 Axios 的 request 谬误，并且音讯是延时音讯
        // TODO 解决超时
    }
}
finally {...}

Axios 没问题了，如果用 fetch() 呢？

解决 fetch() 超时

fetch() 本人不具备解决超时的能力，须要咱们判断超时后通过 AbortController 来触发“勾销”申请操作。

如果须要中断一个 fetch() 操作，只需从一个 AbortController 对象获取 signal，并将这个信号对象作为 fetch() 的选项传入。大略就是这样：

const ac = new AbortController();
const {signal} = ac;
fetch(url, { signal}).then(res => {// TODO 解决业务});

// 1 秒后勾销 fetch 操作
setTimeout(() => ac.abort(), 1000);

ac.abort() 会向 signal 发送信号，触发它的 abort 事件，并将其 .aborted 属性置为 true。fetch() 外部解决会利用这些信息停止掉申请。

下面这个示例演示了如何实现 fetch() 操作的超时解决。如果应用 await 的模式来解决，须要把 setTimeout(...) 放在 fetch(...) 之前：

const ac = new AbortController();
const {signal} = ac;
setTimeout(() => ac.abort(), 1000);
const res = await fetch(url, { signal}).catch(() => undefined); 

为了防止应用 try ... catch ... 来解决申请失败，这里在 fetch() 后加了一个 .catch(...) 在疏忽谬误的状况。如果产生谬误，res 会被赋值为 undefined。理论的业务解决可能须要更正当的 catch() 解决来让 res 蕴含可辨认的错误信息。

原本到这里就能够完结了，然而对每一个 fetch() 调用都写这么长一段代码，会显得很繁琐，不如封装一下：

async function fetchWithTimeout(timeout, resoure, init = {}) {const ac = new AbortController();
    const signal = ac.signal;
    setTimeout(() => ac.abort(), timeout);
    return fetch(resoure, { ...init, signal});
}

没问题了吗？不，有问题。

如果咱们在上述代码的 setTimeout(...) 里输入一条信息：

setTimeout(() => {console.log("It's timeout");
    ac.abort();}, timeout);

并且在调用的给一个足够的工夫：

fetchWithTimeout(5000, url).then(res => console.log("success"));

咱们会看到输入 success，并在 5 秒后看到输入 It's timeout。

对了，咱们尽管为 fetch(...) 解决了超时，然而并没有在 fetch(...) 胜利的状况下干掉 timer。作为一个思维周密的程序员，怎么可能犯这样的谬误呢？干掉他！

async function fetchWithTimeout(timeout, resoure, init = {}) {const ac = new AbortController();
    const signal = ac.signal;
    
    const timer = setTimeout(() => {console.log("It's timeout");
        return ac.abort();}, timeout);
    
    try {return await fetch(resoure, { ...init, signal});
    } finally {clearTimeout(timer);
    }
}

完满！但问题还没完结。

万物皆可超时

Axios 和 fetch 都提供了中断异步操作的路径，但对于一个不具备 abort 能力的一般 Promise 来说，该怎么办？

对于这样的 Promise，我只能说，让他去吧，轻易他去干到天荒地老 —— 反正我也没方法阻止。但生存总得持续，我不能始终等啊！

这种状况下咱们能够把 setTimeout() 封装成一个 Promise，而后应用 Promise.race() 来实现“过时不候”：

race 是竞速的意思，所以 Promise.race() 的行为是不是很好了解？

function waitWithTimeout(promise, timeout, timeoutMessage = "timeout") {
    let timer;
    const timeoutPromise = new Promise((_, reject) => {timer = setTimeout(() => reject(timeoutMessage), timeout);
    });

    return Promise.race([timeoutPromise, promise])
        .finally(() => clearTimeout(timer));    // 别忘了清 timer
}

能够写一个 Timeout 来模仿看看成果：

(async () => {const business = new Promise(resolve => setTimeout(resolve, 1000 * 10));

    try {await waitWithTimeout(business, 1000);
        console.log("[Success]");
    } catch (err) {console.log("[Error]", err);    // [Error] timeout
    }
})();

至于如何写能够停止的异步操作，下次再聊。