反应开发
在一些常见用例中修复详尽的deps警告
在里面 上一篇文章 ，我们查看了正确使用 useEffect 钩子需要采用的正确心智模型。在本文中，让我们看看如何调整这种思维模型来解决一些常见的用例。这也将帮助您避免详尽的部门警告。
在 mount 上做某事
首先，我认为这个想法本身是有缺陷的，因为我们不应该考虑功能组件中的生命周期方法。
但在某些情况下，我们可能需要发送 API 请求来获取一些数据以显示在组件中。如果这不依赖于状态或 prop 值，我们可以将一个空数组作为依赖项传递给 useEffect 挂钩，并且此 API 请求将仅发送一次。重要的是要注意，我们并不是要求 React 只在挂载时调用 useEffect 钩子，方法是像许多人想象的那样传递一个空数组。我们只是告诉 React 这个钩子不依赖任何东西，所以 React 只会在第一次渲染时调用它。
但是如果 API 请求依赖于 state 或 prop 值呢？好吧，如果是这种情况，那么我们应该在每次 state 或 prop 值发生变化时调用 API。否则，为什么这首先要取决于状态或道具值？如果我们在 上一篇文章 ，我们应该在每次活动页面状态改变时发送一个 API 请求。调用一次没有意义。因此，可以预见的是，如果您传递一个空的依赖数组，您将收到详尽的依赖项警告。
但是，如果您仍然有这方面的用例，那么您可以考虑将 state 或 prop 值替换为它们的初始值。毕竟，您不想将它与 state 或 prop 值的更改同步。那么，为什么还要费心使用它呢？
不过，如果你认为你有一个用例，那么你可以使用 useRef 钩子。使用这个钩子，我们可以确保 API 请求只发送一次。你会看到这也有助于我们避免详尽的部门警告。
依赖循环
在某些情况下，我们可能必须使用从同一状态派生的值来设置状态。在这种情况下，将状态作为依赖项传递可能会导致无限循环。例如，让我们以一个添加不同 prop 值并在屏幕上显示输出的组件为例。
每次我们更新 prop 值时，组件都应该将新的 prop 值添加到现有的 prop 值总和中。我们可以将 sum 保持在一个 state 中，并在 prop 值发生变化时将 prop 值添加到该 state 中。
我们可以使用 useEffect 挂钩来实现这一点。在这个钩子中，我们可以将 prop 值添加到现有状态值并使用新的总数更新状态。但是，由于我们同时使用 state 和 prop 值，我们必须将两者都作为依赖项传递。不这样做可能会引发详尽的部门警告。但是即使状态值发生变化，React 也会调用这个钩子。由于我们在钩子中更新状态值，这将导致状态更新的无限循环。
我们可以通过使用 setState 的函数式更新器形式来解决这个问题。 setState 方法也可以接受一个回调函数来更新状态。此回调函数将现有状态值作为参数并返回新的状态值。
因此，我们可以通过使用作为参数传递的现有状态在回调函数中执行此操作，而不是直接从状态值计算新的总和。这意味着我们不需要将状态值作为依赖项传递。这有效地解决了无限循环问题。
useReducer 方法
我们也可以通过使用 使用减速器 钩子而不是 useState 钩子。 useReducer 钩子的工作方式与 Redux 中的 reducer 非常相似。您可以定义减速器，然后调度操作来改变状态。
我们可以将 prop 值添加到 reducer 中的状态，这样我们就不需要将状态值作为依赖项传递给 useEffect 挂钩。
组件范围内的功能
当我们在 useEffect 中调用我们在组件内定义的函数时，我们将再次收到详尽的deps 警告。因此，我们还需要将函数作为依赖项传递。
但是，这样做会导致 React 在每次渲染之后调用 useEffect 钩子。原因是在重新渲染期间，React 调用了功能组件。即使它是一个组件，我们也不应该忘记它仍然是一个函数。当 React 调用这个函数来重新渲染组件时，我们在函数中定义的所有东西都将被重新初始化。这也适用于功能组件内的功能。
这意味着函数引用在重新渲染时不会相同。这导致 React 在每次重新渲染后调用 useEffect 钩子。
解决此问题的一种方法是在 useEffect 挂钩中定义函数。这会将函数从功能组件范围中删除，因此我们不需要将其传递到依赖数组中。
使用回调
然而，这可能并不总是可行的，尤其是当我们需要在别处调用这个函数时。在这种情况下，我们可以使用 useCallback 钩子。 useCallback 钩子将一个函数作为第一个参数，将一个依赖数组作为第二个参数。只要依赖关系没有改变，React 就会确保函数引用没有改变。这意味着 React 不会在每次重新渲染后调用 useEffect 钩子。
取消我们已有的关于 useEffect 钩子的模型并学习正确的模型并不是一件容易的事。您也可能想禁用详尽的deps 规则。我花了一段时间来适应这种新的心理模型。但是相信我。一旦你掌握了窍门，功能组件的特殊性就会开始变得更有意义。您还将编写不使用 hack 来适应基于类的心理模型的代码。当你习惯了这种新的心智模型时，你也会意识到这相比起来非常简单，并且可以让你产生更少的错误代码。
最初发表于 https://www.thearmchaircritic.org 2022 年 8 月 28 日。
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明
本文链接：https://www.qanswer.top/1484/02222916
