由于反应网络应用程序变得复杂，一些组件有一些道具，这些道具不太可读，更难以期待这个组件的作用，并且添加大量道具类型检查并将道具从最顶层组件传递到底层是繁琐的。这主要是由于传递了从上到下传递的flux / redux动作和存储。
有没有很好的方法来减少传入的道具数量？
我想到了两种解决方案，这些解决方案并不完美：
使用点差运算符{... props}传递道具。这确实减少了编写一些道具和道具类型检查，但命名时可能存在冲突，因此操作/存储的名称应该是唯一的。另一个缺点是要特别注意要传递的道具，以避免副作用。
使用容器直接连接组件，该容器以特定方式将操作/存储直接连接到组件。例如，可以使用react-redux的{{1}}。这比解决方案＃1更简洁，更简单，但如果组件由于Redux错误而包含容器，则很难编写组件测试。
错误的一个例子是
connect()
答案 0 :(得分：2)
你已经描述了两种方法及其优点和缺点。我将为你所说的内容添加一些设计考虑因素。
方法＃2是我的首选方法。减少通过组件的道具数量可以避免复杂性。有一些方法可以在不触发错误的情况下测试组件，但我认为值得拥有自己独立的Stack Overflow问题。现在，我只想说明浅层渲染，并考虑你是否真的需要在这里进行单元测试与集成测试。如果你也将在像Selenium这样的东西上创建自动化测试，那么也许可以作为你的集成测试。
方法＃1可以通过严格使用PropTypes来验证传递的内容来改进。将PropTypes检查放在只传递......道具的中间组件上是合理的，但是最终组件（实际使用道具而不是仅仅通过的组件）应该具有非常严格的PropTypes声明。使用Shape而不是Object。使用ArrayOf而不是Array，并且基本上将所有机会都放在PropTypes声明中。
关于您对名称冲突的关注，有时可以将道具组合在一起作为一个对象的成员，并将该对象作为单个道具传递。如果道具在概念上相关或具有单个目标组件，则这是有道理的。我仍然非常喜欢只有更多的容器组件（方法＃2），因为它导致更少的信息流过道具。为具有嵌套成员的对象编写好的PropType会花费更多的时间并产生需要更长时间进行故障排除的警告消息。
人们有时会在开始使用Redux / Flux后忘记.state，有些纯粹主义者喜欢通过商店发送和接收所有内容。无状态组件声明的优雅进一步使我无法在组件中添加.state。但.state非常适合跟踪动画和工具提示可见性等短暂内容。不是所有东西都需要在商店里并通过道具。