what do you guys think about code like this, is this kosher?

# rx

[ursus]

what do you guys think about code like this, is this kosher?

[trevjones]

all of those doOn calls are side effects which announce the status of the download. The single abstraction already provides you with downloading when it is non terminal, and failed when the single terminates with onError. idle is the absence of a single being executed.

also chatRepository seems like an odd place to track attachment download status. the name suggests that it houses chats, not manages stateful interactions for media downloads. is it named properly or is it doing too much?

[trevjones]

give this a watch

https://youtu.be/0IKHxjkgop4▾

[ursus]

Yea its not my code, its from a blog post, and I also feel weird about it, but then philosophically, what is a sideffect?

[ursus]

why is logging okay for sideffecting, while writing to a database isnt? its same thing just different target (console output vs db file)

[trevjones]

console output doesn’t dictate the forward behavior of the application

[trevjones]

the DB is state you care about the logs are not

[trevjones]

the video goes into some of that

[trevjones]

the philosophy of things anyway

[ursus]

hmm okay, ill give you that

[ursus]

so by your definition sideffects are "end" actions on whose results nobody depends on

[ursus]

althought, one could argue that writing a Completable to the database is sideffecting since it the end, no more transformations; technically callsites depends on some query observable of that repository

[trevjones]

yea I think that is what I said, probably not the right way to describe it. I was more trying to say that when I find myself using any of the doOn functions for something other than logging, I like to stop and ask myself if there is a better way for me to model this into the data type.

in your case the return type is a single so it isn’t bad.

[trevjones]

but you could make it an observable of some sealed class type that represents all those conditions as well as actively reports file transfer progress and push all of the chatRepo.doStuff into the .subscribe and hopefully contain all of your state mutation signaling to main thread which can really help with keeping behavior predictable

[ursus]

well, im more investigating what is the definition of sideffect, i.e. what does belong to doOn.. becasue when you think about it, its just some unrelated action, a "side thing"

[ursus]

but, you could also share the observable, subscribe to it once for the db writes, second time for the logging

[ursus]

so is "sideffect" just convenience api?

[trevjones]

🤷 https://softwareengineering.stackexchange.com/a/40314

[trevjones]

my thought is this. side effect imply’s some sort of mutability. mutability can make things hard to manage as a system grows. as a result I try to represent mutability as an observable of an immutable so that changes always get dispatched appropriately

[ursus]

true, but writing to a db is a mutating

[pg]

This therm isn't rx related to be honest. U can read about functional programming to learn what is side effect and what it can cause I think.

[ursus]

well it originates from functional but rx for sure uses the term, its even sometimes in the name - functional reactive programming

[pg]

FRP represents an intersection of two programming paradigms

[ursus]

so?

[pg]

I just suggest you not be confused by reactive programming vs functional reactive programming, nothing else. Cheers