在操作创建器中访问还原状态？

Question

说我有以下几点：

export const SOME_ACTION = 'SOME_ACTION';
export function someAction() {
  return {
    type: SOME_ACTION,
  }
}

并且在该操作创建器中，我想访问全局存储状态（所有还原器）。这样做是否更好：

import store from '../store';

export const SOME_ACTION = 'SOME_ACTION';
export function someAction() {
  return {
    type: SOME_ACTION,
    items: store.getState().otherReducer.items,
  }
}

或者这个：

export const SOME_ACTION = 'SOME_ACTION';
export function someAction() {
  return (dispatch, getState) => {
    const {items} = getState().otherReducer;

    dispatch(anotherAction(items));
  }
}

Answer 1

关于访问动作创建者中的状态是否是一个好主意,存在不同的意见：

• Redux的创建者Dan Abramov认为它应该受到限制：“我认为它可以接受的少数用例是在您发出请求之前检查缓存的数据，或者检查您是否经过了身份验证（换句话说，执行条件分派）。我认为在操作创建者中传递诸如state.something.items之类的数据肯定是反模式的，并且不鼓励这样做，因为它遮蔽了更改历史：如果存在bug，items是不正确的，那么很难跟踪这些不正确的值是从哪里来的，因为它们已经是操作的一部分，而不是由还原器响应操作直接计算出来的。所以要小心操作。“
• 当前Redux维护者Mark Erikson说，在thunks中使用getstate是很好的，甚至被鼓励的--这就是它存在的原因。他在他的博客文章“Idiomatic Redux：Thinks on Thunks,Sagas,Abstraction,and Reusability”中讨论了在action creators中访问状态的利弊。

如果你发现你需要这样做，你建议的两种方法都很好。第一种方法不需要任何中间件：

import store from '../store';

export const SOME_ACTION = 'SOME_ACTION';
export function someAction() {
  return {
    type: SOME_ACTION,
    items: store.getState().otherReducer.items,
  }
}

但是，您可以看到它依赖于store作为从某个模块导出的单例。我们不建议这样做，因为这会使向应用程序添加服务器呈现变得更加困难，因为在大多数情况下，在服务器上，您希望每个请求都有一个单独的存储。因此，虽然这种方法在技术上可行，但我们不建议从模块导出存储。

这就是为什么我们推荐第二种方法：

export const SOME_ACTION = 'SOME_ACTION';
export function someAction() {
  return (dispatch, getState) => {
    const {items} = getState().otherReducer;

    dispatch(anotherAction(items));
  }
}

它需要您使用Redux Thunk中间件，但它在客户端和服务器上都运行良好。您可以在这里阅读更多关于Redux Thunk的内容，以及为什么在这种情况下有必要使用Redux Thunk。

理想情况下，您的操作不应该是“胖”的，并且应该包含尽可能少的信息，但是您应该放心地在自己的应用程序中做最适合您的事情。Redux FAQ提供了关于在操作创建器和还原器之间拆分逻辑的信息，以及在操作创建器中使用getstate可能有用的时间。