javascript - 反应：未安装组件中的 setState

这有点晚了，但是，我最近开始研究 React 抛出的 unmounted setState 警告，他们提到这可能导致内存泄漏。

有一篇博客文章提到 isMounted() 或拥有自己的 isMounted 是一种反模式 https://reactjs.org/blog/2015/12/16/ismounted-antipattern.html

有一个 twitter 线程，Dan Abramov 解释了为什么这是一种反模式以及它如何导致内存泄漏。要点是，promise then/catch 处理程序仍然持有对未安装组件的引用的时间超过了所需的时间。理想情况下，一旦组件被卸载，我们就不应该有这个引用

我已经浏览了与此相关的 stackoverflow 上的其他答案，其中确定了为什么这个具有可取消承诺的解决方案在语义上比其他解决方案更好。

Dan 建议的理想实现是要么拥有可以在内部取消这些组件引用的可取消承诺，要么拥有自己的可取消承诺实现，如果它被取消，它可能只会拒绝承诺，但应该删除对零件。

现在，我真的不明白这个引用是如何工作的，以及如何通过博客文章中建议的解决方案解决这个问题（如果它已被取消，这似乎会拒绝承诺，但没有任何方法可以删除引用组件）

这些是我想了解的事情：

如果在组件A中，在promise.then（或catch）中我们没有引用this，这意味着该组件没有被引用，即使它被卸载，当实际调用then处理程序时也不会发生内存泄漏？
如果我们then在组件 A 中为 Promise 注册一个处理程序，它的生命周期是多久？它会被运行时删除吗？一旦组件被卸载，它是否会被删除，因为组件不再保留对承诺的引用，因此也不再保留then回调。但是在这种情况下，then组件安装后的回调仍然会运行，就像它在微任务队列中安排的那样，但这不会在以后发生吗？（这可能是我们在卸载组件时只看到一次此警告的原因）
我们如何在 Promise 取消中手动删除对组件的引用（正如 Dan 在 Twitter 线程中所建议的那样）以避免内存泄漏？
博文中建议的解决方案仍然会导致内存泄漏？（与 isMounted 解决方案相比，此解决方案在语义上可能更正确）

标签： javascriptreactjspromisees6-promise