Maybe a trivial question, but I often see people using

flow

operator for functions returning a single value. What's the purpose of doing this? Are there any benefits by doing this?

Makes it easier to use Flow operators like

retry

,

catch

, etc...

But if I don't need those, it wouldn't make any sense right?

It would for consistency. If you use flow elsewhere, your code will be much easier to parse and reason about if everything is done with flows

Good point, thanks 🙂

+1 to Martynas, also if you use libraries like… let’s say Room, that return single value but if you ask for

Flow

it will update regularly whenever dat changes. maybe you overlook something. sometimes people use it just because it looks cool, best to evaluate your own usecases

sometimes people use it just because it looks cool,

Yeah that's what I also thought first 😄

true 😄, looks cool and it’s latest hot topic in the community

Sometimes it can be cold too ahah!

😏

The cold point is valid, it's more powerful and arguably nicer API than a suspending function.

If you want cold factories for an operation,

suspend () -> T

is right there

Yeah honestly I don't buy the "flow for everything" approach at the moment. Suspend functions are really convenient. The caller can completely control how it's called. If you don't need an actual subscription with value updates, I don't quite see the point in using flow. It feels more like people coming from Rx are trying to match that model, rather than an actual convenience.

It is kind of as using `Any`everywhere for consistency

Or the Rx analogy, it would be like using

Observable

everywhere for consistency, even in places where

Single

or

Maybe

are a better fit

Hmm also good points from @Joffrey Thanks for your thoughts

I think the flexibility/ambiguity of flow is a feature, the API doesn't need to change later when you do find you need to subscribe for changes, but it's trivially convertible back to suspend with flow.first()

We might be talking about different things then. I mean that I really don't want to expose a flow that is defined this way:

flow { emit(callSuspendStuff()) }

. In this case, just expose the suspend function. If your function does support update events, then expose a

Flow

of course. And users can use the first value if they want, or subscribe for more. But if the flow is defined to emit only one element, this is basically lying in the API.

Good, point I lost the context of single value. But arguably, starting with an assumption of reactive flows all the way through, let's you handle the simple case, but also support reactive backends like Room also.

If I have a single asynchronous value, I'll default to representing that as a suspending function; but if it makes practical sense to bring that fully into a 'reactive system' as a

Flow

then that's okay too - it's not just to look cool 🙂

Thanks for your input guys 🙂