Angular项目中RxJS of操作符未触发UI变更检测问题

• Angular 基于 Zone.js 实现的变更检测只会对异步宏任务、微任务的回调执行做标记，同步执行的代码逻辑不会触发额外的变更检测周期。
• RxJS 的of(value)默认是同步发射值：当你在NgRx Effect中订阅这个流时，读取缓存、发射值、执行Effect逻辑、派发成功action、更新Store这整套流程全部在同一个同步执行栈内完成，Zone没有捕获到任何异步事件，Angular感知不到状态变化，自然不会刷新UI。
• 你加的delay(1)本质是把值的发射时机挪到了下一个宏任务周期，等当前同步栈清空后再执行后续逻辑，Zone能捕获到这个异步事件才触发了变更检测，但这种硬加延迟的写法属于hack，不是规范实现。
• 额外提一句：你在Effect中用from()包裹planetService.getPlanetsResponse()的返回值是冗余代码，该方法本身已经返回Observable，不需要再用from做转换。

不需要靠加延迟凑异步时机，以下方案都符合框架规范：

方案1：指定异步调度器发射缓存值（改动最小，最推荐） #

RxJS的of操作符支持传入第二个调度器参数，用asyncScheduler让缓存值走微任务队列发射，既可以被Zone正常捕获触发变更检测，又不会像delay(1)那样平白增加1ms延迟，是RxJS官方推荐的处理同步Observable兼容Zone的写法：

// 替换原有返回缓存的逻辑，记得从rxjs导入asyncScheduler
if (val) return of(val.value, asyncScheduler);

这个写法下缓存值的发射时机和HTTP请求返回值的发射时机完全一致，没有额外性能损耗。

方案2：调整缓存逻辑到NgRx层（符合架构最佳实践） #

当前你把缓存读写逻辑放在Service中，让Effect承担了读缓存的职责，更符合NgRx设计思路的写法是：

• 写一个全局缓存MetaReducer，或者在getPlanets action的reducer预处理逻辑中先读localStorage缓存
• 如果缓存存在且未过期，直接在reducer层更新Store状态，不需要走Effect发起HTTP请求
• 只有缓存不存在/过期时，才触发Effect调用接口，请求成功后同时写入缓存、更新Store
  这种写法从架构层面就避免了Effect中同步返回值的问题，不需要调整Observable的调度逻辑。

方案3：手动触发变更检测（不推荐） #

如果是局部组件的特殊场景，可以在组件中注入ChangeDetectorRef，在订阅Store数据流后手动调用markForCheck()标记需要更新，但全局缓存逻辑用这种方式会产生大量重复代码，维护成本高。

清理Effect中的冗余from包裹，简化后的Effect代码如下：

loadPlanets$ = createEffect(() =>
  this.actions$.pipe(
    ofType(getPlanets),
    switchMap((action) =>
      this.planetService.getPlanetsResponse(action.page).pipe(
        map((planetsResponse) => getPlanetsSuccess({ planetsResponse })),
        catchError((error) => of(getPlanetsFailure({ payload: error })))
      )
    )
  )
)

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