Comparing Input and Output Event Binding

Question

Comparing Input and Output Event Binding

Can you provide reasons why using @Output for events is more advantageous than passing an @Input function in Angular 2+?

Utilizing @Input:

Parent Template:

<my-component [customEventFunction]=myFunction></my-component>

Inside parent-component.ts:

myFunction = () => {
  console.log("Hello world")
}

Inside my-component.ts

@Input() customEventFunction: Function;

someFunctionThatTriggersTheEvent() {
  this.customEventFunction();
}

Opting for @Output:

Parent Template:

<my-component (onCustomEvent)=myFunction()></my-component>

Inside parent-component.ts:

myFunction() {
  console.log("Hello world")
}

Inside my-component.ts

@Output() onCustomEvent: EventEmitter<any> = new EventEmitter<any>();

someFunctionThatTriggersTheEvent() {
  this.onCustomEvent.emit();
}

Both methods achieve the same outcome, but it seems that the @Output approach is more commonly used in various Angular packages. Some may argue that with an Input, one can verify if the function exists before triggering the event conditionally.

What are your insights on this matter?

angular typescript angular2-components angular5 typescript-decorator

Answer 1

Answer №1

Benefits of using @Output event binding:

Utilizing @Output to define an event clearly indicates that it expects callback methods to handle the event, following Angular's standard mechanism and syntax.
Multiple event handlers can subscribe to the @Output event compared to defining an @Input property that only allows one callback function. Adding a second event handler with @Input would replace the first one, similar to setting onmousemove="doSomething()" in standard DOM event handling. In contrast, @Output event binding allows for multiple event handlers akin to calling
```
btn.addEventListener("mousemove", ...)
```
.

Answer 2

Benefits of using @Output event binding:

Utilizing @Output to define an event clearly indicates that it expects callback methods to handle the event, following Angular's standard mechanism and syntax.
Multiple event handlers can subscribe to the @Output event compared to defining an @Input property that only allows one callback function. Adding a second event handler with @Input would replace the first one, similar to setting onmousemove="doSomething()" in standard DOM event handling. In contrast, @Output event binding allows for multiple event handlers akin to calling
```
btn.addEventListener("mousemove", ...)
```
.

Answer 3

Answer №2

@Sajeetharan's response is not entirely accurate; there is indeed a significant functional discrepancy: the execution context. Let's examine this situation:

@Component({
  selector: 'app-example',
  template: `<button (click)="runFn()">Click Me</button>`,
})
export class ExampleComponent {
  @Input() public fn: any;

  public runFn(): void {
    this.fn();
  }
}

@Component({
  selector: 'app',
  template: `<app-example [fn]="myFn"></app-example>`,
})
export class AppComponent {
  public state = 42;

  // Utilizing arrow syntax will actually trigger an alert of "42" because
  // arrow functions do not possess their own unique "this" context.
  //
  // public myFn = () => window.alert(this.state);

  public myFn(): void {
    // This will unfortunately prompt an alert of "undefined" since this function
    // is executed within the child component's scope!
    window.alert(this.state);
  }
}

This can complicate the use of @Input() properties for passing functions, disrupting the principle of least astonishment and potentially introducing subtle bugs.

Naturally, there are situations where a specific context might not be necessary. For instance, in a searchable list component that accepts intricate data as items and requires a fnEquals function to determine if the search input text matches an item. Nevertheless, such scenarios are often better managed with more versatile mechanisms (like content projection, etc.), boosting reusability.

Answer 4

@Sajeetharan's response is not entirely accurate; there is indeed a significant functional discrepancy: the execution context. Let's examine this situation:

@Component({
  selector: 'app-example',
  template: `<button (click)="runFn()">Click Me</button>`,
})
export class ExampleComponent {
  @Input() public fn: any;

  public runFn(): void {
    this.fn();
  }
}

@Component({
  selector: 'app',
  template: `<app-example [fn]="myFn"></app-example>`,
})
export class AppComponent {
  public state = 42;

  // Utilizing arrow syntax will actually trigger an alert of "42" because
  // arrow functions do not possess their own unique "this" context.
  //
  // public myFn = () => window.alert(this.state);

  public myFn(): void {
    // This will unfortunately prompt an alert of "undefined" since this function
    // is executed within the child component's scope!
    window.alert(this.state);
  }
}

This can complicate the use of @Input() properties for passing functions, disrupting the principle of least astonishment and potentially introducing subtle bugs.

Naturally, there are situations where a specific context might not be necessary. For instance, in a searchable list component that accepts intricate data as items and requires a fnEquals function to determine if the search input text matches an item. Nevertheless, such scenarios are often better managed with more versatile mechanisms (like content projection, etc.), boosting reusability.

Answer 5

Answer №3

There are essentially no distinctions in terms of functionality, however

(i)When utilizing @input, you benefit from being able to specify the type and whether it is private or public

(ii)As pointed out by @ConnorsFan in the comment, a key advantage of using @Output is that multiple subscribers can handle the Output event, whereas only one handler can be provided for the @Input property.

Answer 6

There are essentially no distinctions in terms of functionality, however

(i)When utilizing @input, you benefit from being able to specify the type and whether it is private or public

(ii)As pointed out by @ConnorsFan in the comment, a key advantage of using @Output is that multiple subscribers can handle the Output event, whereas only one handler can be provided for the @Input property.

Comparing Input and Output Event Binding

Answer №1

Answer №2

Answer №3

Similar questions

Can you explain the true meaning behind this specific type definition?

Determine the route parameter name based on the path string, for example, '/posts/:id'

Dealing with inconsistent wait problems in Angular applications with Protractor and Jasmine

Functional interceptor causing Router.navigate() to malfunction

The form data consistently replaces existing values with each new entry added

The data retrieved from the web API is not undergoing the necessary conversion process

Angular and Spring setup not showing data despite enabling Cross Origin Support

Encountering a 'ng serve' error while trying to include a new SCSS style in an

Expanding and collapsing all nodes in Angular Material 6.0.1 Tree by default

When an item in the accordion is clicked, the modal's left side scroll bar automatically scrolls to the top. Is there a solution to prevent this behavior and

Ignore one specific file when importing all files in Angular 7

ngFor is failing to show the array data, which is being fetched from Firebase

Node.js has been giving me trouble as I try to install Inquirer

Updating the displayed data of an angular2-highcharts chart

Angular 2 and its commitment

Typescript is throwing a Mongoose error stating that the Schema has not been registered for the model

Is it possible to meet the requirements of a specific interface using an enum field as the criteria?

Send the component template and functions when triggering an expanded view in a material dialog

Steps to prevent uib-timepicker from automatically adjusting time based on the Browser Timezone

Transforming JSON into object instances with Angular