Which @angular/* package(s) are relevant/related to the feature request?
No response
Description
NG0953 warning causes me more harm than good. Assume I have a function inside my component that triggers 2 outputs one by one. In most recent case I had a date picker that emits dayClicked and then updates value model. The dropdown component that works with that date picker closes the dropdown which destroys the date picker which causes NG0953 warning because it the synchronously tries to update value model.
Proposed solution
I get that sometimes this warning highlights an unexpected order of things, but quite often this IS expected, we just don't care about that one last emit. To me it feels a lot like that takeUntilDestroyed issue that we had some time ago. If it was up to me, I would just throw this warning away, we didn't have it until signal outputs and we were fine. I would like to at least kick in the discussion with this issue, because I'm sure I'm not the only one annoyed by this.
Alternatives considered
In every code that has multiple outputs triggered I have to manually add isDestroyed guard for early returns after first output emitted, because I have no idea and no control over what happens after the first emit.
Which @angular/* package(s) are relevant/related to the feature request?
No response
Description
NG0953 warning causes me more harm than good. Assume I have a function inside my component that triggers 2 outputs one by one. In most recent case I had a date picker that emits
dayClickedand then updatesvaluemodel. The dropdown component that works with that date picker closes the dropdown which destroys the date picker which causes NG0953 warning because it the synchronously tries to updatevaluemodel.Proposed solution
I get that sometimes this warning highlights an unexpected order of things, but quite often this IS expected, we just don't care about that one last emit. To me it feels a lot like that
takeUntilDestroyedissue that we had some time ago. If it was up to me, I would just throw this warning away, we didn't have it until signal outputs and we were fine. I would like to at least kick in the discussion with this issue, because I'm sure I'm not the only one annoyed by this.Alternatives considered
In every code that has multiple outputs triggered I have to manually add
isDestroyedguard for early returns after first output emitted, because I have no idea and no control over what happens after the first emit.