initially I thought the later is better, but when there are errors (e.g. api returns a http error st...

# rx

[iex]

initially I thought the later is better, but when there are errors (e.g. api returns a http error status) the observable aborts, so on the next button press, nothing will happen! To prevent this I can use onErrorReturn on the api observable(s) but this leads to a bit unwieldy chains in particular when there are several calls...

[Daniel Rodak]

The simplest solution would be to use RxBindings library made by Jake Wharton which allows you to simply RxView.clicks(button)
Otherwise, if you don't want to add any external library you could write your own implementation of the clicks method which would based on the PublishSubject .
I'm not exactly sure how you should handle errors because it's based on the architecture that you are using. Personally, I'm using MVI and handling errors in the presenter/business layer.
Personally, I think that handling call by onErrorReturn is quite correct. You can add mapper for certain type of errors and then it's only a single method call inside error handler.
Also, wouldn't say that making a new subscribtion for each button press is a good practice.

[ursus]

Doesnt matter, unless you want to control the concurrent requests somehow - swtiching or concating them etc

[iex]

@Daniel Rodak that's informative, but it doesn't answer the question. If you just use onErrorReturn it means that you're creating a new subscription per click, since the observer chain is aborted.

[iex]

@ursus that's the feeling I have. A single subscription seems more rx-like, composable, etc. but there's no practical difference if it doesn't have to be reused.

[iex]

not entirely sure about the difference between using switchMap to discard a possible ongoing request and cancelling the current subscription though.

[Daniel Rodak]

@iex sorry, misnamed. I meant doOnError

[iex]

and how do you prevent the chain from being aborted? doOnError doesn't do this afaik