Redux操作的命名约定，以区分请求和模型更新

假设我的Redux全局状态如下所示：

{
    micEnabled    : Boolean,
    filterEnabled : Boolean
}

React组件有一个“enablemic”按钮，单击该按钮后，应执行异步操作（可能需要一段时间），并通过承诺进行解析。为了运行这样一个异步操作，我可以在存储中添加一个定制的Redux中间件，或者使用

Redux-thunk

，等等。这不是问题所在

这里我的问题是：哪一个应该是“enablemic”单击时调用的Redux操作的名称

当不涉及异步内容时，通常将Redux操作命名为“setters”（

SET\u CURRENT\u TIME

）或表达式操作（

TOGGLE\u FILTER

），还原程序将直接使用它们来更新状态。因此，有人可能会建议我在上面的用例中使用

ENABLE\u MIC

，但事实是这样的操作（比如“操作1”）不应该直接更新

state.micEnabled

相反，我的Redux中间件将拦截操作1（

ENABLE_-MIC

），运行异步操作，并在解决后调度另一个Redux操作（“操作2”），以便相应的reducer将更新

state.micEnabled

。因此，“动作2”可以

MIC\u启用

总结如下：

• 单击按钮分派

  启用麦克风

• Redux中间件拦截它并执行异步操作
• 解决后，中间件调度

  MIC\u启用

• 减速器更新

  状态。已启用

好吧，这很有道理。问题是，在我的操作中，我还有大量的“常用操作”被分派到还原器以更新状态（例如

切换\u过滤器

）：

• 单击复选框dispatches

  切换过滤器

• Reducer更新

  状态。filterEnabled

因此，

ENABLE_-MIC

和

TOGGLE_-FILTER

都表示“命令”或“请求”，但还原程序只使用其中一个（

TOGGLE_-FILTER

）来更新状态。在另一侧，reducer还侦听已启用的

MIC_

操作（这不是“命令”或“请求”，而是已发生的事情或事件）

---

那么，通过查看我所有Redux操作的名称，有没有建议以一种可理解的方式命名这些Redux操作，我可以很容易地知道哪些更新了状态，哪些只是发送另一个操作？

将其视为AJAX请求，并将其称为

ENABLE\u MIC\u request

，这可能会导致

ENABLE\u MIC\u SUCCESS

或

ENABLE\u MIC\u FAILURE

（如果在您的场景中可能）。您可以使用名为

enableMic

的thunk在一个action creator中涵盖所有内容。这应该是相当透明的

只有

ENABLE\u MIC\u SUCCESS

才会在减速机中翻转

micEnabled

。我建议将其重命名为

isMicEnabled

btw，以便非常清楚它是一个布尔标志

---

处理

ENABLE_MIC_FAILURE

时，您可以显示错误消息，或者在应用程序中执行任何适当的操作。

好的，我将采用以下方法：将

actionCreators.js

拆分为

requestActions.js

和

stateActions.js

“请求操作”不由还原程序处理。取而代之的是，他们做一些API工作，最终可能会发送“状态操作”。“状态操作”根本不异步，只是由还原程序处理以更新Redux状态。谢谢。是的，这与我所发现的非常相似：在动作名称中有显式动词。在我的例子中，我选择了

MUTE\u-MIC

和

UNMUTE\u-MIC

请求操作，以及

SET\u-MIC\u-MUTE

/

SET\u-MIC\u-UNMUTE

作为减速机处理的操作。澄清一下：所有应该由减速机处理的操作都有一个名称，如

ADD\u-XXXX

，

REMOVE\u-XXXX

或

SET\u-XXXX\u-yyyyyyyy

。另一方面，必须由Redux中间件（包括Redux thunk）处理的操作的名称类似于

启用\u XXXX

，

更改\uxxxxx

，

创建\u XXXX

，

关闭\u XXXX

，等等。