React:|React: 函数组件与类有什么不同? React:函数组件与类有什么不同

原文: How Are Function Components Different from Classes?
原译文: 函数组件与类有什么不同?

函数组件与类有什么不同? React函数组件与React类组件有何不同？
有一段时间，规范的答案是: 类可以访问更多功能（如状态）。有了Hooks，就不再是这样了。
也许你听说其中一个在性能上会更好。那么是哪一个? 许多这样的benchmarks是有缺陷的，所以我会小心地从中得出结论。性能主要取决于代码在做什么，而不是你选择的是函数还是类。在我们的观察中，虽然优化策略有点不同，但性能差异可以忽略不计。
在任何一种情况下，我们都不建议重写现有组件，除非你有其他原因，并且你也不介意成为早期实践者。Hooks仍然是新的（就像2014年的React一样），并且一些“最佳实践”尚未进入教程。
这给我们带来了什么? React函数和类之间有什么根本的区别吗?当然，在心智模型中存在。在这篇文章中，我将看看它们之间的最大区别。自从2015年引入函数组件以来，它就一直存在，但它经常被忽视:

函数组件捕获渲染的值。

让我们来解释下这意味着什么。
注意: 这篇文章不是对类或函数的价值判断。我只描述了React中这两种编程模型之间的区别。有关更广泛地采用功能的问题，请参阅Hooks FAQ。
考虑这个组件：

function ProfilePage(props) { const showMessage = () => { alert('Followed ' + props.user); }; const handleClick = () => { setTimeout(showMessage, 3000); }; return ( ); }

【React:|React: 函数组件与类有什么不同?】它显示一个按钮，使用setTimeout模拟网络请求，然后显示弹出框。例如，如果props.user是'Dan'，它将在三秒后显示'Followed Dan'。很简单。
(请注意，在上面的示例中我是否使用箭头或函数声明并不重要。function handleClick()将以完全相同的方式工作。)
我们把它写成一个类会怎么样？一个简单的翻译可能是这样的:

class ProfilePage extends React.Component { showMessage = () => { alert('Followed ' + this.props.user); }; handleClick = () => { setTimeout(this.showMessage, 3000); }; render() { return ; } }

通常认为这两段代码是等价的。人们经常在这些模式之间自由地重构，而不注意它们的含义:

文章图片
image 但是，这两个代码片段略有不同。好好看看他们。你看到区别了吗? 就我个人而言，我花了一段时间才明白这一点。
前面有剧透，如果你想自己弄明白，这里有一个在线演示。本文的其余部分解释了差异及其重要性。
在我们继续之前，我想强调一点，我所描述的差异与React Hooks本身无关。以上示例甚至没有使用Hooks！
这都是React中函数和类之间的区别。如果你计划在React应用程序中更频繁地使用函数，则可能需要了解它。
我们将通过React应用程序中常见的bug说明其差异。
打开此示例沙箱并使用选择的当前配置文件和上面的两个ProfilePage实现 -- 每个都渲染一个Follow按钮。
使用两个按钮尝试此操作序列：

点击其中一个"follow"按钮
在3秒之前更改所选的个人资料(笔：就是那个下拉框)。
查看弹出的文字。

你会注意到一个特殊的区别：

使用上面的ProfilePage 函数，单击Follow Dan的个人资料，然后导航到Sophie's仍然会弹框'Followed Dan'。
使用上面的ProfilePage 类，他将会弹出'Followed Sophie'：

文章图片
image 在此示例中，第一个行为是正确的行为。如果我follow一个人然后导航到另一个人的个人资料，我的组件不应该对我follow的人感到困惑。类的实现显然是错误的。
(你应该关注Sophie。)
那么为什么我们的类示例会以这种方式运行？
让我们仔细看看我们类中的showMessage方法：

