我的意思是它们更像是事件而不是状态！
我不会这么说。我认为加载指示器是 UI 的一个很好的例子，它很容易被描述为状态的函数：在这种情况下，是一个布尔变量。虽然this answer 是正确的，但我想提供一些代码来配合它。
在async example in Redux repo，减速机updates a field called isFetching：
case REQUEST_POSTS:
return Object.assign({}, state, {
isFetching: true,
didInvalidate: false
})
case RECEIVE_POSTS:
return Object.assign({}, state, {
isFetching: false,
didInvalidate: false,
items: action.posts,
lastUpdated: action.receivedAt
组件使用来自 React Redux 的 connect() 订阅 store 的状态和 returns isFetching as part of the mapStateToProps() return value，因此它可以在连接组件的 props 中使用：
function mapStateToProps(state) {
const { selectedReddit, postsByReddit } = state
const {
isFetching,
lastUpdated,
items: posts
} = postsByReddit[selectedReddit] || {
isFetching: true,
items: []
}
return {
selectedReddit,
posts,
isFetching,
lastUpdated
}
}
最后，组件uses isFetching prop in the render() function 呈现“正在加载...”标签（可以想象，它可能是一个微调器）：
{isEmpty
? (isFetching ? <h2>Loading...</h2> : <h2>Empty.</h2>)
: <div style={{ opacity: isFetching ? 0.5 : 1 }}>
<Posts posts={posts} />
</div>
}
即使是更糟糕的情况，当我必须在 redux/react 应用程序中使用本机确认对话框或警报对话框时，我该怎么办？它们应该放在哪里，actions 还是 reducers？
任何副作用（显示对话框肯定是副作用）不属于 reducer。将减速器视为被动的“状态建设者”。他们并没有真正“做”事情。
如果您希望显示警报，请在调度操作之前从组件执行此操作，或者从操作创建者执行此操作。当一个动作被调度时，为了响应它而执行副作用为时已晚。
对于每条规则，都有一个例外。有时您的副作用逻辑非常复杂，您实际上想要将它们耦合到特定的操作类型或特定的减速器。在这种情况下，请查看像 Redux Saga 和 Redux Loop 这样的高级项目。仅当您对 vanilla Redux 感到满意并且遇到真正的分散副作用问题时才这样做，您希望使其更易于管理。