Angular ESLint中prefer-signals规则对asReadonly信号的检查问题分析

问题背景

在Angular应用中，Signal API的引入为状态管理带来了新的范式。@angular-eslint/prefer-signals规则旨在帮助开发者正确使用Signal，避免常见的误用模式。然而，该规则在处理asReadonly()转换后的Signal时存在一个重要的检查遗漏。

问题本质

当开发者使用asReadonly()方法将一个可写Signal转换为只读Signal时，prefer-signals规则未能正确识别这种Signal声明，导致以下潜在问题：

class TestComponent {
  // 这里应该被标记为readonly但规则未检测到
  testSignal = signal(0).asReadonly();

  updateSignal() {
    // 虽然asReadonly()防止了值被直接修改，但引用仍可被替换
    this.testSignal = signal(1); // 这应该被规则捕获但实际未被检测
  }
}

技术影响

1. 引用安全性：asReadonly()仅保证Signal内部值的不可变性，但不保护Signal引用本身不被重新赋值
2. 设计意图违背：开发者使用asReadonly()通常意味着希望完全不可变，而规则未能支持这一意图
3. 潜在Bug：组件中Signal被意外替换可能导致难以追踪的状态问题

解决方案原理

该问题的修复需要扩展prefer-signals规则的检测逻辑，使其能够：

1. 识别通过asReadonly()转换的Signal声明
2. 对这些声明应用与直接声明为readonly相同的检查规则
3. 确保任何后续对Signal引用的重新赋值都会被标记为违规

最佳实践建议

1. 对于需要完全不可变的Signal，推荐同时使用readonly修饰符和asReadonly()：

class SafeComponent {
  readonly count = signal(0).asReadonly(); // 双重保护
}

2. 考虑使用自定义工厂函数创建真正不可变的Signal：

function immutableSignal<T>(initialValue: T) {
  return signal(initialValue).asReadonly();
}

class BetterComponent {
  readonly data = immutableSignal({}); // 更清晰的意图表达
}

总结

这个问题的修复强化了Angular ESLint对Signal使用模式的静态检查能力，特别是对只读Signal的完整保护。开发者应当理解asReadonly()与readonly修饰符的不同作用域，并在需要完全不可变的场景中结合使用两者。