与React类组件相比，React函数式组件究竟有何不同？
在过去一段时间里，典型的回答是类组件提供了更多的特性（比如state）。当有了Hooks后，答案就不再是这样了。
或许你曾听过它们中的某一个在性能上的表现优于另一个。那是哪一个？很多此类的判断标准都存在这样那样的缺陷（flawed），所以我会谨慎看待从它们中得出的结论。性能主要取决于代码的作用，而不是选择函数式还是类组件。在我们的观察中，尽管优化策略各有略微不同，但性能差异可以忽略不计。
在任何一种情况下，除非你有其他原因并且不介意成为早期使用者，否则我们不推荐重构你现有的组件。Hooks还很年轻（如同2014年的React），并且有些“最佳实践”还没有找到它们的切入方式。
那么现在是个什么情况？React的函数式组件和类组件之间是否有任何根本上的区别？当然有 —— 在心智模型上。在这篇文章中，我将阐述它们之间的最大区别。 自2015年我们推出函数式组件以来，它一直存在，但是经常被忽略：
函数式组件捕获了渲染所用的值。（Function components capture the rendered values.）
让我们来看看这意味着什么。
思考这个组件:
function ProfilePage(props) {
const showMessage = () => {
alert('Followed ' + props.user);
};
const handleClick = () => {
setTimeout(showMessage, 3000);
};
return (
<button onClick={handleClick}>Follow</button>
);
}
它渲染了一个利用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 <button onClick={this.handleClick}>Follow</button>;
}
}
通常我们认为，这两个代码片段是等效的。人们经常在这两种模式中自由的重构代码，但是很少注意到它们的含义：
然而，这两个代码片段还是有略微的不同。 仔细的看看它们。现在看出他们的不同了吗？就我个人而言，我花了好一会儿才看明白这一点。
接下来的文章是“剧透”，如果你想自己搞明白，你可以查看这个live demo。 本文的生育部分解释了这里面的差异以及阐述了为什么这很重要。
在我们继续之前，我想强调一点，我所描述的差异与 React Hooks 完全无关。上面的例子中甚至没有使用 Hooks！
它全部是关于 React 中函数式组件与类组件的区别的。如果你打算在你的 React 应用中更频繁地使用函数式组件，你可能需要理解它。
我们将通过 React 应用程序中的一个常见错误来说明其中的不同。
打开这个sandbox例子 例子， 你将看到一个当前账号选择框以及两个上面 ProfilePage 的实现 —— 每个都渲染了一个 Follow 按钮。
尝试按照以下顺序来分别使用这两个按钮：
你将看到一个奇特的区别:
当使用 函数式组件 实现的 ProfilePage, 当前账号是 Dan 时点击 Follow 按钮，然后立马切换当前账号到 Sophie，弹出的文本将依旧是 ‘Followed Dan’。
当使用 类组件 实现的 ProfilePage, 弹出的文本将是 ‘Followed Sophie’：
在这个例子中，第一个行为是正确的。如果我关注一个人，然后导航到了另一个人的账号，我的组件不应该混淆我关注了谁。 在这里，类组件的实现很明显是错误的
所以为什么我们的例子中类组件会有这样的表现？
让我们来仔细看看我们类组件中的 showMessage 方法：
class ProfilePage extends React.Component {
showMessage = () => {
alert('Followed ' + this.props.user);
};
这个类方法从 this.props.user 中读取数据。在 React 中 Props 是不可变(immutable)的，所以他们永远不会改变。然而，this是，而且永远是，可变(mutable)的。
事实上，这就是类组件 this 存在的意义。React本身会随着时间的推移而改变，以便你可以在渲染方法以及生命周期方法中得到最新的实例。
所以如果在请求已经发出的情况下我们的组件进行了重新渲染，this.props将会改变。showMessage方法从一个“过于新”的props中得到了user。
这暴露了一个关于用户界面性质的一个有趣观察。如果我们说UI在概念上是当前应用状态的一个函数，那么事件处理程序则是渲染结果的一部分 —— 就像视觉输出一样。我们的事件处理程序“属于”一个拥有特定 props 和 state 的特定渲染。
然而，调用一个回调函数读取 this.props 的 timeout 会打断这种关联。我们的 showMessage 回调并没有与任何一个特定的渲染“绑定”在一起，所以它“失去”了正确的 props。从 this 中读取数据的这种行为，切断了这种联系。
让我们假设函数式组件不存在。我们将如何解决这个问题？
我们想要以某种方式“修复”拥有正确 props 的渲染与读取这些 props 的showMessage回调之间的联系。在某个地方props被弄丢了。
一种方法是在调用事件之前读取this.props，然后将他们显式地传递到timeout回调函数中去：
class ProfilePage extends React.Component {
showMessage = (user) => {
alert('Followed ' + user);
};
handleClick = () => {
const {user} = this.props;
setTimeout(() => this.showMessage(user), 3000);
};
render() {
return <button onClick={this.handleClick}>Follow</button>;
}
}
这种方法 会起作用。然而，这种方法使得代码明显变得更加冗长，并且随着时间推移容易出错。如果我们需要的不止是一个props怎么办？如果我们还需要访问state怎么办？如果 showMessage 调用了另一个方法，然后那个方法中读取了 this.props.something 或者 this.state.something，我们又将遇到同样的问题。然后我们不得不将this.props和this.state以函数参数的形式在被showMessage调用的每个方法中一路传递下去。
这样的做法破坏了类提供的工程学。同时这也很难让人去记住传递的变量或者强制执行，这也是为什么人们总是在解决bugs。
同样的，在handleClick中内联地写alert代码也无法解决问题。我们希望以允许将其拆分为多个方法的方式来构造组织代码，但同时也能读取与某次组件调用形成的渲染结果对应的props和state。这个问题并不是React所独有的 —— 你可以在任何一个将数据放入类似 this 这样的可变对象中的UI库中重现它
或许，我们可以在构造函数中绑定方法？
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 <button onClick={this.handleClick}>Follow</button>;
}
}
不，这没有解决任何问题。记住，我们面对的问题是我们从this.props中读取数据太迟了——读取时已经不是我们所需要使用的上下文了！然而，如果我们能利用JavaScript闭包的话问题将迎刃而解
通常来说我们会避免使用闭包，因为它会让我们难以想象一个可能会随着时间推移而变化的变量。但是在React中，props和state是不可变得！（或者说，在我们的强烈推荐中是不可变得。）这就消除了闭包的一个主要缺陷。
这就意味着如果你在一次特定的渲染中捕获那一次渲染所用的props或者state，你会发现他们总是会保持一致，就如同你的预期那样：
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 <button onClick={handleClick}>Follow</button>;
}
}
这样，在它内部的任何代码（包括showMessage）都保证可以得到这一次特定渲染所使用的props。React再也不会“动我们的奶酪”。
**然后我们可以在里面添加任意多的辅助函数，它们都会使用被捕获的props和state。**闭包万岁！
上面的例子是正确的，但是看起来很奇怪。如果你在render方法中定义各种函数，而不是使用class的方法，那么使用类的意义在哪里？
事实上，我们可以通过删除类的“包裹”来简化代码：
function ProfilePage(props) {
const showMessage = () => {
alert('Followed ' + props.user);
};
const handleClick = () => {
setTimeout(showMessage, 3000);
};
return (
<button onClick={handleClick}>Follow</button>
);
}
就像上面这样，props仍旧被捕获了 —— React将它们作为参数传递。不同于this，props对象本身永远不会被React改变。
如果你在函数定义中解构props，那将更加明显：
function ProfilePage({ user }) {
const showMessage = () => {
alert('Followed ' + user);
};
const handleClick = () => {
setTimeout(showMessage, 3000);
};
return (
<button onClick={handleClick}>Follow</button>
);
}
当父组件使用不同的props来渲染ProfilePage时，React会再次调用ProfilePage函数。但是我们点击的事件处理函数，“属于”具有自己的user值的上一次渲染，并且showMessage回调函数也能读取到这个值。它们都保持完好无损。
这就是为什么，在上面那个demo的函数式版本中，点击关注Sophie的账号，然后改变选择为Sunil仍旧会弹出’Followed Sophie’：
这个行为展现是正确的
现在我们明白了React中函数式组件和类组件之间的巨大差别：
函数式组件捕获了渲染所使用的值。