NgRx reducer中添加条件判断逻辑是否为良好开发实践？

你在reducer的on操作符中编写纯条件判断的写法是完全符合NgRx设计规范的良好实践，不需要把逻辑挪到side effect中。

• reducer的核心职责就是基于当前状态快照和传入的action计算新状态，只要逻辑保持纯函数特性——也就是无副作用、相同输入永远返回相同输出——在内部加状态更新的条件判断完全合理，根本不算反模式。你现在写的规则「仅当preferredLanguage还没被设置的时候，才用浏览器检测到的默认语言填充」本身就是核心的状态更新规则，本来就该归reducer管。
• 如果把判断逻辑挪到side effect中，反而会引入竞态漏洞：effect中读取状态、条件判断、派发action三个步骤不是原子操作。举个典型场景：effect刚读取到preferredLanguage为undefined，还没等派发action，用户手动切换语言的action已经完成处理，把preferredLanguage改成了用户选择的值，这时候effect延迟派发的browserLanguageSupported action还是会错误覆盖用户的选择，完全达不到你要的防覆盖目的。

你提到的「不确定能不能通过Angular服务注入设置feature state初始值」是完全支持的，不需要硬编码静态初始值。你可以通过工厂函数注入依赖来生成初始状态，参考写法：

import { createFeature, createReducer, on } from '@ngrx/store';
import { BrowserLangService } from './browser-lang.service';

export interface State {
  preferredLanguage: AppLanguage | undefined;
  rehydrationComplete: boolean;
}

// 初始状态工厂，可注入需要的服务
export const createInitialState = (langService: BrowserLangService): State => ({
  preferredLanguage: langService.getDetectedSupportedLang(),
  rehydrationComplete: false
});

export const languageFeature = createFeature({
  name: 'language',
  reducer: createReducer(
    on(LanguageActions.browserLanguageSupported, (state, { browserLanguage }) => {
      if (!state.preferredLanguage) {
        return { ...state, preferredLanguage: browserLanguage };
      }
      return state;
    }),
    // 其余action处理逻辑
  ),
  extraOptions: {
    initialStateFactory: createInitialState,
    // 声明工厂依赖的服务
    deps: [BrowserLangService]
  }
});

就算你用这种方式提前把浏览器检测到的语言设为初始值，也建议保留reducer里的条件判断作为兜底，避免hydration时序异常、服务初始化延迟等边界场景下的状态错误覆盖。

只有当判断逻辑本身需要引入副作用（比如需要调用本地存储、发送埋点、触发其他异步流程）时，才适合把判断逻辑放到effect中；纯状态更新规则的判断，全部放在reducer中实现即可。

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