使用 Redux 时在 React 视图中保留一些条件代码是一种反模式吗？答案

【问题标题】：Is it an anti-pattern to keep some conditional code in React views when using Redux?使用 Redux 时在 React 视图中保留一些条件代码是一种反模式吗？
【发布时间】：2017-10-09 06:41:44
【问题描述】：

我对使用 React 相当满意，但我对使用 Redux 时正确的方法感到困惑。外面的每个人似乎都在按照自己的方式做事。单击按钮时，我会在 React 视图中调用一个方法，例如：

handleClick(value) {
  this.props.action.handleValueChange(value);
}

现在我想在这个按钮点击上做更多的事情。那么我应该在触发的操作中还是在handleClick 方法本身中执行这些操作？

handleClick(value) {
  this.props.action.handleValueChange(value);
  // is this fine?
  if(this.props.someValue === "somethign")
    this.props.action.fetchSomeData(value);
}

我也可以使用 thunk 并在动作创建器本身中执行此操作，但推荐的执行方式是什么？

【问题讨论】：

可以更好地使用 mapDispatchToProps 来调度任何操作并使用 thunk 来进一步调度您的异步 api 调用，谢谢
如果我理解你，我在方法handleClick中所做的更好？
我认为当您使用 mapDispatchToProps 将您的操作与道具映射时，您可以轻松实现可维护和可读的代码。所以是的，handleClick 你的方式似乎更好，因为你没有在你的操作中添加任何组件特定的代码。

标签： reactjs redux react-redux redux-thunk

【解决方案1】：

从单一职责和纯函数的角度来考虑它。该方法应该处理点击并将其转换为下一个箍，就像在接力赛中传递接力棒一样。点击可以导致一个动作或一个状态改变的信号。当你开始使用这个词时，你会注意到事情变得过于逻辑繁重（这就像你的蝙蝠侠信号要模块化）：

获取用户输入
并将其保存到组件状态
并调用操作创建者
并获得回复
并将其保存到某个新状态
并重新渲染视图

考虑为您需要完成的每一件事都调用一个“哑”函数。他们的确切居住地取决于您。这与您记得学习数据库调用和“哑模型”时的逻辑相同，它们并不关心您对数据做了什么，他们只是得到他们被要求的东西。给他们输入，比如“get user id 1337”，他们会回答“here {}”或“no”。他们有一个责任，如果你重构他们周围的一切，他们就会坚持到底，直到“通过 id 获取用户”不再足够的那一天。

如果您追求纯粹性，这将使您的应用程序非常模块化。它可以在您的类中显示为很好的分段方法，或者您可以将每个函数导入其中。如果您想进一步阅读，您将从有关函数式编程的高级文章和视频中获得很多。倾听对他们重要的事情。您会注意到它允许出色的模块化架构，其中包含许多可重用的小代码片段。它是功能组合，但它也是对象组合。这些东西在 React 中也从未如此重要，因为如果你愿意，你可以在一个类中创建整个应用程序：)

Redux-thunk 适合，因为它是应用级别的状态。还有组件级状态，而不仅仅是容器状态。当你将 props 传递给一个哑组件时，它会将这些 props 作为它的“状态”工作，所以它就像 child #2。我相信你现在正在考虑层次结构。如果你从一个维度进入另一个维度，你的逻辑可能会过度扩展。也许逻辑可以询问它需要什么，并且单独的处理程序可以将处理程序加入其数据。

我要说明的一点是，我不会直观地查看handleClick 的内部，以便在数据从数据库返回时找到一些事件侦听器。任何超过 50 到 100 行的内容都会变得非常冗长，并且对于必须通读的人来说很费力。如果您稍后返回并将顶部连接到底部，其他人可能会称它为意大利面条，但如果您每个函数每个事件每个操作都有一个文件，他们就不能（其中每个函数都有一项工作，每个对象都有一个目的） )。

我并不是说它必须与此类似。我只是说模块化是王道，因为它使扩展、维护和重构变得容易。当我看到你的代码时，我需要吸收和预先加载我的短期记忆的越少，我就会越喜欢它。

这是一个我认为更喜欢的示例目录树，我希望说明一种思维方式，而不是一个精确的解决方案：

components/
    auth/
        auth_actions.js
        auth_types.js
        auth_reducer.js
        LoadingSpinner.js
        LoginForm.js
        SignupForm.js
        SplashScreen.js
queries/
    mongodb_checkIfEmailExists.js
    mongodb_getUserById.js
    neo4j_getUserByNodeId.js

现在，想象一下你的朋友正在和你一起工作。您正在处理登录视图，而她正在处理仪表板视图。您在同时工作时不会遇到任何文件冲突。当您查看文件时，您可能也很清楚发生了什么。您还会注意到您的所有导入都类似于 ./Something 而不是 ../../../actions。

我希望这是对思维方式的说明，而不是确切的解决方案。

【讨论】：