Angular中信号(Signal)与表单交互时的陷阱解析

在Angular 19版本中，开发者在使用信号(Signal)与表单交互时可能会遇到一个特殊的问题：当在窗口blur事件中更新信号值时，会抛出"NG0600: Writing to signals is not allowed in a computed"错误。这个问题看似简单，但实际上涉及Angular响应式系统的深层机制。

问题现象

开发者通常会这样实现一个监听应用状态的Service：

fromEvent(window, 'blur', { capture: true })
  .subscribe(() => this.testSignal.set(this.testSignal()));

当与表单禁用操作结合时：

signIn(): void {
  this.signInForm.disable();
}

在某些情况下会触发上述错误，特别是在涉及路由导航等复杂场景时。

问题根源

这个问题的本质在于Angular的响应式执行上下文：

1. 当表单禁用时，会触发DOM元素的disabled属性变化
2. 这会同步触发blur事件
3. 由于使用了{capture: true}，事件处理程序会在属性变更的同一调用栈中执行
4. 此时Angular正处于模板更新过程中，形成了一个特殊的响应式上下文

技术原理

Angular的信号系统有严格的使用规则：

1. **计算信号(computed)**中不允许写入其他信号
2. 模板执行期间也不允许直接写入信号
3. 事件监听器通常会在安全上下文外执行，但capture: true改变了这一行为

解决方案

方案1：使用untracked包装

fromEvent(window, 'blur', { capture: true })
  .subscribe(() => untracked(() => this.testSignal.set(this.testSignal())));

untracked会临时退出当前响应式上下文，允许安全地更新信号值。注意这与RxJS的unsubscribe不同，它不会阻止信号变更通知。

方案2：延迟执行

fromEvent(window, 'blur', { capture: true })
  .pipe(delay(0))
  .subscribe(() => this.testSignal.set(this.testSignal()));

通过delay(0)将信号更新推迟到下一个事件循环，避开敏感的响应式上下文。

最佳实践建议

1. 对于直接绑定到DOM事件的处理程序，考虑使用untracked包装
2. 避免在可能同步触发的事件处理程序中直接修改信号
3. 对于复杂的跨上下文信号更新，考虑使用服务封装
4. 在Angular 19+版本中，这个问题已经得到改善，但仍需注意类似场景

理解Angular响应式系统的执行上下文机制，可以帮助开发者避免这类隐蔽的问题，写出更健壮的响应式代码。