New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add observed property to OutputEmitterRef #54837
Comments
If we did expose such a property, it would probably be a |
It would be even better! |
What about |
The output would need to be required only when an input has a specific value (if I understand what is on your mind) |
Yeah, Now I see difrence, in your proposition it’s more about conditional required based on value of some input / directive. So yeah I will open new issue as both solutions solve difrent issues. Sory for clogging this issue |
Yeah, this is one of the follow-up's we did consider and would implement using a For the use-cases, we did see a similar pattern, especially with expensive subscriptions only being triggered upon "interest from the parent". The initial thinking still was that an input likely makes more sense here. Subjectively, it would seem confusing to me if the behavior of a component changes based on an output that I subscribe to. That is because "inputs" can "configure" the directive, but outputs simply emit values to the parent conceptually. It's more explicit and keeps the mental model simpler IMO. In either case, adding such a signal to OutputRef is trivial. |
One use case for this is wrapping third party (non angular) libraries. For example if such library allow binding to mouse move event and I want to allow my component user to add a (for example) chart mouse move output I will need to always listen to the third party event. If I could know if output was declared I could optimize and won't listen to that event unnecessarily. |
Very interesting issue. Thanks @GuillaumeNury for raising this. TL;DR: I wouldn't recommend changing I totally agree with @devversion on this except on this point:
where I think that this is not subjective, but really objective 😊 First, I think that it makes outputs align with DOM event listeners which do not affect DOM behavior. In the case of performance optimization, I think that That is why I'd generally recommend being explicit and use inputs in Guillaume's case. This way we can reduce the Meanwhile, if you really want to go with magic 😊, or if it is really needed to debug or optimize something, the solution could be a If some additional API should be added to |
As @Component({
standalone: true,
selector: 'app-child',
template: `
<h2>{{ actionEmitter.observed ? '👀' : '🙈' }}</h2>
<button
[disabled]="!actionEmitter.observed"
(click)="actionEmitter.next()">CLICK</button>
`,
})
export class Child {
actionEmitter = new Subject<void>();
action = outputFromObservable(this.actionEmitter);
} (observed is not a signal anymore but a regular boolean. Subject already track its observers) Stackblitz : https://stackblitz.com/edit/angular-output-snitching-wd3hf4?file=src%2Fmain.ts Thanks @yjaaidi for the pointer (and the stackblits)! As the workaround looks simple, maybe we can close this issue? |
Cool! Happy to hear that this works for you.
Not likely but still possible in case there is an imperative subscription (e.g. testing or Just an observation here for anyone reading this in the future. Not all observables have the |
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: angular#54837
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: angular#54837
Which @angular/* package(s) are relevant/related to the feature request?
core
Description
With the
@Output
decorator, I used to check theobserved
of theEventEmitter
(because it inheritsSubject
) to enable/disable some features.For example,
<lu-select (clueChange)="..." />
would display a search bar inLuSelect
component but<lu-select />
would not.This solution seems elegant as it avoid an additional input that would lead to unwanted cases:
<lu-select enableClue (clueChange)="..." />
and<lu-select />
would work<lu-select (clueChange)="..." />
would be useless because the search bar is not disabled becauseenableClue = false
<lu-select enableClue />
would be useless because the search bar is displayed, but nobody listen to its valueProposed solution
Add a
getter
propertyobserved
in OutputEmitterRef(in this file)
Alternatives considered
Replace existing usages of
emitter.observed
by inputs.The text was updated successfully, but these errors were encountered: