【发布时间】：2017-05-20 12:36:53
【问题描述】：
为什么是yyyyyyyyyyyyyy？
亲爱的读者，
我从高处和低处搜索过，但没有人能在没有信心的情况下解释这一点，只要说“这就是效果！”或“你就是这样做的！别问为什么！”
问题
class ChildComponent {
@Output selected: EventEmitter<T>() = EventEmitter<T>();
@Input item;
handleClick(e, t) {
...
this.selected.emit(t);
}
}
class ParentComponent {
items = [];
handleSelection(type) {
...
}
}
父模板
<child-component [item]="item" (selected)="handleSelection(item)" *ngFor="let item of items">
{{item.name}}
</child-component>
无论出于何种原因，没有人可以用任何抽象的东西来解释这种语法。每个答案都非常具体，以至于在组件级别定义事件的特殊性之外失去了任何意义，只有直接父级可以访问 - 而且，实际上没有任何理由 使用@Output/EventEmitter 而不是@Input/callback。
问题
@Output isThisAUselessVariable;
鉴于这个“输出”是未定义的——而且，与EventEmitter 无关——看在波塞冬的份上，我会怎么做呢？在这一点上，我什至可以用它做什么？现在完全没用了吗？如果它有一个值，但该值是 Array 或 Object 怎么办？ String 呢？ 我如何使用@Output 没有使用EventEmitter？
这似乎在这里像奇怪的问题，但我想避免回答“因为你可以用它来举办活动。如果你想要一个活动，就用这个！这就是你做活动的方式！为什么???我不知道！记住魔术事件语法就行了！”
其他问题和好奇心
一）
为什么命名为“@Output”？是什么让它成为“输出”？
二）
除了消息耦合的潜在好处之外，为什么不将@Input 与回调一起使用呢？
C）
消息是我使用@Output 的唯一原因吗？还有什么/可以用来做什么？ [ 看到' ]
D)
谁可以收听此事件？曾祖父母能否在不必将处理程序直接传递给子/曾孙并手动冒泡的情况下进行聆听？ [见'B']
E)
我习惯于消息传递是全局的或冒泡的，并且精心设计事件驱动架构以在应用程序规模而不是组件规模定义事件类型。这允许不同类型的“消息过滤”（参见维基百科），并允许我们使用应用程序中介。
为什么我想要在组件规模上使用它？如何在更大范围内定义事件并在更低范围内使用它们？
F）
我如何调解这些事件？ [见'E']
感激不尽，
科迪
【问题讨论】：
-
“而且，几乎没有任何理由使用
@Output/EventEmitter代替@Input/callback” 使用事件而不是回调的所有常见原因怎么样，例如如果您需要多个不是 1 的侦听器？ -
个人推荐 - 我建议提出问题而不是批评：“这是错误的。为什么有人会做错事？” 不会真正激励任何人接受回答问题的时间，更不用说 6 部分问题了。
-
这个问题太宽泛了……
-
另外，让你的标题不是一堆关键词；见How to Ask。
-
迈克，我想你的意思是深入。 Broad 类似于“我如何使用 TypeScript？”，它具有很大的广度。这个问题只是关于@Output。
标签： javascript angular typescript output eventemitter