功能与类组件作为容器组件

Question

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

编辑：这是因为我遇到的大多数（如果不是全部）容器组件都是类组件。鉴于容器组件的上下文，以问题的形式重新解释一下，使用功能组件而不是容器组件是否有益？

Answer 1

首先，React Hooks和useState是React的一个非常新的功能（类组件是最近3或4年的标准，而不是几个月的钩子），因此大多数文档和示例是使用类组件自然编写的。

第二，以我个人的经验以及官方文档中的内容而言，确实没有急于逃避类容器组件的困扰，尤其是因为编写良好，没有错误的代码更重要比最优化的最新代码。

我们公司的开发人员习惯于对容器的组件进行分类（我们有300,000个LOC React应用程序和1亿个用户，因此更改不会仅仅是因为是的-如果发生问题，我们通常会陷入严重麻烦）。

并且，到目前为止，“类组件”使我们能够轻松快速地回答以下问题：

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

我对个人项目慢慢采用了钩子，我真的很喜欢它们，但是即使在与它们玩了几个月之后，很多次我也无法想出“最佳实践”的做事方式，并且已经对此进行了记录在文档中也是如此：最佳做法只会随着时间而来。

性能方面

至于性能，几乎每页最多创建一次容器组件，或者最多创建几次，因此，如果代码编写得当，我不可能认为它们的性能会降低。

此外，基准测试基本上只是一个数字游戏（与CPU周期和相机百万像素相同），并且与posted here by Dan Abramov一样，基准测试显示的数字也差不多。

我了解人们迷上了数字（当我真正地热衷于照相机时，我非常痴迷于百万像素和镜头光圈，而且随着我的摄影技术变得越来越好，它变得很有趣而消失了。）

总结一下：

类容器的优点：

1. 更巩固的最佳实践和大量可靠的信息。
2. 由许多大公司进行测试和测试，并由开发人员提供担保。
3. 如果您喜欢Java中的类语法（我喜欢），则类容器可使代码更易读。

功能容器（带钩）的优点：

1. 更干净的代码（不再if props.fetched !== prevProps.fetched哈利路亚！）
2. 与Redux的useReducer和dispatch之类的库进行更好的集成（减少样板代码以及我非常不喜欢的HOC非常受欢迎）。
3. 在竞态条件下易于出错，我怀疑调试起来很容易，因为它们遵循非常清晰的功能范例。

同样，这绝不是事实上的标准，而是我基于经验的个人观点。接受您认为有用的内容，而忽略您没有的内容。希望这可以帮助！ ：）