-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
asSingle()
to automatically run take(1)
beforehand
#2595
Comments
Hey, thanks for the suggestion! When considering adding it implicitly we felt that it is too much of a "hidden contract" and we are potentially taking away elements from a source stream silently and dropping them without notifying the consumer, which is not something we want. |
Hi @freak4pc, thanks for quick answer :) To be honest, I would rather think the current For example, consider creating
And I think this logic will also be naturally applied to 1-element Also, for this behavioral breaking changes, my guess is that it is relatively safe without introducing any regressions. |
Another case study is, if we think about a "finite" observable that sends "1............Done!", then |
Thanks for the interesting feedback :) I prefer leaving the AsDouble case aside because it's not directly relevant to our case. Single and Maybe don't make any guarantees about the completion timing, it makes a guarantee about delivering a Single value, but it does mean the developer has to do the extra work here. In the case study you mentioned the problematic case is "1 ... (2... 3... 4..)... Done". If you take(1) implicitly you are dropping 2-3-4 and the developer might not know. What if they want the last element? What if they want one in the middle? We prefer leaving the explicit decision of this to the developer who know their own use case, and not make any assumptions inside the framework. |
I think how to pick 1st or non-1st element from multi-element observable for Considering my above case study of
If we apply your logic of "explicitly make sure the source only has one element", That said, we could perhaps rewrite your slogan as "explicitly make sure the source only has one element and completes immediately, just like how |
@inamiy If you want that sort of behavior, then you could use You see there are two issues around converting an Observable to a Single and you are only focusing on one. The other is "What if the Observable completes without emitting a value?" |
Hi @danielt1263 , zero-element observable to |
The point is The library gives you three options:
Given your case study above, you clearly want to use |
Another option would be to write your own custom operator. This is quite easy to do and I'd be happy to help you with it. All you need to do is specify how it should behave in all the scenarios. |
@danielt1263 |
P.S. |
Yes, let's go back to the original discussion. I don't think anyone would have an issue making their own operator to do
As I mentioned in my reply - I disagree with the way you see this. For example: with your implementation I would get "1.Done", but maybe that's not what I want. This puts the control in the developer's hands.
About this, what I usually do is let thing = await observable.first().asSingle().value Or drop the take(1) if I'm 100% sure it will terminate after 1 value (like a network request). |
And you seem to want |
I just realized that But I assume such breaking change is not possible soon, and we will need to let both @freak4pc In addition, current And as I mentioned in @danielt1263 's reply above, fully deleting unsafe |
I think the only thing we could do is add a clause in |
Interesting. So, my suggested change will eventually break their code, so I think I need to give up on proposal :( Thanks @freak4pc , @danielt1263 for discussion! |
Agreed. There are a number of ways to handle conversion from Observable to Single and we have operators to take care of the three most common. We haven't had any demand for the ones we don't cover. It seems the real problem here is a documentation issue. @inamiy whatever documentation that caused you to use asSingle instead of first might need some adjustment. Was that something in this library? If so, maybe you could submit a PR that updates the documentation. |
Current
observable.asSingle()
does not work as expected whenobservable
is an infinite stream sinceclass AsSingle
requires upstream's termination to actually send the value to the downstream.To workaround this, users always require to write
observable.take(1).asSingle()
, but it will be handy ifasSingle()
can automatically handletake(1)
.What do you think?
The text was updated successfully, but these errors were encountered: