Style guide wrongly suggests using native event names

[GiuseppePiscopo]

See this @angular/angular issue where discussion started.

At least the following two guidelines:

• https://angular.io/styleguide#!#05-12,
• https://angular.io/styleguide#!#05-13

seems to indicate that change is quite a valid name for a custom event. It turns out that's a very bad idea, as that is also the name of a native event and all sorts of issues come out of that.

I'd suggest totally changing that name into something else, non-native, e.g. pick or remove or whatever.

Also, there could be one more guide, still related to @Output names, clearly indicating that native event names should be avoided, maybe with a reference to some MDN/W3C page listing all of them (does it exist?).

[MilanLempera]

Some time ago, I run into the same problem - #2757.

List of events is available here: https://developer.mozilla.org/en-US/docs/Web/Events#Standard_events

There is a lot of events. For me, some prefix solution is better, because I am not able to remember all standard this event names. Moreover, in the future, some events can be added, which may lead to change a behavior of an existing application.

But prefixing is currently also mentioned as bad practice - https://angular.io/styleguide#!#05-16

[BrainCrumbz]

We are not adding the on prefix to @Output events, as we do that for the handler name instead. The way we solved it is to prefix event with component name. So for a change event in a ListItemComponent, we define something like listItemChange output event.

[wardbell]

I don't recall that style-guide says anything about how to choose input or output property names. There is nothing in those two links about it.

I suppose it is worth mentioning that one should use property names that do not collide with either a native property/event name or a property/event name used by any other component or directive (same reason). TBH, there are many ways to shoot yourself in the foot and if we tried to cover them all, we'd have a ridiculously, unreadable guide. TBH again, this particular issue has not come up often. Calling an event change is kind of asking for trouble. So I'm not feeling great urgency on this one.

I'll ask my colleagues for their opinion.

I'm reluctant to go beyond the advice to avoid collisions. We should take no position on prefixes. In particular, the on prefix is a personal decision; as noted, many developers like that for the handler, not the event. So I think we should stay away from any naming recommendation.

[BrainCrumbz]

@wardbell thanks for your feedback. In those links the proposed examples (even the blue "correct" ones) do name their event emitters as change and that happens more than once. So, well, they're definitely guiding readers into those troubles you mention 😺 :

    @Component({
      selector: 'toh-hero-button',
      template: `<button>{{label}}</button>`
    })
    export class HeroButtonComponent {
      @Output() change = new EventEmitter<any>();
      @Input() label: string;
    }

So while I totally agree that there should be too many wrong ways to mention, and I agree that everyone will have its take on prefixing, I'd say that:

• (like you say) docs could mention to pay some attention in choosing names so to avoid collisions, both with native and third-party properties/events
• at the very minimum, provided example should not be the first to fall into that trap

HTH

[webmozart]

What's the resolution here? What is the preferred way to systematically avoid naming collisions with native events?