函数组件与类组件作为容器组件

Question

我似乎找不到任何关于使用功能组件作为容器组件的利弊的材料，既然状态不是问题。

编辑:这是因为我遇到的大多数容器组件(如果不是所有容器组件)都是类组件。考虑到容器组件的上下文，以问题的形式重新表述这一点，相对于容器组件而言，使用功能组件是否有好处？

Answer 1

首先，React和useState是一个非常新的特性(类组件在过去3或4年中是规范的，而不是钩子的几个月)，所以大多数文档和示例都是自然地使用类组件编写的。

第二，在我个人的经验中，由于它是在官方文档中编写的，因此不急于逃离类容器组件，特别是因为--一个编写得很好、没有bug的代码--比最优化的、最新的代码更重要。

我们公司的devs习惯于对容器的组件进行分类(我们有一个30万LOC React应用程序和1亿用户，所以更改并不仅仅是因为是的--如果有什么东西坏了，我们通常会有很大的麻烦)。

和类组件现在允许我们快速回答这些问题：

1. 这个容器在哪里检查更改？检查ComponentDidUpdate()
2. 是否有任何内存泄漏或未处理的事件？检查ComponentWillUnmount()
3. 在这个容器中使用的状态变量是什么？检查constructor()

我慢慢地将钩子用于个人项目，我真的很喜欢它们，但即使在玩了几个月之后，我也想不出一种“最佳实践”的方法，这也在文档中得到了记录:最佳实践只能随着时间的推移而出现。

性能方面

至于性能，容器组件几乎从未在每页上创建过一次以上或最多几次，因此，如果代码编写得很好，我不可能认为它们的性能会更差。

此外，基准测试通常只是一个数字游戏(与CPU周期和摄像机超大像素相同)，而正如丹·艾布拉莫夫在此发帖一样，基准测试似乎显示了相似的数字。

我理解人们对数字的痴迷(当我真的对相机感兴趣的时候，我对超大像素和镜头光圈非常着迷，而且随着我的摄影技巧越来越好，有趣的是我的摄影技巧也渐渐消失了)。

总结一下：

类别容器的好处：

1. 更多巩固的最佳实践和许多良好的坚实的信息在那里。
2. 许多大公司试过并进行了测试，并得到了开发商的担保。
3. 如果您喜欢Javascript中的类语法(我喜欢)，那么类容器可以使代码更易读懂。

功能容器(带钩子)的好处：

1. 更干净的代码(不再有if props.fetched !== prevProps.fetched哈利路亚！)
2. 更好地与诸如Redux的useReducer和dispatch (锅炉板代码的减少，以及我非常不喜欢的HOCs )进行更好的集成是非常受欢迎的。
3. 由于它们遵循非常清晰的功能范例，所以不太容易发生争用条件，而且我怀疑它们更容易调试。

再说一次，这绝不是事实上的标准或任何东西，只是我个人经验的看法。把你发现有用的东西拿走，留下你不有用的东西。希望这会有所帮助！:)