NgRx Signals 中引入 `watch` 函数的技术探讨

在 Angular 生态系统中，响应式编程一直是核心话题。随着 Angular 16 引入 Signals 作为响应式原语，开发者们开始探索如何更优雅地处理状态变化和副作用。NgRx 团队近期提出了一个有趣的技术讨论：在 @ngrx/signals 包中引入 watch 函数，作为对 Angular 原生 effect 的补充方案。

背景：Angular 的 effect 机制

Angular 提供了 effect 函数来处理信号变化的副作用。其核心特点是自动依赖追踪——任何在 effect 回调中同步读取的信号都会自动成为依赖项，当这些信号变化时，effect 会重新执行。

const count = signal(0);

effect(() => {
  console.log('count value', count());
});

这种隐式依赖追踪虽然强大，但在实际开发中却存在几个显著问题：

1. 异步依赖丢失：如果在异步操作中读取信号值，依赖关系不会被自动追踪
2. 依赖排除困难：需要使用 untracked 函数来避免不必要的依赖
3. 隐式依赖陷阱：任何同步调用的函数中读取的信号都会成为依赖

watch 函数的设计理念

watch 函数的核心思想是显式依赖声明。开发者需要明确指定要监听的信号，回调函数不在响应式上下文中执行，从而避免了隐式依赖的问题。

基本用法：

const count = signal(0);

watch(count, (value) => {
  console.log('count value', value);
});

多信号监听：

const count1 = signal(10);
const count2 = signal(100);

watch(count1, count2, (val1, val2) => {
  console.log(val1 + val2);
});

清理机制：

watch(count, () => {
  console.log('count changed', count());
  return () => console.log('cleanup');
});

技术对比：effect vs watch

特性	effect	watch
依赖追踪方式	隐式自动追踪	显式声明
响应式上下文	在响应式上下文中执行	在普通上下文中执行
异步依赖处理	需要同步读取信号	无此限制
排除依赖	需要使用 untracked	自动排除未声明的信号
代码可预测性	较低（依赖隐式追踪）	较高（依赖显式声明）

设计讨论与社区观点

这一技术讨论引发了 Angular 社区的广泛关注，主要观点分为两派：

支持方认为：

• 显式声明使代码更可预测和可维护
• 解决了 effect 的隐式依赖陷阱问题
• 与其他框架（如 Vue、SolidJS）的设计一致

反对方担忧：

• 增加 API 复杂度，可能造成选择困难
• 显式声明会增加样板代码
• 可能被滥用，导致不良实践
• 核心问题应该是减少副作用的使用

实际应用场景分析

1. UI 状态同步：当需要将信号状态同步到非响应式UI库时，watch 的显式声明更安全

2. 性能敏感操作：对于只在特定信号变化时才需要执行的昂贵操作，watch 能精确控制

3. 第三方集成：与非 Signals 系统集成时，显式依赖更可靠

4. 组合式工具函数：构建可复用的工具函数时，避免隐式依赖更可控

最佳实践建议

1. 优先选择：简单场景用 effect，复杂依赖用 watch
2. 副作用最小化：无论哪种方式，都应保持副作用精简
3. 组合使用：可以将 watch 与 computed 结合使用
4. 明确边界：在组件与服务间建立清晰的响应式边界

未来展望

这一讨论反映了响应式编程领域的一个永恒课题：如何在便利性与可控性之间找到平衡。无论 watch 是否最终被纳入 NgRx，它提出的问题都值得每一位 Angular 开发者思考：

• 我们如何更好地管理响应式依赖？
• 如何在框架提供的便利性与代码的可维护性之间取得平衡？
• 什么样的API设计最能引导开发者走向最佳实践？

这些问题的探索将继续推动 Angular 响应式编程模型的进化。