输入与输出事件绑定

Input vs Output Event Binding

我正在寻找关于为什么对事件使用 @Output 比在 Angular 2+ 中传递 @Input 函数更好的论据。

使用@Input:

父模板:

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

父级内部-component.ts:

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

我的内心-component.ts

@Input() customEventFunction: Function;

someFunctionThatTriggersTheEvent() {
  this.customEventFunction();
}

使用@Output:

父模板:

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

父级内部-component.ts:

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

我的内心-component.ts

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

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

两者实现相同的目标,但我认为 @Output 方法比我在其他 Angular 包中看到的更典型。有人可能会争辩说,如果只应有条件地触发事件,您可以通过输入检查函数是否存在。

想法?

功能上基本有no differences,但是

(i)当您使用 @input 时,您可以利用 @Input 是我们可以定义类型以及它是私有的还是 public

(ii)正如评论中提到的@ConnorsFan,使用@Ouput的好处是很多订阅者可以处理 Output 事件,而只能为 @Input 属性.

提供一个处理程序

@Output事件绑定的优点:

  1. 使用@Output 定义事件清楚地表明它期望回调方法使用标准 Angular 机制和语法来处理事件。
  2. 许多事件处理程序可以订阅@Ouptut 事件。另一方面,如果你定义一个接受回调函数的@Input属性,那么只能注册一个事件处理器;分配第二个事件处理程序会断开第一个事件处理程序。为了与标准 DOM 事件处理程序并行,@Input 回调函数绑定类似于设置 onmousemove="doSomething()" 而 @Output 事件绑定更像是调用 btn.addEventListener("mousemove", ...).

@Sajeetharan 的回答实际上并不完全正确: 一个显着的功能差异:执行上下文。考虑这种情况:

@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;

  // Using arrow syntax actually *will* alert "42" because
  // arrow functions do not have their own "this" context.
  //
  // public myFn = () => window.alert(this.state);

  public myFn(): void {
    // Oops, this will alert "undefined" because this function
    // is actually executed in the scope of the child component!
    window.alert(this.state);
  }
}

这实际上使得使用 @Input() 属性传递函数变得非常尴尬。至少它打破了最小惊喜原则并且可以引入偷偷摸摸的错误。

当然,有些情况下您可能不需要上下文。例如,也许你有一个可搜索的列表组件,它允许将复杂的数据作为项目,并且需要传递一个 fnEquals 函数,以便搜索可以确定搜索输入文本是否与项目匹配。但是,这些情况通常可以通过更可组合的机制(内容投影等)更好地处理,从而提高可重用性。