What are recommanditions for @Output event names (to prevent native event name collision)?

milanlempera picture milanlempera · Oct 27, 2016 · Viewed 11.5k times · Source

I have played with Angular 2 components and their compositions and I have run into ugly behavior, which is caused by native event bubbling and @Output name collision.

I have component app-form with form in template

<form (ngSubmit)="submitButtonClicked($event)">
  <input type="text"/>
  <button type="submit">Send</button>
</form>

I use this form component in app-middle component, which has own event emitter with name submit.

@Component({
  selector: 'app-middle',
  templateUrl: './middle.component.html',
  styleUrls: ['./middle.component.css']
})
export class MiddleComponent implements OnInit {

  @Output() submit = new EventEmitter<string>();

  constructor() { }

  emitSubmitEvent() {
    this.submit.emit("some data");
  }

}

template:

<div>

  <app-form></app-form>

</div>

And app component with template:

<app-middle (submit)="submitListener($event)"></app-middle>

Now, submitListener will be called

  • when submit on app-middle is called (wanted behavior)
  • when form is submitted, because native event bubble to the top ("parasitic" behavior)

I suppose, "parasitic" behavior is based on DOM event bubbling. I can stop it by event.stopPropagation() in submitButtonClicked handler, but if I forgot stop it, I get pretty ugly errors.

Generally, I consider this behavior quite dangerous. If I am not wrong, every event binding expression handler can be potentially called "parasitically" by native event from inner components. if has same name as any of DOM events (https://developer.mozilla.org/en-US/docs/Web/Events) And I don't talk about forward compatibility....

Same problem you can see here: https://bitbucket.org/winsik/submit-event-issue/src

Did you run into this problem? How do you name your @Outputs?

Answer

simon picture simon · Jul 23, 2017

I'm prefixing @Output events with the name of my components, which seems to work pretty well and to provide a consistent and clear convention which avoids the problems you describe. For example, suppose I have a component named, e.g. TurnEditorComponent -- @Output events might be named turnEditorChange, turnEditorFocus, turnEditorBlur and so on.