如何在NgRx Signals中合理使用ScreenLockService锁屏？Hooks中用Effect是否正确？

我正在使用NgRx Signals，试图找到在特定操作期间利用ScreenLockService锁定/解锁屏幕的最佳方式。以下是我目前使用signalStore和服务管理屏幕锁定的实现代码：

export const BookStore = signalStore(
  withState(initialStore),
  withMethods((store,
               restService = inject(RestService)) => ({
    openModal: rxMethod<string>(
      pipe(
        tap(() => patchState(store, { isLoading: true })),
        switchMap((id) => {
          return from(restService.backendRestClient.getBook(id)).pipe(
            tapResponse({
              next: (books) => patchState(store, { books }),
              error: (err) => patchState(store, { error: err }),
              finalize: () => patchState(store, { isLoading: false })
            })
          );
        })
      )
    ),
  })),
  withHooks((store) => {
    const screenLockService = inject(ScreenLockService);

    return {
      onInit() {
        effect(() => {
          if (store.isLoading()) {
            screenLockService.lock();
          } else {
            screenLockService.unlock();
          }
        });
      },
    };
  })
);

我的问题： #

1. 在withHooks中使用effect调用screenLockService.lock()和unlock()是否是正确的做法？
2. 是否有更好的处理方案，比如避免将屏幕锁定直接与store状态耦合？

我正在考虑的方向： #

• 将屏幕锁定逻辑移至其他服务，在其中订阅store状态变化是否合适？
• 使用signalStore时，是否有更具声明性或集中式的方式管理屏幕锁定这类副作用？

问题1：在withHooks中用effect调用屏幕锁定是否正确？ #

这种做法可行但存在潜在问题：

• 优点：借助NgRx的effect自动追踪isLoading信号变化，无需手动管理订阅，逻辑集中在store生命周期钩子中。
• 缺点：把UI副作用（屏幕锁定）与store状态强绑定，导致store职责不纯——store原本应专注状态管理，现在额外承担了UI副作用触发逻辑；另外，若多个地方修改isLoading状态，都会触发屏幕锁定，可能出现非预期行为。

问题2：更好的解耦方案？ #

当然有，核心思路是让store只负责状态管理，将副作用逻辑剥离到专门层，以下是几种推荐方案：

方案1：将屏幕锁定逻辑封装到独立服务

创建ScreenLockManagerService，专门监听store状态变化并处理锁定逻辑：

@Injectable({ providedIn: 'root' })
export class ScreenLockManagerService {
  constructor(private bookStore: BookStore, private screenLockService: ScreenLockService) {
    effect(() => {
      const isLoading = this.bookStore.isLoading();
      isLoading ? this.screenLockService.lock() : this.screenLockService.unlock();
    });
  }
}

在应用初始化时（比如根组件ngOnInit）注入该服务，或通过APP_INITIALIZER初始化。这种方式的好处：

• 完全解耦store与屏幕锁定逻辑，store回归纯状态管理职责
• 锁定逻辑集中在专门服务中，便于维护和测试
• 可轻松扩展，比如添加防抖、过滤特定加载场景等逻辑

方案2：在方法中直接触发锁定（更具声明性）

如果屏幕锁定仅与特定操作（比如openModal）强相关，直接在rxMethod中处理副作用更直观，避免依赖isLoading状态的全局变化：

withMethods((store, restService = inject(RestService), screenLockService = inject(ScreenLockService)) => ({
  openModal: rxMethod<string>(
    pipe(
      tap(() => {
        patchState(store, { isLoading: true });
        screenLockService.lock(); // 操作开始时锁定
      }),
      switchMap((id) => {
        return from(restService.backendRestClient.getBook(id)).pipe(
          tapResponse({
            next: (books) => patchState(store, { books }),
            error: (err) => patchState(store, { error: err }),
            finalize: () => {
              patchState(store, { isLoading: false });
              screenLockService.unlock(); // 操作结束（无论成功失败）解锁
            }
          })
        );
      })
    )
  ),
})),

这种方式的优势：

• 副作用与触发它的操作直接绑定，逻辑清晰，避免全局状态变化带来的意外触发
• 无需依赖effect追踪状态，减少间接依赖

方案3：使用NgRx Effects（若项目仍用传统Effects）

如果项目同时使用NgRx Effects，可创建专门Effect监听特定动作（比如OpenModal），再处理屏幕锁定：

@Injectable()
export class ScreenLockEffects {
  lockScreen$ = createEffect(
    () => this.actions$.pipe(
      ofType(BookStore.openModal),
      tap(() => this.screenLockService.lock())
    ),
    { dispatch: false }
  );

  unlockScreen$ = createEffect(
    () => this.actions$.pipe(
      ofType(BookStore.openModal.success, BookStore.openModal.failure),
      tap(() => this.screenLockService.unlock())
    ),
    { dispatch: false }
  );

  constructor(private actions$: Actions, private screenLockService: ScreenLockService) {}
}

这种方式适合已使用传统Effects的项目，保持副作用管理的一致性。

总结建议 #

• 如果屏幕锁定是全局加载状态的通用副作用，推荐方案1（独立服务），解耦且集中管理
• 如果屏幕锁定仅与特定操作绑定，优先用方案2（在方法中直接处理），逻辑更直观
• 如果项目依赖传统NgRx Effects，方案3是更一致的选择

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