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

Question

@Output() x: EventEmitter & @Input() callback: Function 之间的权衡是什么？

作为我寻找解决方案的第一步，我已经彻底阅读了Angular2 为什么使用 @Output 而不是 @Input for callbacks。标题似乎问了同样的问题，不过，其中的问题在接受标准方面相当浅薄，我的问题正在寻找更多细节。请参阅下文了解此类详细信息。

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

使用EventEmitter作为@Output

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

使用回调作为 @Input

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

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

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

Answer 1

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

@Inputs是属性绑定。Angular 在幕后做了更多的工作来管理输入的变化检测，输入的行为可以通过ChangeDetectionStrategy. @Inputs还必须在组件的生命周期钩子开始触发之前由组件解析。@Inputs主要用于家长与孩子的交流。

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

还有一些用例可以将@Outputs 和@Inputs组合到单个属性中（例如，香蕉盒语法，如[(ngModel)] ).

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