feat(core): add observed to OutputEmitterRef

[arturovt]

Prior to this commit, it wasn't possible to check whether the output had any listeners (if it was being observed). Before output(), we could check whether EventEmitter had any listeners by checking its observed property.

In this commit, we convert listeners from a list to a signal so that we can have a computed observed signal.

This commit only updates the OutputEmitterRef implementation. We can't update OutputFromObservableRef because it expects an observable signature to be provided, and the observable doesn't technically have any API to count subscribers; only Subject does.

Please note that there have been different discussions on whether the OutputEmitterRef should be extended or not. This change is not considered breaking because the signature of the private property has been changed and another property has been added to the public API.

Related issue: #54837

[devversion]

I think we still want to discuss this change more— that's why we didn't create a PR for this. We are not aligned whether it makes sense to add this functionality, or if it just increases API surface unnecessarily and potentially even encourages non-ideal practices.

[devversion]

I think we should discuss more potential use-cases in the issue. So far, there wasn't too much interest IIRC.

[Harpush]

I think we should discuss more potential use-cases in the issue. So far, there wasn't too much interest IIRC.

Think about a component which has the ability to emit an output on every mouse move. If I knew no one listens to the output there is no reason to even add the event listener. Can really help with non angular third party libraries integration too.

[devversion]

@Harpush There are ways to address this issue, which may not be super common, looking at the issue interest— E.g.

1. Using an observable with outputFromObservable
2. Using an explicit input to control performance-sensitive outputs.

I'm not opposed against this property. It was something we considered during design, but simply wanted to collect more feedback. It's trivial to add

[Harpush]

@Harpush There are ways to address this issue, which may not be super common, looking at the issue interest— E.g.

1. Using an observable with outputFromObservable
2. Using an explicit input to control performance-sensitive outputs.

I'm not opposed against this property. It was something we considered during design, but simply wanted to collect more feedback. It's trivial to add

By using output from observable - only when someone subscribes (which is essentially the same as having a consumer to the output) the observable will actually register the event? What about multiple subscribers? Do I need to share it? Although the chance of multiple subscriptions is extremely low...
An input is always an option but a bit annoying as you let the consumer have control on an internal optimization he shouldn't know of...

[devversion]

By using output from observable - only when someone subscribes (which is essentially the same as having a consumer to the output) the observable will actually register the event? What about multiple subscribers? Do I need to share it? Although the chance of multiple subscriptions is extremely low...

Arguably, if you are thinking of optimizations like this w/r/t to e.g. a mouse event being expensive, you are likely also considering what would happen with multiple subscribers, or investing time to think how this can be solved.