Redux中数据sanitization逻辑应放在fat action creators还是fat reducers？

业内普遍更推荐将后端数据的解析、清洗（sanitize）逻辑放在action creators中，也就是fat action creators方案更符合最佳实践。

• 符合Redux的分层设计原则
  Redux的设计规范中明确要求reducers必须是无副作用的纯函数，仅需要基于传入的action和当前state计算新的state，不应该承担数据校验、格式转换的额外职责。如果将脏数据直接传入reducer再处理，不仅违背了reducer的设计定位，还会导致同一份清洗逻辑在多个处理同源数据的reducer中重复编写，复用性极低。
• 前置拦截问题，降低后续排查成本
  后端返回的原始数据在action creators中完成请求后第一时间做清洗，相当于在数据进入Redux数据流的入口就完成了质量校验，后续reducer、selector、业务组件接触到的全是符合预期的干净数据，不会因为脏数据引发连锁报错。出现数据格式问题时也只需要排查对应接口的action creators逻辑即可，不用在整个数据流链路中溯源。
• 更适配异常处理流程
  如果清洗过程中发现后端返回的数据完全不可用（比如核心字段缺失、结构完全不符合预期），可以直接在action creators中终止action派发，直接走报错、重试、兜底逻辑，避免无效数据进入store污染全局状态。

如果存在同一份原始后端数据需要供给多个reducer，且不同reducer需要的字段格式、转换逻辑差异较大的情况，可以将通用的基础校验（比如必填字段缺值兜底、非法值过滤）放在action creators中完成，再把半处理的数据派发给reducer做和自身state结构强相关的定制化转换，这一方案也在可接受范围内。

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