我应该如何将redux与不会被重用的嵌套子组件一起使用？ [英] How should I use redux with nested subcomponents that won't be reused?
问题描述
我正在研究一个包含许多子组件的组件，其中一些子组件嵌套了五个子组件。我有兴趣使用redux来获得在共同状态原子中具有单一真实来源的优势。
I'm working on a component that has many subcomponents, some of which are nested five deep. I'm interested in using redux for the advantage of having a single source of truth in a common state atom.
我不理解的是聪明/愚蠢的组件推荐，并将提供者置于主要组件之上，并通过道具传递所有内容。如果我这样做，那么我需要将道具一直传递到第五个嵌套项目，这样它就可以进行回调以调度一个动作或查看只有它需要的状态，而不是它的父项。我理解这是用于代码重用，但子组件永远不会在主组件之外使用。这里推荐的解决方案是什么？仍然使用道具？
What I'm not understanding is the smart/dumb component recommendation and putting the provider above the main component and passing everything down via props. If I do this then I'd need to pass props down all the way to the fifth nested item so it can make a callback to dispatch an action or to look at some state that only it needs and not its parents. I understand this is for code reuse, but the subcomponents will never be used outside of the main component. What is the recommended solution here? Still use props?
注意：此库的作者要求我们在StackOverflow上提问。我之所以提到这一点，是因为SO似乎将最佳实践问题标记得太模糊了。
Note: the author of this library requested we ask questions on StackOverflow. I'm mentioning this because SO seems to flag "best practice" questions as too vague.
推荐答案
虽然answer matt clemens确实涵盖了这一点一个很高的水平，但我会在这里尝试更深入。
While the answer matt clemens posted does cover this at a high level, but I'll try to go into more depth here.
你可以使用 connect（）任何级别。这样做会使组件智能，因为它知道 props 的来源。 dumb 组件只有 props ，它们可以来自任何地方。智能组件耦合到redux;一个愚蠢的组件不是。
You can use connect() at any level. Doing so makes the component smart, since it knows where its props come from. A dumb component just has props, and they could come from anywhere. A smart component is coupled to redux; a dumb component is not.
那里对这种方法有不同的看法，但它是受支持和有效的。
There are differing opinions on this approach, but it is supported and valid.
在哪里绘制这条线完全取决于你，但让我们看一个例子。您有一些聊天客户端，其标准侧边栏组件，消息窗口和用于发送新消息的输入字段。
Where to draw this line is entirely up to you, but let's look at an example. You have some chat client with a standard sidebar component, a message window, and the entry field for sending new messages.
+---------+--------------------------+
| | |
|Sidebar | Messages window |
| | |
| | |
| | |
| | |
| +--------------------------+
| | New Message Entry **|
| | |
+---------+--------------------------+
所有这些的父级将使用 connect（）从中获取数据redux并通过道具将它们送入这些组件。现在想象除了新消息条目之外的那两个星号打开一个设置面板（忽略愚蠢的位置，这是一个例子）。 新邮件条目传递这些道具是否真的有意义？不，它没有。
The parent of all of these would use connect() to get the data from redux and feed it into these components via props. Now imagine that those two asterisks besides new message entry open up a settings panel (ignore the stupid placement, this is an example). Does it really make sense for new message entry to pass those props through? No, it doesn't.
要解决此问题，您可以创建一个特殊的容器，让我们称之为 SettingsContainer 使用 connect（）来获取它的道具，它所做的只是将它们传递给 SettingsPopup 。 SettingsPopup 不知道redux，仍然可以正常测试/样式化/重用，新的消息条目只需知道 SettingsContainer ，而不是它的任何依赖。
To solve this you could create a special "container", lets call it SettingsContainer that used connect() to get its props and all it did was pass them down to SettingsPopup. SettingsPopup would not know about redux, and could still be tested/styled/reused normally, and the new message entry would only need to know about SettingsContainer, not any of its dependencies.
这种方法可以很好地扩展，但它有两个惩罚。首先，像 SettingsContainer 这样的智能包装器组件必须由其他哑组件使用。这使新消息条目组件的测试变得复杂。其次，顶级组件不再公开数据依赖关系的整个图形，这使得在不深入研究组件层次结构的情况下更难以推理。
This approach scales well, but it has two penalties. First, the smart "wrapper" components like SettingsContainer have to be consumed by otherwise dumb components. This complicates the testing of the new message entry component. Second, the top-level component no longer exposes the entire graph of data dependencies, which makes things harder to reason about without delving deep into the component hierarchy.
这些权衡可能是值得的，但你应该知道它们。
These tradeoffs can be worth it, but you should be aware of them.
这篇关于我应该如何将redux与不会被重用的嵌套子组件一起使用？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
