具有另一个动作作为有效负载的 Redux 动作答案

【问题标题】：Redux action having another action as payload具有另一个动作作为有效负载的 Redux 动作
【发布时间】：2019-09-12 02:46:16
【问题描述】：

redux action A 可以将 action B 作为其有效负载吗？

我的用例是我正在尝试存储每个正在进行的 API 请求并以以下格式保存我的 api 状态：

type ApiState = {
    requests: { [id: string]: AnyAction }
    hasNetwork: boolean
}

requests 属性的键基本上是发起请求的操作type（例如USER_FETCH_REQUEST），值是操作（具有类型、有效负载、元数据的整个操作）。我正在使用redux-observable 过滤每个以type 结尾的动作_REQUEST（项目约定），然后，如果匹配，则调度一个新动作，该动作接收初始api请求动作作为参数（有效负载）并更新@ 987654328@与它。

简单示例：

const getUser = (id: string) => ({
    type: "USER_FETCH_REQUEST",
    payload: { id }
})

const addRequest = (action: AnyAction) => ({
    type: "API_REQUEST_ADD",
    payload: action
})

// somewhere in epic pipeline ("action" is result of getUser(id))
addRequest(action)

// resulting state
{
    "requests": {
        "USER_FETCH_REQUEST": {
            type: "USER_FETCH_REQUEST",
            payload: { id }
        }
    }
}

这样，如果我的应用程序脱机并且我在 ApiState 中有 5 个请求，我只需在保留网络后调度所有这些操作（因为操作应该包含正确完成请求所需的所有数据）。

我还在 _SUCCESS 或 _CANCEL 上清除这些请求，并在 _ERROR 上有一些自定义逻辑，但我只是好奇上述规范是否是反模式并且会导致不希望的应用程序状态？

【问题讨论】：

您需要小心保持与任何存储的操作的向后兼容性，这些操作可能会在谁知道未来什么时间被分派，否则保留操作日志或重播调用肯定是常见的使用 redux 处理离线模式的方法。

标签： reactjs redux react-redux redux-actions

【解决方案1】：

记录或存储操作列表根本不是反模式。 Time Travel，一个非常流行的 redux 用例，正是通过这个实现的。

但是我认为您上面的代码似乎有点过度设计。实现相同结果的一种更简单的方法是将您的操作修改为类似的内容

const getUser = (id: string) => {
  const action = {
    type: "USER_FETCH_REQUEST",
    payload: { id }
  }

  add_to_request_cache(action);
  return action;
}

或者，为了让这更容易，写一个动作创建器，比如

const actionCreator = (action: AnyAction) => {
  // Code that handles various types of actions like _REQUEST or _SUCCESS actions
  // add_to_request_cache(action);
  return action;
}

然后用 this 包装所有的动作。

【讨论】：