-
Notifications
You must be signed in to change notification settings - Fork 3k
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
delayWhen should use an indefinite delay for notifiers that complete without emitting #3665
Comments
So the semantics here seem off... The notifier completes without notifying, therefor the delay should last indefinitely. This isn't a bug with the library so much as it is with the usage. |
@benlesh The docs explicitly state that the notifier completing should cause the value to be emitted. |
🤦♂️ |
Okay, so we need to fix the issue, but deprecate the behavior. |
I have recently run into the same issue(s). Regarding the deprecationEven though there is a deprecation warning for Observable<never> this only works if the generated Observable is known to be of type never at compile time. Regarding the bugThe bug that the behaviour of the delayWhen operator depends on the truthiness of the source value persists as well. Here is a more concise version of the reproduction code:
|
@cartant how can we move forward with this? |
Hi guys! One more thought regarding the deprecation Can someone explain to me why the deprecated version of |
The generic is the type of the emitted values. void means it emits but without data, never means it never emits. |
Ah got it... Thanks @Airblader! So |
This is still an issue and we should resolve it before we release v7, IMO. |
- Resolves an issue where a duration selector that never emitted a value would cause the value to be emitted, even though there wasn't a "notification". - `delayWhen` is now based on `mergeMap`. I started off with trying to use `mergeInternals`, but quickly realized it was doing the same thing as `mergeMap`, and I could just use that directly. I'm not sure if this size optimization is "taking it too far", but I feel that `delayWhen` isn't exactly "hot path" code, so this optimization is fine, given the bundle savings it should yield. BREAKING CHANGE: `delayWhen` will no longer emit if the duration selector simply completes without a value. Notifiers must notify with a value, not a completion. fixes ReactiveX#3665
I've just spent a while tracking down an issue related to this. It appears that the documentation was not updated:
|
This looks to be still an open issue. Any solution? |
No one appears to be looking at this issue, so I've opened a new issue for it: #6977. |
This issue's title has been changed, as the implementation of
delayWhen
is not correct - see the discussion below.The original issue's description follows.
RxJS version: 6.1.0
Code to reproduce:
Expected behavior:
0
should be emitted and logged to the console.Actual behavior:
Nothing is emitted and logged to the console.
If the
of
function is passed1
instead of0
,1
is logged to the console.Additional information:
Looking at
delayWhen
, I can see another problem (other than #3663) with the implementation. If the value is falsy, and the notifier completes - rather than nexts - the value won't be emitted.The text was updated successfully, but these errors were encountered: