NgRx Signals 中注入上下文到 onDestroy 的设计思考

在 NgRx Signals 项目中，开发者们正在讨论如何为 onDestroy 生命周期钩子提供依赖注入（DI）上下文的最佳实践。这一技术决策关系到信号存储（Signal Store）的生命周期管理方式，值得深入探讨。

背景与挑战

在 Angular 生态系统中，依赖注入是一个核心特性。然而，当涉及到生命周期钩子时，特别是在信号存储的上下文中，如何优雅地处理依赖注入成为了一个技术挑战。当前面临的主要问题是：onDestroy 钩子需要在注入上下文之外运行，这限制了开发者直接使用 inject() 函数获取服务的能力。

两种设计方案

社区提出了两种主要的设计方案：

方案一："Svelte 风格"闭包方式

withHooks((store) => {
  const service = inject(SomeService);
  // 初始化逻辑
  
  return () => {
    service.doSomethingAtTheEnd();
  }
})

方案二：显式生命周期钩子对象

withHooks((store) => {
  const service = inject(SomeService);
  
  return {
    onInit() {
      service.doSomethingAtTheStart();
    },
    onDestroy() {
      service.doSomethingAtTheEnd();
    }
  }
})

方案对比与技术考量

1. 一致性原则：方案二与 NgRx Signals 现有的 withMethods 和 withComputed API 设计风格保持一致，都采用了"DI访问+实现分离"的模式。

2. 扩展性考量：方案二为未来可能添加的其他生命周期钩子（如 onChange）预留了扩展空间，而方案一的闭包方式在这方面显得较为局限。

3. Angular 生态适配：方案二的 onInit 和 onDestroy 命名与 Angular 组件生命周期钩子保持一致，降低了开发者的认知负担。

4. 技术约束：两种方案都能解决注入上下文的问题，但方案二通过对象属性明确定义了不同生命周期的行为，代码结构更为清晰。

实现细节与演进

在技术实现过程中，团队还考虑了以下关键点：

• Store 传递方式：最终决定将 store 作为参数传递给 withHooks 函数，而不是各个生命周期钩子，这保持了与 Angular 生命周期钩子无参数的设计一致性。

• 防滥用机制：虽然无法完全防止开发者将初始化逻辑放在错误的位置，但可以通过代码规范和潜在的 lint 规则来引导正确用法。

• 类型安全：TypeScript 的类型系统确保了返回对象的正确结构，为开发者提供了良好的类型提示和编译时检查。

最佳实践建议

基于这一设计决策，建议开发者在实际项目中：

1. 将依赖注入的逻辑集中在 withHooks 的主函数体内
2. 将具体的初始化逻辑放在 onInit 方法中
3. 清理逻辑应当置于 onDestroy 方法
4. 避免在 withHooks 主函数体内直接执行业务逻辑

这一设计不仅解决了当前的技术挑战，还为 NgRx Signals 未来的功能扩展奠定了良好的基础架构。通过这种方式，开发者可以更自然地管理信号存储的生命周期，同时充分利用 Angular 强大的依赖注入系统。