javascript - 为什么 addChangeListener 应该在 componentDidMount 而不是 componentWillMount？

Question

我将此行视为对此处另一个问题的回答:

“componentWillMount 应该是 componentDidMount，否则你会在节点中泄漏事件发射器。”

我也不是很懂。有人可以更详细地解释一下吗？

更多信息:

使用 flux 构建一个 React 应用程序，作为初始渲染的一部分，子组件计算一些数据。理想情况下，在计算完这些数据后，我想调用一个操作，用一部分新数据更新商店的状态。

通常，更新商店的状态会发出一个导致重新渲染的更改事件。但是，由于直到 componentDidMount(而不是在 componentWillMount 中)才添加更改监听器，因此我的顶级组件无法监听初始渲染期间发生的更改并启动重新渲染。

如果我将 addChangeListener 移动到 componentWillMount 似乎可以解决这个问题，但上面的引述表明这是个坏主意？

Answer 1

我认为应该在 componentDidMount 中设置监听器的流行观点是错误的，因为它可以防止同构应用程序出现问题。我认为在 98% 的情况下，对于非同构应用程序，在 componentWillMount 和 componentDidMount 中设置监听器将以相同的方式工作，但它在概念上是错误的，并且在 2% 的情况下例(如原题给出的例子)会做错事。

React 源代码中有 git issue 讨论和评论，建议最好不要在服务器上调用 componentWillMount，但如果不是，则会产生问题在校验和测试中比较服务器预渲染和客户端初始渲染。在服务器上拥有 componentWillMount 意味着在这种情况下它不会作为组件生命周期的一部分执行，但这被用作在任何情况下都不将其视为生命周期一部分的借口。

事实上，如果您不创建同构应用程序，componentWillMount 正是注册监听器的正确位置。如果您正在创建一个同构应用程序，那么您必须做出一些妥协，因为在这种情况下校验和/生命周期问题并不理想(也许只是测试服务器环境，然后不注册监听器？)。

在非同构应用程序中，在 componentWillMount 中添加监听器在某些情况下可以节省不必要的重新渲染，并将按文档顺序注册它们。文档顺序的优点是，如果您有办法在重新呈现组件时刷新未决事件(例如，MutationObserver 上的takeRecords)，那么您可以确保文档自上而下而不是自下而上重新渲染，将渲染复杂度从多项式转换为线性。

此外，在初始渲染和注册监听器之间没有危险期，Store 可以在不触发渲染的情况下更改，从而导致 View 与 Store 不同步(原始问题中给出的示例问题).如果监听器已在 componentDidMount 中注册，您需要确保商店在子级的 componentDidMount 调用中未更改，或者强制重新渲染/重新同步注册监听器后，如果在 componentDidMount 中完成，则以反向文档顺序完成，这可能是多项式复杂度(取决于 React setStates 的聚合方式/是否聚合)。