这时，你将会看到一个现象：

• 使用函数组件时，当前账号是小白，点击查询按钮，然后立马将当前账号切换到小黄，但弹框显示的内容依然还是小白；

• 而当使用类组件时，同样的操作下，弹框显示的是小黄。

那为什么会这样呢？因为当切换下拉框后，新的 user 作为 props 传入了类组件中，所以此时组件内的 user 已经发生变化了。如下代码所示：

showMessage = () => {
     // 这里每次都是取最新的 this.props。
    alert('用户是' + this.props.user);
};
1
2
3
4
1
2
3
4

这里的 this 存在一定的模糊性，容易引起错误使用。如果希望组件能正确运行，那么我们可以这样修改：

 showMessage = (user) => {
    alert('用户是' + user);
  };
  handleClick = () => {
    const {user} = this.props;
    setTimeout(() => this.showMessage(user), 3 * 1000);
  }
1
2
3
4
5
6
7
1
2
3
4
5
6
7

但在函数组件的闭包中，这就不是问题，它捕获的值永远是确定且安全的。有了这样一个基础认知，我们就可以继续探讨差异了。

独有能力

类组件通过生命周期包装业务逻辑，这是类组件所特有的。我们常常会看到这样的代码：

class A extends React.Component {
  componentDidMount() {
     fetchPosts().then(posts => {
      this.setState({ posts });
    }
  }
  render() {
    return ...
  }
}
1
2
3
4
5
6
7
8
9
10
1
2
3
4
5
6
7
8
9
10

在还没有 Hooks 的时代，函数组件的能力是相对较弱的。在那个时候常常用高阶组件包裹函数组件模拟生命周期。当时流行的解决方案是 Recompose。如下代码所示：

const PostsList = ({ posts }) => (
  <ul>{posts.map(p => <li>{p.title}li>)}ul>
)
const PostsListWithData = lifecycle({
  componentDidMount() {
    fetchPosts().then(posts => {
      this.setState({ posts });
    })
  }
})(PostsList);
1
2
3
4
5
6
7
8
9
10
1
2
3
4
5
6
7
8
9
10

这一解决方案在一定程度上增强了函数组件的能力，但它并没有解决业务逻辑掺杂在生命周期中的问题。Recompose 后来加入了 React 团队，参与了 Hooks 标准的制定，并基于 Hooks 创建了一个完全耳目一新的方案。

这个方案从一个全新的角度解决问题：不是让函数组件去模仿类组件的功能，而是提供新的开发模式让组件渲染与业务逻辑更分离。设计出如下代码：

import React, { useState, useEffect } from 'react';
1
1

function App() {
const [data, setData] = useState({ posts: [] });
useEffect(() => {
(async () => {
const result = await fetchPosts();
setData(result.data);
}()
}, []);

return (

{data.posts.map(p =>
• {p.title}
)}

export default App;

使用场景

从上一部分内容的学习中，可以总结出：

• 在不使用 Recompose 或者 Hooks 的情况下，如果需要使用生命周期，那么就用类组件，限定的场景是非常固定的；

• 但在 recompose 或 Hooks 的加持下，这样的边界就模糊化了，类组件与函数组件的能力边界是完全相同的，都可以使用类似生命周期等能力。

设计模式

在设计模式上，因为类本身的原因，类组件是可以实现继承的，而函数组件缺少继承的能力。

当然在 React 中也是不推荐继承已有的组件的，因为继承的灵活性更差，细节屏蔽过多，所以有这样一个铁律，组合优于继承。 详细的设计模式的内容会在 05 讲具体讲解。

性能优化

那么类组件和函数组件都是怎样来进行性能优化的呢？这里需要联动一下上一讲的知识了。

• 类组件的优化主要依靠 shouldComponentUpdate 函数去阻断渲染。

• 而函数组件一般靠 React.memo 来优化。React.memo 并不是去阻断渲染，它具体是什么作用还记得吗？赶紧翻翻上一讲的内容再次学习下吧。

未来趋势

由于 React Hooks 的推出，函数组件成了社区未来主推的方案。

React 团队从 Facebook 的实际业务出发，通过探索时间切片与并发模式，以及考虑性能的进一步优化与组件间更合理的代码拆分结构后，认为类组件的模式并不能很好地适应未来的趋势。 他们给出了 3 个原因：

• this 的模糊性；

• 业务逻辑散落在生命周期中；

• React 的组件代码缺乏标准的拆分方式。

而使用 Hooks 的函数组件可以提供比原先更细粒度的逻辑组织与复用，且能更好地适用于时间切片与并发模式。

答题

相信通过以上的分析，当被问到这道面试题时，你已经知道如何应答了吧。

作为组件而言，类组件与函数组件在使用与呈现上没有任何不同，性能上在现代浏览器中也不会有明显差异。

它们在开发时的心智模型上却存在巨大的差异。类组件是基于面向对象编程的，它主打的是继承、生命周期等核心概念；而函数组件内核是函数式编程，主打的是 immutable、没有副作用、引用透明等特点。

之前，在使用场景上，如果存在需要使用生命周期的组件，那么主推类组件；设计模式上，如果需要使用继承，那么主推类组件。

但现在由于 React Hooks 的推出，生命周期概念的淡出，函数组件可以完全取代类组件。

其次继承并不是组件最佳的设计模式，官方更推崇“组合优于继承”的设计概念，所以类组件在这方面的优势也在淡出。

性能优化上，类组件主要依靠 shouldComponentUpdate 阻断渲染来提升性能，而函数组件依靠 React.memo 缓存渲染结果来提升性能。

从上手程度而言，类组件更容易上手，从未来趋势上看，由于React Hooks 的推出，函数组件成了社区未来主推的方案。

类组件在未来时间切片与并发模式中，由于生命周期带来的复杂度，并不易于优化。而函数组件本身轻量简单，且在 Hooks 的基础上提供了比原先更细粒度的逻辑组织与复用，更能适应 React 的未来发展。

总结

经过本讲的学习，你可以掌握类组件与函数组件的区别，对于组件的方方面面都有了大概的认识。那么组件是通过什么模式来设计的呢？我将会在下一讲与你详细探讨。

《大前端高薪训练营》

精选评论

**辉：

我太菜了吧，还是没听懂改变小白小黄的例子，按这样岂不是说类组件更好，实时更新

**举：

类组件未来会用的更少对吧？hook 理论上可以让整个应用都使用函数式组件。

    讲师回复：

    是的，React 团队更倾向于推广 Hooks 来取代现有的模式，但 Hooks 这种模式能走多远还得看社区的使用与反馈情况。如果看过 React Future（https://github.com/reactjs/react-future）就会发现从现在去预估未来真的很难、很难预测未来 React 团队会不会又突然调整方向，在那之后当下的规划与流行在未来还会占多少。但从目前社区的情况而言，我感觉 Hooks 和类组件各占一半，暂时还难分伯仲。

console_man：

老师讲得清清楚楚，明明白白的。还有代码辅助。思路非常的清晰

    编辑回复：

    感谢反馈，加油，学完一定会有所收获的。

s(t)：

回复**辉，我在过去的某个节点想要获取user的信息就该获取过去的user，而不是最新的user。对应着ui=f(data)，只要输入不变，输出就是固定可预测的。过去的data对应过去的渲染结果。

**龙：

“那为什么会这样呢？因为当切换下拉框后，新的 user 作为 props 传入了类组件中，所以此时组件内的 user 已经发生变化了” 请问老师这里为什么函数组件没有接收到父组件传来的props啊？

    讲师回复：

    接收了，但函数 showMessage 和 handleClick 被调用时使用的是前值的引用。

**明：

Hooks 更易于 tree-shaking 是吗？

    讲师回复：

    tree shaking 只依赖于 ES2015 module 的结构，这个并不依赖于某种技术手段，完全依赖于代码的语法结构。
要说 hooks 更易于 tree shaking，我觉得缺乏依据。当然，如果有更好的案例说明，可以继续留言，感谢分享。
tree shaking 可以看一下 https://webpack.js.org/guides/tree-shaking/

**4829：

何为心智模型？

    讲师回复：

    引用唐纳德·诺曼的话来讲，就是“心智模型是存在于用户头脑中对一个产品应具有的概念和行为的知识。这种知识可能来源于用户以前使用类似产品沉淀下来的经验，或者是用户根据使用该产品要达到的目标而对产品概念和行为的一种期望。”
一个具体的例子而言，当我们习惯了左侧行驶方向后 ，突然去右侧行驶方向的国家，那么就需要重新建立心智模型。不光是行驶方向的区别，你的座位也变化到了右边，操作习惯，视野方向，都需要调整适应。
不知道这样的解释是否清洗，如果还有问题，欢迎继续留言。

*瑞：

对于本文的取props的例子。函数组件取到捕获值才是 React 的正确行为的吗？

    讲师回复：

    不能叫正确行为，应该是捕获的执行方式理解成本更低，用起来负担更轻。

**梁：

hooks出来后，慢慢的减少使用class组件了都

*康：

这个面试必考

    编辑回复：

    是的，老师讲的都是面试常考的