是否有一个很好的经验法则来确定反应组件是否应该管理它自己的状态？

Question

我很反应，真的很享受。在创建组件时，在决定组件是否应该管理它自己的状态时，是否需要考虑一个好的经验法则（或简单的泛化）。

作为示例（仅作为示例），输入根据状态添加不同的类，如'hover'或'not empty'......

创建一个在内部管理这些状态的组件或者只是在我呈现输入的地方处理它会更好吗？

我知道这个问题可能是“主要基于意见”，但我希望能够对如何思考这个问题有一个普遍的感受。

提前致谢， -Ted

Answer 1

这是一场持续不断的内部斗争，你只能在线下做出决定而你是对的，它主要是基于意见的（这意味着没有答案是正确的）。但是，我可以分享自己的经验以及我决定如何拆分组件逻辑的过程。

我想到了这些事情：

• 拥有/没有这条逻辑如何影响单元测试？如果组件需要太多的设置来进行测试，那么我将一些逻辑移入它并远离父容器组件。
• 我多久会重复使用一次该组件？如果它经常多次，那么我会看一下可以渲染它的Container组件的类型，再看看是否需要太多的样板，然后移动逻辑。
• 值是通过自己的行为还是基于外部队列而改变？在您的悬停示例中，行为会因其自身的行为而发生变化，因此感觉类似于className（自身的支柱）对组件本身做出反应。
• 最重要的是，您是否从删除逻辑并将其放入Container中获益？如果您认为其他组件可以从了解输入字段的悬停状态中获益，那么您可能希望将逻辑放在容器中。否则你就会抽出太多东西。

应用程序状态管理库（如Redux）通常会建议尽可能少地使用它们的库，而是依赖于组件的内部状态。我之所以提到这一点，是因为当你弄清楚逻辑的位置时，你必须考虑最终目标，通常是创建一个Web应用程序，其中有多个组件协同工作。摘要太少，您最终创建不可重用的组件。摘要太多了，你可以通过使用内部状态来修剪大量的样板和配置。

Answer 2

Zeke有一些非常好的观点。我只想添加自己的指南，即：

• 如果组件的行为相同，无论它在何处使用，并且 与整个应用程序/环境的行为无关，那么请说明应该是内部的

• 否则，在其他地方管理州并传递道具