我不明白的是智能/愚蠢的组件建议,并将提供商放在主要组件之上,并通过道具传递所有东西.如果我这样做,那么我需要把道具一直传递到第五个嵌套的项目,所以它可以做一个回调来派遣一个动作,或者看一些只有它需要的状态,而不是它的父母.我明白这是代码重用,但是子组件永远不会在主组件之外使用.这里推荐的解决方案是什么？仍然使用道具？
注意：这个库的作者要求我们在StackOverflow上提出问题.我提到这个,因为SO似乎标榜“最佳实践”的问题太模糊.
解决方法
你可以在任何级别使用connect().这样做使得组件变得聪明,因为它知道其道具来自哪里.一个愚蠢的组件只有道具,他们可以来自任何地方.智能组件耦合到redux;一个愚蠢的组件不是.
There are differing opinions on this approach,但它是支持和有效的.
绘制这条线的方法完全取决于你,但我们来看一个例子.您有一些聊天客户端,具有标准边栏组件,消息窗口和用于发送新消息的输入字段.
+---------+--------------------------+ | | | |Sidebar | Messages window | | | | | | | | | | | | | | +--------------------------+ | | New Message Entry **| | | | +---------+--------------------------+
所有这些的父级将使用connect()从redux获取数据,并通过道具将其馈送到这些组件中.现在想象,除了新的消息条目之外,这两个星号打开一个设置面板(忽略愚蠢的位置,这是一个例子).新消息输入通过这些道具是否真的有意义？不,没有.
为了解决这个问题,你可以创建一个特殊的“容器”,让它调用它使用connect()来获取它的道具的SettingsContainer,它所做的一切都将它们传递给了SettingsPopup. SettingsPopup不会了解redux,并且仍然可以正常测试/样式/重新使用,新的消息条目只需要了解关于SettingsContainer,而不是任何依赖关系.
这种方法很好,但它有两个惩罚.首先,必须由其他愚蠢的组件使用“设置容器”这样的智能“包装”组件.这使得新消息输入组件的测试变得复杂化.第二,顶级组件不再暴露数据依赖关系的整个图形,这使得事情更难于推理,而不深入到组件层次结构中.
这些权衡是值得的,但你应该意识到这些.
