Redux：将选择器导入操作？答案

【问题标题】：Redux: importing selectors into actions?Redux：将选择器导入操作？
【发布时间】：2017-11-11 02:41:43
【问题描述】：

似乎一致认为，如果动作创建者需要状态信息（并且我们希望独立于状态形状），调用动作的组件应该向动作提交所需的状态切片。参见例如丹·阿布拉莫夫的评论here

但是为什么我们不将选择器导入到动作中呢？

import { mySelector } from '../reducers';

const myAction = () => (dispatch, getState) => {
  const requiredState = mySelector(getState());
  etc...
};

看起来这至少可以节省一些通过组件往返的状态切片并解耦。

这样做有什么缺点？（除非动作不能导出ActionTypes。）

【问题讨论】：

标签： javascript reactjs ecmascript-6 redux react-redux

【解决方案1】：

是的，如果您要在您的动作创建者、thunk 或 saga 中访问存储状态，那么您应该使用选择器函数来封装查找过程。

您问题的另一方面是如果在动作创建者中访问商店状态是个好主意。丹对此有所保留，我理解他的来历，但从我的角度来看，这很好。我写了一篇博客文章，讨论了一些关于使用 thunk、sagas 和 state 的常见问题，名为Idiomatic Redux: Thoughts on Thunks, Sagas, Abstraction, and Reusability，并给出了我认为这些问题通常不是真正需要担心的问题的原因。

【讨论】：

链接中问题的核心有大量有用的想法。尽可能多地投票:)

【解决方案2】：

AFAIK 您提到的评论中的想法是将您的操作与状态“分离”。

将动作与应用程序状态解耦，从调用动作的地方获取您需要的数据，使动作不受状态限制。

通常解耦总是好事，有一些好处：

更易于维护代码和更改实现
更简单的单元测试。
减少操作的依赖性。

【讨论】：

但是，我们不只是将动作与组件逻辑紧密耦合吗？现在，使用该操作的每个不同组件都需要提供正确的，有时是相同的状态切片。这不是比使用选择器保持对“数据层”的依赖更脆弱和耦合吗？
@bebbi 应用程序可以使用“容器”，容器将调度动作而不是直接调度组件。 IMO 这与 React 中的无状态组件非常有效。
@bebbi 组件既不能绑定到应用程序状态，也不能绑定到状态逻辑。该组件仅显示数据并对用户输入/事件做出反应，并将访问状态和应用程序逻辑委托给容器。容器执行逻辑和调度动作，因此 reducer 可以改变状态。
感谢@GibboK。是的，我之前指的是容器。因此，在需要固定状态切片的操作示例中，您建议使用具有必要选择器的单个容器，并在需要该操作时将其与多个表示组件挂钩？