Angular ESLint 规则对信号式输入别名的支持

在 Angular 16 中引入的信号式 API 为开发者提供了新的方式来声明组件输入和双向绑定。随着这些新特性的加入，相关的代码规范检查工具也需要相应更新。本文将介绍 Angular ESLint 项目中关于信号式输入别名检查规则的演进过程。

信号式输入与模型简介

Angular 16 引入了两个重要的信号式 API：

1. input() - 用于声明组件输入属性
2. model() - 用于声明双向绑定属性

这些函数式 API 替代了传统的 @Input() 和 @Output() 装饰器，提供了更简洁的语法和更好的类型推断。

原有规则的限制

Angular ESLint 项目中原本有一个 no-input-rename 规则，用于检查传统的 @Input() 装饰器是否被不恰当地重命名。例如：

@Input('aliasName') propertyName: string;

这种重命名可能会导致代码可读性问题，因此该规则会标记出这种情况。

然而，随着信号式 API 的引入，开发者开始使用新的语法：

property = input('default', { alias: 'aliasName' });
property = model('default', { alias: 'aliasName' });

原有的 no-input-rename 规则无法识别这些新的信号式输入别名用法。

规则的演进

社区成员发现了这个问题并提交了 issue。经过讨论和开发，解决方案分为两个部分：

1. 首先扩展了 no-input-rename 规则以支持 input() 函数的别名检查
2. 随后考虑为 model() 函数添加类似的检查

在 Angular ESLint 的 v19 版本中，这个问题得到了完整解决。现在规则能够同时检查以下所有形式的输入重命名：

• 传统的装饰器语法 @Input('alias')
• 信号式输入 input(..., { alias: 'alias' })
• 信号式模型 model(..., { alias: 'alias' })

最佳实践建议

虽然技术上允许为输入属性设置别名，但通常建议避免这样做，除非有充分的理由。使用原始属性名可以提高代码的：

1. 可读性 - 开发者不需要记忆额外的别名
2. 可维护性 - 减少因别名导致的混淆
3. 一致性 - 保持代码风格统一

如果确实需要使用别名，建议：

1. 保持别名与属性名语义相关
2. 在团队内建立统一的命名约定
3. 添加清晰的注释说明使用别名的原因

总结

随着 Angular 信号式 API 的引入，相关的代码规范工具也需要不断演进。Angular ESLint 项目及时更新了 no-input-rename 规则，使其能够覆盖新的信号式输入和模型语法，帮助开发者保持代码质量。作为开发者，了解这些规则的变化并遵循最佳实践，可以编写出更健壮、更易维护的 Angular 应用。