我一直在努力寻找一种好的方法，用一种好的编码模式实现React中的组件。
通常我知道表示性组件和容器组件的概念：演示文稿仅显示html并接收来自 prop 的所有内容（数据和回调）;容器协调表示体检索和改变数据并通过 prop 将其传递给它们。
现在我使用redux工具包和rtk查询，以及钩子。
按照这种方法，容器组件应该是唯一允许useSelector、useDispatch和useQuery的组件。但是我发现，允许presentationals选择、获取和调度它们真正需要的东西要简单得多，也更干净，而不是创建一个巨大的容器组件，用一个巨大的状态列表和获取访问权限来管理其子组件的所有数据。对于列表来说尤其如此。在这种情况下，仅仅让每个子进程检索自己的数据（从状态中获取或检索），或者对于深度嵌套的表示形式，要容易和干净得多。
但是我把容器组件和伪表示混淆了，伪表示总是在更容易的时候检索一些东西，而真正的表示可能用于一般的和完全可重用的组件。而且组件树非常混乱（比如容器-〉伪表示-〉容器-〉伪表示-〉真正表示-〉真正表示...）。
最后，我觉得我没有好的规则，代码是混乱的。
容器和表示组件是否仍然是一种遵循最佳实践模式的良好编码风格，但在钩子和redux的世界里？
2条答案
按热度按时间h22fl7wq1#
自2018年引入React钩子以来，Dan Abramov所倡导的React容器模式就已经被弃用了。
参见丹2015年的博客条目Presentational and Container Components。
他2019年的更新：
2019年更新：很久以前我写了这篇文章，我的观点也随之发生了变化。特别是，我不建议再像这样拆分组件。如果你觉得这在你的代码库中很自然，这种模式可能很方便，但我已经见过太多次它在没有任何必要的情况下被强制执行，而且几乎是教条式的狂热。我发现它有用的主要原因是它让我把复杂的有状态逻辑从组件的其他方面分离出来，而钩子让我做同样的事情而不需要任意的划分。由于历史原因，这段文字保持原样，但不要太认真。
随着React钩子的出现，“智能”和“哑”组件之间的区别，以及“容器”和“表示”组件之间的区别几乎被消除了。
现在常见的模式和“最佳实践”是编写React函数组件，并且只使用React钩子。在使用Redux和React-Redux的情况下，使用
useDispatch和useSelector钩子而不是connect高阶组件。自从React钩子出现以来，我还没有特意编写React类组件或将代码在“表示”和“容器”之间拆分。rjjhvcjd2#
我的经验法则是在一个组件中完成这一切。然后当你创建越来越多的组件时，你会看到模式开始显现。所以，你可以做一个呈现组件，而不是从一个组件到另一个组件复制和粘贴代码。其中一些 prop 甚至可以是当一个按钮被点击或一个框被选中时要做什么。
总的来说，表示组件最终将类似于各种react js ui框架之一，比如https://mui.com/