共计 1189 个字符，预计需要花费 3 分钟才能阅读完成。
1、写在后面
本篇文章旨在解释 react 异步申请内存透露问题的起因，以及对 AbortController 应用摸索，欢送各位童鞋一起摸索交换。
2、怎么会这样，why((灬ꈍ ꈍ灬))
常常用 react 开发我的项目的小伙伴应该常常碰到这种问题，即一个弹出框或者一个组件被另外一个组件立刻销毁，但被销毁或者敞开的弹出框外部可能正在某种申请中(申请示意：这不能怪我啊，我还没回城呢，你却拆了我家，嘤嘤嘤~~)，这时销毁了组件，但申请还在路上，申请的回调还没开释，这就导致了内存透露。
3、AbortController
咋个办呢，用一个变量存贮是否行将销毁？willUnmount 时 setState 为 true？为 true 时做一些操作？。。。
貌似不怎么行呀，曾经在途中的申请怎么召回？class 组件能够应用生命钩子，但 hooks 呢，没有钩子，Fetch,axios 如同也都只返回 promise，当然 rxjs 能够 (subscribe 返回句柄，能够在 effect 下 return unsubscribe)，但 rxjs 团队学习老本比拟高，比拟少用。怎么办呢？
AbortController 对象实现了能够与申请通信的接口，通过它咱们能够显示的停止申请。
属性：AbortController.signal 一个 AbortSignal 对象，咱们能够拿着它与 request 对话或者停止它
Returns an AbortSignal object instance, which can be used to communicate with, or to abort, a DOM request.
办法：AbortController.abort 在一个申请实现前停止它
Aborts a DOM request before it has completed. This is able to abort fetch requests, consumption of any response bodies, and streams.
应用(how to use)
Wow, It’s seem Ok！
如同能够了，销毁了申请也被停止了，回调更改 react 状态也停止，不错。
然而大家不知发现什么问题没有，每一个申请都如此解决是否太麻烦？一个 AbortController 的 signal 是否能管制多个申请，还是像 promise 一样状态凝固？
所以，让咱们来测试一下
测试后果：AbortConntroller 的 abort 存在和 promise 一样的问题，一旦状态凝固，再应用这个实例 signal 的申请将间接回绝
优化
大家应用 react 开发我的项目，必定就是工程化我的项目，不止一个中央应用申请，一个个去写逻辑必定不事实，但设计 AbortController 的单例模式显然不适合。在那 axios 封装 request 办法的时候用工厂模式生成 AbortController，并在返回的 promise 上减少属性，让使用者拿到控制器。
