【问题标题】:Reat - Components/Containers: One view, multiple actions?React - 组件/容器:一个视图,多个操作?
【发布时间】:2017-09-28 11:31:10
【问题描述】:

我会尽量简洁:我有一个过滤器视图(容器),它结合了像网格组件这样的愚蠢组件和结果,以及一个带有一些字段和操作(如提交)的表单组件。在这种情况下,存在一些疑问: - 如果我有一个组件(例如下拉菜单),它有自己的数据(一些东西的列表),它应该负责获取自己的数据还是应该委托给它的智能父级(过滤视图)? - 这个智能过滤视图有许多愚蠢的组件需要处理,所以,它是否负责传播这些组件所需的所有操作(例如:handleSearchClick、handleGridRowClick 等)?

如果是这样,那应该是最终的结构:

  • 过滤视图(智能)
    • 表单(愚蠢,从 FilterView 收到回调操作)
      • TextField(哑)
      • CustomerDropDown(智能?还是应该 FilterView 向它发送数据?)
    • 网格(哑,从 FilterView 接收回调操作)

我希望我已经很好地解释了我的意思。

提前致谢。

【问题讨论】:

    标签: reactjs components containers


    【解决方案1】:

    蓬松的问题得到蓬松的答案。

    对于如何找到智能/转储组件的最佳位置并没有真正的共识。有大量关于它的博客文章,甚至 React 文档对这个概念也很模糊。假设您使用像 Redux 这样的东西,我会说,不要害怕连接您的“更深”的组件。尝试使用更简单、更简洁的代码,这些代码易于查看和推理,而不是在这里遵循一些精确的科学。

    在我当前的项目中,我们之前是否遵循“自上而下传递所有数据”,现在我们已切换到将较低组件直接连接到需要它们的商店和操作。这感觉好多了,对我们来说效果很好。 其他人在 Redux 存储库的 Recommended usage of connect() 问题中很好地描述了我们的问题以及我们切换的原因。

    使用 Redux 和它的连接组件,更频繁地连接到状态没有实际成本,所以基本上这完全取决于您和您的遗产。

    即使您不使用 Redux,我相信这些博客文章和问题也可以帮助您。

    良好的阅读提示: Recommended usage of connect() #419

    Abramov´s Smart and Dumb components blog post

    【讨论】:

    • 您好 Per Svensson,感谢您的快速回答。这是我使用 React/Redux 的第二个项目,也是我第一个认真的项目。乍一看我没有意识到的一件事(在我深入研究问题之前我永远不会这样做),就是将这种容器/组件方法与更深层次的组件一起使用真的很棘手,而且搞砸整个事情的机会是真实的。我会看看你发送的github问题。我阅读了 Abramov 的帖子,但现在我意识到我错过了一个重要的部分:“这是一个持续的重构过程,所以不要试图在第一次就把它做好。”。再次感谢。
    • 您还可以在 github 问题中看到库创建者的观点发生了转变。早些时候,当 redux 出现时,只有自顶向下的方法,它甚至被钉在 React 文档中。现在 Redux 和 React 团队(现在都一样?;))都不提倡一种解决方案来统治他们。关于重构......哦,是的,我们也重构了很多。 :)
    猜你喜欢
    • 2016-04-26
    • 1970-01-01
    • 2023-03-07
    • 2015-03-05
    • 2016-01-16
    • 1970-01-01
    • 2016-06-04
    • 2017-11-22
    • 2015-10-23
    相关资源
    最近更新 更多