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.

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

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.

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

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.

when this feature will be merged ?

Another use case for this is a directive that has a default behavior, but allows a dev to specify their own handler to be used in place of the default by handling an output. With observed, you can use the presence of that handler to disable the default behavior. Without it, you need to the dev to also provide a boolean input to disable the behavior in addition to the output handler. Or even to hide a button that triggers an action if there's no handler for it. For example, a common component that displays a Share button only if I provide a (share) handler.

(removing this from v19 scope as we don't have sufficient alignment on whether or how we want to expose this option)

This is quite an artificial limitation.

We were using something like:

 if (this.create.observed) {
    this.create.emit({
      name: value.name,
    });
  } else {
    this.defaultHandler(value.name);
  }

I am surprised that this is no longer possible to do and requires an additional input.

@alxhub, any notes on the best practice here and why usage like this should be prevented?

Let's continue the discussion in #54837.

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}