NgRx Signal Store 中服务注入的循环依赖问题解析

问题背景

在使用 NgRx Signal Store 时，开发者可能会遇到一个棘手的问题：当尝试在 Signal Store 中调用注入服务的方法时，控制台会抛出"xxx is not a function"的错误。这个问题看似简单，但实际上涉及到了 Angular 依赖注入系统的深层机制。

典型错误场景

让我们来看一个典型的错误案例。开发者创建了一个 ContractStore，在其中注入了 ContractService，并尝试调用该服务的 sortContractsByFirstName 方法：

export const ContractStore = signalStore(
  {providedIn: 'root'},
  withState(initialState),
  withComputed(({contracts, searchQuery}) => {
    const contractService = inject(ContractService)
    return {
      sortedContracts: computed(() => {
        const sortedContracts = contractService.sortContractsByFirstName(contracts())
        return sortedContracts
      }),
    }
  })
);

表面上看这段代码没有问题，但实际上运行时却会报错"contractService.sortContractsByFirstName is not a function"。

问题根源分析

经过深入排查，发现问题根源在于循环依赖。具体来说：

1. ContractStore 注入了 ContractService
2. ContractService 又注入了 FilterModalStore
3. FilterModalStore 反过来又注入了 ContractService

这种循环依赖关系导致 Angular 的依赖注入系统无法正确实例化这些服务，最终表现为服务方法不可用。

解决方案

解决这类问题的关键在于打破循环依赖链。具体可以采取以下方法：

1. 重构服务职责：将共享逻辑提取到独立的服务中，避免服务之间相互依赖
2. 使用中间服务：创建一个新的服务作为中介，打破直接循环
3. 延迟注入：在真正需要时才获取服务实例，而不是在构造函数中注入

在上述案例中，解决方案是将 FilterModalStore 中的计算逻辑移到 ContractService 或 ContractStore 中，避免双向注入。

最佳实践建议

为了避免类似问题，建议开发者：

1. 设计清晰的依赖关系：在项目设计阶段就规划好服务之间的依赖方向
2. 避免双向依赖：保持依赖关系的单向性
3. 使用接口抽象：通过接口来解耦具体实现
4. 模块化设计：将相关功能组织到同一模块中，减少跨模块依赖

总结

NgRx Signal Store 是一个强大的状态管理工具，但在使用时需要注意 Angular 依赖注入系统的限制。循环依赖问题可能会导致难以调试的错误，如"xxx is not a function"。通过合理设计服务架构和依赖关系，可以避免这类问题的发生。当遇到类似错误时，开发者应该首先检查是否存在服务间的循环依赖，然后通过重构来解决问题。