reactjs - useEffect exhaustive-deps 警告 : what possible issues is this trying to avoid?

Question

我意识到有很多关于 React 的 useEffect hook 的依赖数组的问题，以及可能因缺少依赖项而出现的 eslint 警告。关于此的其他一些很好的讨论:

• How to fix missing dependency warning when using useEffect React Hook
• React useEffect Missing Dependency
• React useEffect missing dependecy?
• React Hook useEffect has a missing dependency with useEffect

虽然这些警告的原因和解决方案非常清楚，但我很难理解的一件事是原因。首先，快速总结一下，我的理解是将 useEffect 作为三个通用目的:

• 如果省略它的依赖数组，它的行为就像 componentDidMount 和 componentDidUpdate:它在第一次呈现组件时运行，并在所有后续呈现时运行。
• 如果它的依赖数组是空的，它就像 componentDidMount 一样:它可以用来运行第一次初始化代码(例如从服务器获取初始数据等)。
• 否则，您可以在其依赖数组中包含您希望它“监视”的任何变量；它会像 componentDidMount 一样工作，然后在这些变量发生变化时像 componentDidUpdate 一样工作。
• (为了完整起见:它的返回值也可用于实现 componentWillUnmount 行为，但这超出了本期的范围)。

我知道如果 useEffect 引用了在 useEffect 之外声明的任何函数(或其他变量)，eslint 会报错。根据以上链接，有多种方法可以解决这些警告:将函数添加到依赖数组并使用 useCallback 记住它；使用 //eslint-disable-next-line 或 //eslint-disable-line react-hooks/exhaustive-deps 禁用警告；等这些都是有道理的。我很难理解的是为什么它甚至会提示这个。

所以，我的具体问题:

1. 实际上，我不明白为什么您曾经想要引用依赖项数组中的本地函数。例如，如果您有 useEffect(() => { checkCurrentUser() }, [])，并且 checkCurrentUser 需要在 useEffect 之外定义，因为它在别处被调用，checkCurrentUser 将在每个组件渲染(这就是为什么如果我们把它放在数组中，我们应该用 useCallback 记住它)。但对我来说，为什么有人会在依赖数组中想要这个完全没有逻辑意义。那么为什么这甚至是一个警告呢？这个警告实际上有助于防止什么？在我看到警告的所有时间里，在每种情况下，应用程序的行为都完全符合我的预期/意图。

2. 如果 useEffect 的主要目的之一是像 componentDidMount 一样“运行一次”，而实现该行为的方法是显式放置一个空数组，那么如果您指定一个空数组，为什么会麻烦您呢？我能理解为什么如果您有一个包含一些引用但不包含其他引用的依赖项数组，那么发出警告可能是有意义的——就像“哎呀，你忘记了一些”——但是空数组是一个特定的、定义明确的用法。对我来说，它会告诉您“空数组是个问题”似乎没有意义，因为这是实现 componentDidMount 类型初始化的唯一方法。感觉就像警告你“不要使用 componentDidMount()”一样。如果这应该是 useEffect 的 3 个主要用途之一，为什么它会提示一个空数组？

同样，我确实了解警告出现的情况以及解决方法。我只是很难理解拥有它的好处，(1) 在函数的情况下(我们明确知道它会在每次渲染时发生变化)，以及 (2) 在空数组的情况下(这是一个特定的用法) ).

Answer 1

(1) in the case of functions (which we definitively know will changeon every single render)

要求将函数放在依赖项中的原因 seems to be与他们要求您将任何其他值放在依赖项中的原因相同:可能发生的情况是，您正在使用的函数可能本身引用了组件范围内的某些值，这些值可能会变得陈旧。

(2) in the case of an empty array (which are a specific usage).

在这种情况下，我将引用 Dan Abramov 从 this 引用的答案评论:

I think the biggest gotcha with class life cycle methods likecomponentDidMount is that we tend to think of it as an isolatedmethod, but in fact it's part of a flow. If you reference something incomponentDidMount you will most probably need to handle it incomponentDidUpdate as well, or your component may get buggy. This iswhat the rule is trying to fix, you need to handle values over time....

您可能会在该线程中找到有关他们为何这样做的更多信息。