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
Calling to Observable.toBlocking(). Always a bad practice? #3956
Comments
However, if you are in the reactive world and suddenly want to use source.map(v -> someAPI(v).toBlocking().first())... Instead, you should be using any of the source.concatMap(v -> someAPI(v))... |
Thanks for the explanation David. |
I've got a question about this. In Android, shouldInterceptRequest on a WebClient requires a returned value, either null or a WebResourceResponse. I would like to avoid having a blockingFirst() call. Ideally I would like to pass a reference to the return value into the Observable chain and then make the decision on blocking later on. But I can't see how to do this. |
@tomgallagher almost always is. If you have something specific, please ask the wider audience of StackOverflow about it. |
OK thanks. |
Hi.
I have a library which returns observables. And I have another one which require to return the data in a synchronous way.
Particularly, I’m talking about OkHttp Interceptors. I need to retrieve the oauth token in order to add it as header. But this data comes from an observable.
Calling
toBlocking().first()
is the only way I can think to solve this problem. But I do not know if callingtoBlocking()
may have some unexpected effects (I mean I know that this observable resolves its task reading from disk or memory, so it is not a really heavy task). But because it seems to be not recommended to use it in production code, as a general rule.Thanks.
The text was updated successfully, but these errors were encountered: