[Code health] Verify usage of Rx side effects

There are some instances in the code in which we rely on doOnNext, doOnSuccess and other RX side effect operators.

In general, we should either avoid side effects entirely or ensure their usage is carefully prescribed.

Personally, I like treating anything that does not have to do with the direct manipulation of data (emitted items) as a side effect. For example, logging and UI changes would both be considered side effects from this perspective. I think this approach enables us to maintain clear separation between the actual ‘transformation’/ data-manipulating code and ‘side-effecting’ code like logging.

For our purposes, we only need to treat logging as a side-effect, since display related code is handled by fragments (and ideally live-data binding). The majority of cases in which we manipulate some piece of data in a doOn function can be expressed using transformations instead.

@gino-m

[gino-m]

Just came across this in Google Rx MVVM example:

https://github.com/googlesamples/android-architecture/blob/2e20b4a5deffb354f5ffa01c7f4448fd37acb6c3/todoapp/app/src/main/java/com/example/android/architecture/blueprints/todoapp/tasks/TasksViewModel.java#L77-L84

They’re using side effects for loading state indicator as well as errors. Arguably more readable than using a wrapper class, esp. since there’s no downside to doing so in this particular case afaict.

[gino-m]

Latest guidance is in our Wiki; let’s identify these as we go, closing for now.