组件等待Redux Action Creator返回Promise是否为反模式？

首先直接给结论：你现在的写法没有打破Redux的单向数据流，而且是完全被允许的，甚至是处理组件级UI状态（比如isSubmitting）的最佳实践之一。

为什么没有打破单向数据流？ #

Redux的单向数据流核心规则是：

UI 触发 Action → Reducer 更新全局 State → UI 响应 State 变化

你的代码完全符合这个逻辑：

1. 组件调用this.props.addStudent(values)，本质是触发一个Thunk Action；
2. Thunk内部先调用API，成功后dispatchaddStudentSuccess和fetchStudents这两个同步Action，更新全局store——这一步严格遵循了"Action驱动State更新"的单向流；
3. 组件用await等待这个异步流程结束，然后更新自己的本地isSubmitting状态——这个状态是组件私有的UI状态，和全局store的数据流无关，只是组件内部的状态管理行为，并没有让全局State反向流向UI或者直接修改全局State。

关于组件级UI状态的最佳实践 #

你提到的"把isLoading、isSubmitting这类状态放在组件本地"是完全正确的：

• 这类状态属于组件专属的UI状态，不需要共享给其他组件，放在组件state里能减少全局store的冗余，也让组件的状态管理更独立；
• Redux Thunk的设计本来就支持返回Promise，官方文档也明确提到可以用这种方式让组件知道异步操作的完成时机，所以这是官方认可的用法。

补充：有没有其他可选方案？ #

如果你担心组件和Thunk的耦合，也可以在Thunk里多dispatch几个Action（比如addStudentStart、addStudentSuccess、addStudentFailure），把isSubmitting放到全局store里。但这种做法反而会增加全局store的复杂度，因为这个状态只属于当前表单组件，完全没必要共享。你的当前写法更简洁，也符合关注点分离的原则。

总结一下：你的理解是对的（组件级UI状态该放本地），做法也是正确的（用await等待Thunk完成来更新本地状态），并没有违背Redux的单向数据流规则~

内容的提问来源于stack exchange，提问作者TTCG