Angular：@Output() x: EventEmitter 和 @Input() 回调之间的权衡是什么？答案

【问题标题】：Angular: What Are The Tradeoffs Between @Output() x: EventEmitter & @Input() callback?Angular：@Output() x: EventEmitter 和 @Input() 回调之间的权衡是什么？
【发布时间】：2018-03-10 05:33:48
【问题描述】：

@Output() x: EventEmitter 和 @Input() 回调：函数之间的权衡是什么？

作为寻找解决方案的第一步，我已通读Angular2 why use @Output over @Input for callbacks。标题似乎问了同样的问题，不过，里面的问题在接受标准上相当浅，我的问题是在寻找更多细节。有关详细信息，请参阅下文。

[至少] 3 种方法可以在 Angular++（不是 1.x）中完成子对父通信，但为了更好地实现第 3 个选项，我只关心其中的 2 个问题：

使用EventEmitter 作为@Output

@Output() onEvent: EventEmitter<any> = EventEmitter<any>();

使用回调作为@Input

@Input() handleEvent: Function = new Function();

@Outputs 是自动可选参数/属性吗？
@Outputs 是否会在后台发出任何对 Angular 有帮助的信号？
是否存在垃圾收集问题？

总的来说，这两种方法之间的权衡是什么？

【问题讨论】：

标签： javascript angular typescript callback event-handling

【解决方案1】：

@Outputs 是数据流。它们本质上是Observables，上面有一些额外的爵士乐。 Angular 并不（立即）关注正在发出的数据。 Angular 将在内部使用 Output 挂钩来运行更改检测，主要用作子与父通信挂钩。

@Inputs 是属性绑定。 Angular 在后台做更多的工作来管理输入的更改检测，其行为可以通过ChangeDetectionStrategy 进行更改。 @Inputs 还必须在组件的生命周期挂钩开始触发之前由组件解析。 @Inputs 主要用作父子之间的通信。

将事件处理程序设置为@Input 不被认为是好的做法，并且违反了 Angular 风格指南。 Angular 已经对@Input 属性运行更改检测，并比较属性值何时更改。将输入设置为函数（并将属性绑定到函数）可能会导致更改检测无法预测。相反，在@Inputs 上使用getters 和setters 或使用ngOnChanges 挂钩来执行属性绑定更改的逻辑关闭。

还有将@Outputs 和@Inputs 组合成一个属性的用例（例如，[(ngModel)] ) 之类的香蕉盒语法。

如果您按照文档和推荐的方式使用 Angular 的 API，则无需担心内存泄漏。但是，您仍然有责任在组件销毁时清理其他订阅。

【讨论】：

很棒的答案。这涵盖了验证/使我的直觉无效以进行实施所需的大部分内容。谢谢。