关于useEffect错误用法的推理

珍惜时间，勤奋学习！今天给大家带来《关于useEffect错误用法的推理》，正文内容主要涉及到等等，如果你正在学习文章，或者是对文章有疑问，欢迎大家关注我！后面我会持续更新相关内容的，希望都能帮到正在学习的大家！

React 中最错误使用的 hook 无疑是 useEffect。我们这样做有多种原因，而不仅仅是一个。让我们从我的角度来探讨其中的每一个。

生命周期遗产

所以我认为影响更大的原因之一是，在前钩子时代，我们使用了类。对于这一时期开始使用React的人来说，已经习惯了使用生命周期方法和this.state。我在这篇文章中写了一些相关内容。有人怀念古老而黄金的阶级时代，看重它的简单和直接。这个模型非常符合一般程序员的常识，学习面向对象和命令式编程，并且心理结构恰好与该模型相关。

然后他们添加了钩子。

思维范式转变

问题在于所发生的范式转变。一般来说，程序员都非常熟悉命令式和面向对象范式，他们通常在大学和课程中教授，主要是命令式，遵循人类的共同思维流程。

当你切换到函数式编程等不同范式时，你会面临一种相反的思维方式，这与常见的思维方式不太接近。这种“回归”就更难理解了。

响应式编程也遇到同样的问题。这是从主动编程方式到被动编程方式的转变。我们看到它错误地使用了 useEffect。

大多数“错误”都是状态同步。因此，开发人员使用 useEffect 来跟踪某些状态或 prop，并基于某些逻辑来更改状态。这个案例揭示了我们需要的相反的思维方式。

在 OOP 和命令式编程中，您是主动的，以主动的方式进行更改和逻辑。反应性基于相反的情况，您对机会做出反应，并声明您希望系统在状态发生变化时执行的计算。

对于大多数用户来说，在useEffect上主动设置新的状态是直接的方式，状态发生了变化，所以你需要手动跟踪变化并用它更新其他状态。文档说不推荐，但没有明确的原因。

在 React 中进行派生是推荐的方式，不仅是出于性能原因，而且是出于概念原因。 React 是一个推导机器，最终的结果就是 UI 的推导。您不需要主动处理这些状态转换和重新计算，它只是根据您编写的声明性代码发生。

React 文档没有很好地解释这一点，在 hooks 之后，React 核心团队和内容创建者没有进行演讲或课程来解释这些概念。

React 的概念混乱

React 似乎存在“概念混乱”，向 hooks 的过渡是最有力的例子，但不是唯一的例子。 hooks 的使用有一个很大的区别，它是基于反应性的，尽管 React 核心团队开玩笑说反应性，但他们决定切换到它。

功能组件非常适合它。每次重新渲染都会再次调用该函数，并且内部的所有内容都会获取状态和道具当前版本，因此，内部创建的所有内容都表现得像派生。回报，JSX，是UI的衍生。

但是 React 并不是函数式编程和反应性的完美和纯粹的实现。它以概念和想法为灵感，并将它们融合起来创建自己的模型，但无论如何，核心就在那里。

这一点需要明确。即使不是反应性的示例，它也使用了它们的概念，并且更深入地了解这些模式使开发人员可以轻松地使用这些原语思考和创建解决方案。顺便说一句，这就是我写这个“React 中的反应性”系列的原因。

不仅仅是对用户说，“不要在 useEffect 上同步状态，这很糟糕”，而是解释为什么它很糟糕，以及如何以“同步状态”甚至是第一个解决方案的方式思考。

缺乏一些原语

这一原因正在得到改善，尤其是在 React 19 中。异步派生是使用 useEffect 的原因之一，但现在我们必须使用原语，它在某些方面填补了这一空白。

当然，我们在原语中仍然存在一些弱点，例如动态派生的情况和其他情况，但是越来越多的 React 将更多的副作用移出了 hooks 字段，就像 ref 回调的情况一样。

我们总是可以期待未来的消息。我邀请大家阅读React中所有其他Reactivity的帖子，并带来具体的案例和问题，我们可以探索并找到这些常见反应性问题的更多解决方案。

终于介绍完啦！小伙伴们，这篇关于《关于useEffect错误用法的推理》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！