This rule raises an issue when Angular output bindings (including aliases) are named using standard DOM event names like 'click', 'change', or 'blur'.

Why is this an issue?

Using native DOM event names for Angular output bindings creates confusion and potential conflicts in event handling.

When you name a custom output with the same name as a native DOM event, it becomes unclear whether you’re handling a native browser event or a custom component event. This ambiguity makes the code harder to understand and debug.

Additionally, this naming pattern can lead to unexpected behavior when the component is used, as developers might assume they’re binding to native events when they’re actually binding to custom outputs.

What is the potential impact?

This practice reduces code clarity and can lead to debugging difficulties when developers cannot distinguish between native DOM events and custom component events. It may also cause confusion during code reviews and maintenance.

How to fix in Angular?

Rename the output binding to use a more descriptive, non-native event name. Add a prefix or suffix to make it clear this is a custom component event.

Non-compliant code example

@Component()
class MyComponent {
  @Output() change = new EventEmitter<string>(); // Noncompliant
}

Compliant code example

@Component()
class MyComponent {
  @Output() valueChange = new EventEmitter<string>();
}

When using the new output() function, ensure both the property name and alias avoid native DOM event names.

Non-compliant code example

@Component()
class MyComponent {
  change = output<string>(); // Noncompliant
}

Compliant code example

@Component()
class MyComponent {
  valueChange = output<string>();
}

In component metadata, rename outputs to avoid native DOM event names.

Non-compliant code example

@Component({
  outputs: ['click'] // Noncompliant
})
class MyComponent {}

Compliant code example

@Component({
  outputs: ['buttonClick']
})
class MyComponent {}

Documentation