Redux: 智能组件和哑组件之间的“快乐媒介”在哪里？

我们曾经说过，在早期版本的文档中减少连接的组件会更好，但是我没想到会有那么多的货运狂热。 😞是的，连接每个组件通常是一个过大的杀伤力，但是将所有组件置于首位！ 仅出于获取dispatch目的进行连接特别无害，因此您不必为此经常感到难过。

您的代码对我来说绝对不错。 👍

谢谢。 至少我现在有一个强有力的论点，认为我的代码很好，并且可能在更好的公司工作：)

但是，我仍然无法想象connect是过大的情况。 如何发展这项技能以知道我必须打破哪个规则，要么从不使用该数据的父控件传递数据到子控件，要么在代码中添加另一个connect （特别是如果它读取一小块数据）从商店）？

应用程序中的许多connect会出现什么样的问题？

Redux的订户通知过程是一个运行每个订户回调的简单循环，因此显然为O（n）。 从理论上讲，如果订户回调做的事情很复杂，或者订户数量非常大，这可能会成为性能问题。

在实践中，这可能不是什么大问题。 我怀疑您必须拥有数千个活动订阅，并且许多操作将分派一秒钟，才能真正成为问题。 目前，我还不知道有什么具体的基准可以证明这一点（除非最近的MobX / Redux比较可能有用）。

总体而言，我认为您应该遵循经典的“使其正常运行，使其正确，快速”的方法。 编写使您的应用程序功能正常工作的代码。 查看您编写的内容，并在需要时调整结构，这样更有意义。 如果看起来很慢，请进行测量和基准测试，并修复实际上很慢的零件。