Maybe a trivial question, but I often see people u...

# coroutines

[Lilly]

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?

[mbonnin]

Makes it easier to use Flow operators like retry , catch , etc...

[Lilly]

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

[Big Chungus]

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

[Big Chungus]

But that comes down to preference I guess

[Lilly]

Good point, thanks 🙂

[Marko Novakovic]

+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

[Lilly]

sometimes people use it just because it looks cool,

Yeah that's what I also thought first 😄

[Marko Novakovic]

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

[mbonnin]

Sometimes it can be cold too ahah!

[Lilly]

😏

[yschimke]

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

[Adam Powell]

If you want cold factories for an operation, suspend () -> T is right there

[Joffrey]

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.

[Joffrey]

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

@Big Chungus I do believe the opposite of this, so I guess yeah it's matter of preference. Using flows everywhere you can't know anymore what's supposed to give you a single value, or if this will be updated in the future and more values may come.

[mcpiroman]

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

[Adam Powell]

Or the Rx analogy, it would be like using Observable everywhere for consistency, even in places where Single or Maybe are a better fit

[Lilly]

Hmm also good points from @Joffrey Thanks for your thoughts

[yschimke]

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()

[yschimke]

I had a ViewModel with a cache User. A MutableState, that I populated with a coroutine launched in viewModelScope. I removed the State, just exposed the Flow, but annoyingly found it glitchy as each view would relaunch the flow. Suggestion from a coworker and glitch solved.

val me = dao.getMe().shareIn(viewModelScope, SharingStarted.WhileSubscribed(5000))

[Joffrey]

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.

[Joffrey]

Regarding your bug in the view model, I didn't quite get how it relates to the topic. If the UI needed reactive updates, then you should indeed be using flows. But that's not really about the design of the lower APIs.

[yschimke]

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.

[darkmoon_uk]

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 🙂

[darkmoon_uk]

I mean; it's not just to look cool 😎

[Lilly]

Thanks for your input guys 🙂