Ngrx多响应场景最佳实践：多Effect/Action/Reducer还是单一实现？

针对你遇到的GraphQL请求分两次返回数据（一次仅含customerDetail，一次仅含products）的场景，下面分析两种方案的优缺点，并给出实践建议：

方案一：多Action对应多Reducer #

核心逻辑 #

在请求Effect中调用服务后，根据返回数据的内容直接分发对应Action（如LoadCustomerDetailSuccess、LoadProductsSuccess），每个Action关联独立的Reducer更新对应状态；错误可共用或拆分对应Action。

优缺点 #

• 优势：
  • Action语义明确，从Action类型就能直接判断要更新的状态模块，调试时通过Action日志可清晰追踪每一次状态变更的触发源
  • 每个Reducer职责单一，仅处理对应模块的状态更新，符合单一职责原则，代码维护更清晰
• 劣势：
  • 会增加一定样板代码，每个数据模块需要对应成功、错误Action（可通过共用错误Action减少一部分）

方案二：单一Action对应单Reducer #

核心逻辑 #

请求返回后始终分发同一个Action，在Reducer中根据Action携带的数据（判断是customerDetail还是products）来更新对应状态。

优缺点 #

• 优势：
  • 减少Action数量，样板代码更少
  • 状态更新逻辑集中在单个Reducer中，无需跨多个Reducer维护
• 劣势：
  • Action语义模糊，无法从Action类型区分更新的是哪部分数据，调试时难以追踪两次数据更新的差异
  • Reducer职责变重，需要增加大量条件判断来区分数据类型，违反单一职责，后期逻辑复杂后易出问题

最佳实践建议 #

优先选择优化后的多Action方案，具体优化点如下：

• 去掉额外的过滤Effect，在请求的主Effect中直接判断返回数据：当数据包含customerDetail时分发LoadCustomerDetailSuccess，包含products时分发LoadProductsSuccess，避免中间环节的冗余代码
• 错误处理可共用一个LoadCustomerAndProductsFailed Action，在Reducer中根据需求更新对应模块的错误状态，无需为每个模块单独定义错误Action
• 状态设计上，可统一维护一个请求加载状态（如customerAndProductsLoading），避免为两个模块分别定义加载状态，减少状态冗余

这种方式既保留了多Action方案的清晰性和可追踪性，又通过直接在主Effect中分发对应Action的方式，降低了样板代码的冗余度，平衡了代码简洁性和可维护性。

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