Fluxor架构：是否应在不同Feature间共享Action？

不推荐直接在Feature 2中处理Feature 1的Action #

这种做法不规范，会破坏Feature之间的模块化隔离，导致代码耦合度升高。一旦Feature 1的Action结构或业务逻辑变动，Feature 2的Reducer必须同步修改，后续维护成本会大幅增加，违背了Feature拆分的设计初衷。

减少重复请求的更佳方案 #

1. 抽离通用逻辑到公共模块 #

把获取通用数据的Effect、对应Action（如fetchCommonData、fetchCommonDataSuccess）以及通用Reducer，整体迁移到项目的common或shared公共目录下，作为全局可复用的逻辑单元。所有需要该数据的Feature（Feature 1、Feature 2）都可以直接调用公共Action，数据存储在全局公共State中，从根源上避免重复请求。

2. 给原Effect添加缓存逻辑 #

如果暂时不想重构公共模块，可以在原Effect中加入请求判断逻辑：

• 在State中维护该通用数据的请求状态（比如idle、loading、success）
• 当Feature 2触发相同Action时，先检查State中是否已有有效数据，若存在则跳过服务器请求
• 示例伪代码：

export const fetchCommonDataEffect = createEffect(() => {
  return actions$.pipe(
    ofType(fetchCommonData),
    withLatestFrom(store$.select(selectCommonDataStatus)),
    filter(([_, status]) => status !== 'success'), // 已有数据则终止请求流程
    switchMap(() => {
      return api.getCommonData().pipe(
        map(data => fetchCommonDataSuccess(data)),
        catchError(err => of(fetchCommonDataFailure(err)))
      )
    })
  )
})

3. 通过状态选择器共享已有数据 #

无论通用数据逻辑是否抽离，所有需要该数据的Feature都可以通过**状态选择器（Selector）**直接读取已有数据，无需各自维护副本。比如在Feature 2中调用selectCommonData选择器，直接获取Feature 1 State中的数据，避免重复存储和Reducer耦合。

总结 #

跨Feature处理Action的做法不符合模块化规范，优先推荐将通用数据逻辑抽离到公共层；其次可以通过缓存机制减少重复请求，同时用选择器共享数据，既保证代码的可维护性，又能高效复用数据。

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