关于javascript:玩转-AbortController-控制器

绝大部分状况，网络申请都是先申请先响应。然而某些状况下，因为未知的一些问题，可能会导致先申请的 api 后返回。最简略的解决方案就是增加 loading 状态，在所有申请都实现后能力进行下一次申请。

但不是所有的业务都能够采纳这种形式。这时候开发者就须要对其进行解决以防止渲染谬误数据。

咱们能够应用版本号来决策业务解决以及数据渲染:

const invariant = (condition: boolean, errorMsg: string) => {if (condition) {throw new Error(errorMsg)
    }
}

let versionForXXXQuery = 0;

const checkVersionForXXXQuery = (currentVersion: number) => {
    // 版本不匹配，就抛出谬误
    invariant(currentVersion !== versionForXXXQuery, 'The current version is wrong')
}

const XXXQuery = async () => {
    // 此处只能应用 ++versionForXXXQuery 而不能应用 versionForXXXQuery++
    // 否则版本永远不对应
    const queryVersion = ++versionForXXXQuery;

    // 业务申请
    checkVersion(queryVersion)
    // 业务解决
    //？界面渲染


    // 业务申请
    checkVersion(queryVersion)
    // 业务解决
    //？界面渲染
}

如此，先申请的 api 后返回就会被谬误中止执行，但最终渲染到界面上的只有最新版本的申请。然而该计划对业务的侵入性太强。尽管咱们能够利用 class 和 AOP 来简代码和逻辑。但对于开发来说仍旧不敌对。这时候咱们能够应用 AbortController。

话不多说，先应用 AbortController 实现下面雷同的性能。

let abortControllerForXXXQuery: AbortController | null = null

const XXXQuery = async () => {
    // 以后有停止控制器, 间接把上一次勾销
    if (abortControllerForXXXQuery) {abortControllerForXXXQuery.abort()
    }

    // 新建控制器
    abortControllerForXXXQuery = new AbortController();

    // 获取信号
    const {signal} = abortControllerForXXXQuery
    
    const resA = await fetch('xxxA', { signal});
    // 业务解决
    //？界面渲染

    const resB = await fetch('xxxB', { signal});
    // 业务解决
    //？界面渲染
}

咱们能够看到：代码非常简单，同时失去了性能加强，浏览器将提前进行获取数据（注：服务器依旧会解决屡次申请，只能通过 loading 来升高服务器压力）。

尽管代码很简略，然而为什么须要这样增加一个 AbortController 类而不是间接通过增加 api 来进行停止网络申请操作呢？这样不是减少了复杂度吗？笔者开始也是这样认为的。到前面才发现。AbortController 类尽管较为简单了，然而它是通用的，因而 AbortController 能够被其余 Web 规范和 JavaScript 库应用。

const controller = new AbortController()
const {signal} = controller

// 增加事件并传递 signal
window.addEventListener('click', () => {console.log('can abort')
}, {signal})

window.addEventListener('click', () => {console.log('click')
});

// 开始申请并且增加 signal
fetch('xxxA', { signal})

// 移除第一个 click 事件同时停止未实现的申请
controller.abort()

既然它是通用的，那是不是也能够终止业务办法呢。答案是必定的。先来看看 AbortController 到底为啥可能通用呢？

AbortController 提供了一个信号量 signal 和停止 abort 办法, 通过这个信号量能够获取状态以及绑定事件。

const controller = new AbortController();

// 获取信号量
const {signal} = controller;

// 获取以后是否曾经执行过 abort，目前返回 false
signal.aborted

// 增加事件
signal.addEventListener('abort', () => {console.log('触发 abort')
})

// 增加事件
signal.addEventListener('abort', () => {console.log('触发 abort2')
})


// 停止 (不能够解构间接执行 abort，有 this 指向问题)
// 控制台打印 触发 abort，触发 abort2
controller.abort()

// 以后是否曾经执行过 abort, 返回 ture
signal.aborted

// 控制台无反馈
controller.abort();

无疑，上述的事件增加了 abort 事件的监听。综上，笔者简略封装了一下 AbortController。Helper 类如下所示：

class AbortControllerHelper {
    private readonly signal: AbortSignal 

    constructor(signal: AbortSignal) {
        this.signal = signal
        signal.addEventListener('abort', () => this.abort())
    }

    /**
     * 执行调用办法，只须要 signal 状态的话则无需在子类实现
     */
    abort = (): void => {} 

    /**
     * 查看以后是否能够执行
     * @param useBoolean 是否应用布尔值返回
     * @returns 
     */
    checkCanExecution = (useBoolean: boolean = false): boolean => {const { aborted} = this.signal
        // 如果应用布尔值，返回是否能够继续执行
        if (useBoolean) {return !aborted}
        // 间接抛出异样
        if (aborted) {throw new Error('abort has already triggered');
        }
        return true
    }
}

如此，开发者能够增加子类继承 AbortControllerHelper 并放入 signal。而后通过一个 AbortController 停止多个乃至多种不同事件。

如果你感觉这篇文章不错，心愿能够给与我一些激励，在我的 github 博客下帮忙 star 一下。

博客地址

AbortController MDN

关于javascript:玩转-AbortController-控制器

应用“版本号”

应用 AbortController

AbortController 勾销之前申请

AbortController 移除绑定事件

通用的 AbortController

激励一下

参考资料