class ProfilePage extends React.Component { showMessage = () => { alert('Followed ' + this.props.user); };

这个类的方法从this.props.user读取。Props在React中是不可变的，因此它们永远不会改变。然而，this是，并且一直是可变的。
实际上，这就是this在一个类中的全部的目的。React本身会随着时间的推移而改变，以便你可以在render和生命周期方法中读取新版本。
因此，如果我们的组件在请求处于运行状态时重新呈现，则this.props将会更改。showMessage方法从“过新”的props中读取user。
这就暴露了一个关于用户界面性质的有趣观察。如果我们说UI在概念上是当前应用程序状态的函数，那么事件处理程序就是呈现结果的一部分——就像可视化输出一样。我们的事件处理程序“属于”具有特定props和状态的特定渲染。
但是，调用其回调读取this.props的超时会中断该关联。我们的showMessage回调没有“绑定”到任何特定的渲染，因此它“失去”正确的props。从this读取切断了这种联系。
假设函数组件不存在。我们如何解决这个问题？
我们希望以某种方式“修复”具有正确props的render和读取它们的showMessage回调之间的连接。沿途的某个地方props丢失了。
一种方法是在事件早期读取this.props，然后将它们显式传递到超时完成处理程序：

class ProfilePage extends React.Component { showMessage = (user) => {alert('Followed ' + user); }; handleClick = () => { const {user} = this.props; setTimeout(() => this.showMessage(user), 3000); }; render() { return ; } }

这个可以运行。但是，这种方法会使代码随着时间的推移变得更加冗长和容易出错。如果我们需要不止一个prop怎么办？如果我们还需要访问该状态怎么办？如果showMessage调用另一个方法，并且该方法读取this.props.something或this.state.something，我们将再次遇到完全相同的问题。所以我们必须通过从showMessage调用的每个方法将this.props和this.state作为参数传递。
这样做会破坏通常由类提供的人体工程学。这也很难记住或执行, 这就是人们经常解决问题的原因。
同样，在handleClick中嵌入alert代码并不能解决更大的问题。我们希望以一种允许将代码拆分为更多方法的方式来构造代码，同时还可以读取与这个调用相关的呈现所对应的props和状态。这个问题甚至不是React独有的 - 你可以在任何UI库中重现它，你只需要将数据放入可变的对象，比如this。
也许，我们可以在构造函数中绑定方法？

class ProfilePage extends React.Component { constructor(props) { super(props); this.showMessage = this.showMessage.bind(this); this.handleClick = this.handleClick.bind(this); }showMessage() { alert('Followed ' + this.props.user); }handleClick() { setTimeout(this.showMessage, 3000); }render() { return ; } }

不，这不能解决任何问题。请记住，问题是我们从this.props读取的太晚了 - 不是我们正在使用的语法！但是，如果我们完全依赖JavaScript闭包，问题就会消失。
通常会避免闭包，因为很难想象随着时间的推移可能会发生改变的值。但在React中，props和状态是不可改变的！(或者至少，这是一个强烈的推荐。)这就消除了闭包的主要障碍。
这意味着，如果结束某个特定渲染中的props或状态，则始终可以指望它们保持完全相同：

class ProfilePage extends React.Component { render() { // Capture the props! const props = this.props; // Note: we are *inside render*. // These aren't class methods. const showMessage = () => { alert('Followed ' + props.user); }; const handleClick = () => { setTimeout(showMessage, 3000); }; return ; } }

你在渲染时“捕获”了props：
image 这样，它内部的任何代码（包括showMessage）都可以保证看到这个特定渲染的props。React不再“移动我们的奶酪”了。
然后我们可以在里面添加任意数量的辅助函数，它们都会使用捕获的props和状态。闭包来救场了!
[上面的例子](example above)是正确的，但看起来很奇怪。如果在render中定义函数而不是使用类方法，那么拥有一个类有什么意义呢？
实际上，我们可以通过删除它周围的类“外壳”来简化代码:

function ProfilePage(props) { const showMessage = () => { alert('Followed ' + props.user); }; const handleClick = () => { setTimeout(showMessage, 3000); }; return ( ); }

就像上面一样，props仍然被捕获 - React将它们作为参数传递。与this不同，props对象本身永远不会被React改变。
如果你在函数定义中对props进行解构，效果会更明显:

function ProfilePage({ user }) {const showMessage = () => { alert('Followed ' + user); }; const handleClick = () => { setTimeout(showMessage, 3000); }; return ( ); }

当父组件使用不同的props呈现ProfilePage时，React将再次调用ProfilePage函数。但我们单击的事件处理程序“属于”上一个呈现，它有自己的user值和读取它的showMessage回调。它们都完好无损。
这就是为什么，在这个演示的功能版本中，单击关注Sophie的个人资料，然后将选择更改为Sunil会弹出'Followed Sophie'：

文章图片
image 这个行为是正确的。(虽然你可能也想关注Sunil！)
现在我们了解React中函数和类之间的巨大差异：

函数组件捕获呈现的值。

使用Hooks，同样的原则也适用于状态。考虑这个例子：

function MessageThread() { const [message, setMessage] = useState(''); const showMessage = () => { alert('You said: ' + message); }; const handleSendClick = () => { setTimeout(showMessage, 3000); }; const handleMessageChange = (e) => { setMessage(e.target.value); }; return ( <> ); }

(这里是在线演示。)
虽然这不是一个非常好的message应用的UI，但它说明了同样的观点：如果我发送特定消息，组件不应该对实际发送的消息感到困惑。这个函数组件的message捕获了“属于”呈现的状态，呈现返回了浏览器调用的单击处理程序。因此，当我单击"send"时，消息将设置为输入中的内容。
因此，默认情况下，我们知道React中的函数捕获props和状态。但是，如果我们想要阅读不属于这个特定渲染的最新props或状态，该怎么办？如果我们想“从未来读取它们”怎么办？
在类中，你可以通过阅读this.props或this.state来实现它，因为this本身是可变的。React改变了它。在函数组件中，还可以有一个可变值，该值由所有组件呈现共享。它被称为“ref”：

function MyComponent() { const ref = useRef(null); // You can read or write `ref.current`. // ... }

但是，你必须自己管理它。
ref与实例字段扮演相同的角色。这是进入可变命令式世界的出口。你可能熟悉“DOM refs”，但概念更为通用。它只是一个盒子，你可以把东西放进去。
即使在视觉上，this.something看起来像是something.current的镜子。它们代表了相同的概念。
默认情况下，React不会为函数组件中的最新props或状态创建ref。在许多情况下，你不需要它们，分配它们将是浪费工作。但是，如果你愿意，可以手动跟踪值：

function MessageThread() { const [message, setMessage] = useState(''); const latestMessage = useRef(''); const showMessage = () => { alert('You said: ' + latestMessage.current); }; const handleSendClick = () => { setTimeout(showMessage, 3000); }; const handleMessageChange = (e) => { setMessage(e.target.value); latestMessage.current = e.target.value; }; // ... }

如果我们在showMessage中读取message，我们会在按下“发送”按钮时看到消息。但是当我们读取latestMessage.current时，我们得到最新的值 - 即使我们在按下发送按钮后继续输入。
你可以比较两个演示，看看差异。ref是一种“选择退出”渲染一致性的方法，在某些情况下可以很方便。
通常，你应该避免在渲染期间读取或设置refs，因为它们是可变的。我们希望保持渲染的可预测性。但是，如果我们想获得特定props或状态的最新值，那么手动更新ref会很烦人。我们可以通过使用effect来自动处理它：

function MessageThread() { const [message, setMessage] = useState(''); // Keep track of the latest value. const latestMessage = useRef(''); useEffect(() => { latestMessage.current = message; }); const showMessage = () => { alert('You said: ' + latestMessage.current); }; // ... }

(这里是一个demo。)
我们在effect 中进行赋值，以便ref值仅在DOM更新后更改。这确保了我们的突变不会破坏依赖于可中断呈现的Time Slicing and Suspense等特性。
使用像这样的ref并不是经常需要的。捕获props或状态通常是更好的默认配置。但是，在处理间隔和订阅等命令式API时，它可以很方便。请记住，你可以跟踪任何这样的值 - 一个prop，一个状态变量，整个props对象，甚至是函数。
这种模式对于优化也很方便，例如当useCallback标识更改太频繁时。但是，using a reducer 通常是一个更好的解决方案。(后续的博客文章的主题！)
在这篇文章中，我们研究了类中常见的破坏模式，以及闭包如何帮助我们修复它。然而，你可能已经注意到，当你试图通过指定依赖项数组来优化Hooks时，可能会遇到使用过时闭包的bug。是否意味着闭包是问题？我不这么认为。
正如我们上面所看到的，闭包实际上帮助我们解决了很难注意到的细微问题。类似地，它们使在并发模式下编写正确工作的代码更加容易。这是可能的，因为组件内部的逻辑结束了正确的props和状态。
到目前为止，我所看到的所有情况下，“过时的闭包”问题都是由于错误地假设“函数不会更改”或“props总是相同”而发生的。事实并非如此，因为我希望这篇文章有助于澄清这个问题。
函数与它们的props和状态密切相关，因此它们的身份也同样重要。这不是bug，而是函数组件的一个特性。例如，函数不应该从useeffect或usecallback的“依赖项数组”中排除。(正确的修复通常是useReducer或上面的useRef解决方案 - 我们很快就会记录如何在它们之间进行选择。)
当我们编写大多数带有函数的React代码时，我们需要调整优化代码，以及哪些值会随时间变化。
正如 Fredrik所说 :