Am looking at some code like following a function in a view

Question

Am looking at some code like following a function in a view model that creates a `StateFlow` using `stateIn` which is called collected from Fragment seemingly it work but feels like there s an issue or at least some redundancy here but can t put my finger on why right now reason that s it s a suspend function instead of property is that it needs to call `suspendFunctionReturningFlowB` here but probably other ways around that ```suspend fun someFunction = flowA combine suspendFunctionReturningFlowB valA valB gt lt some logic gt stateIn viewModelScope SharingStarted WhileSubscribed 5000 null ```

John O&apos;Reilly · Answer

It at least seems like there would only by definition be one subscriber so perhaps use of `stateIn` etc redudant

yschimke · Answer

Yeah that would be my concern

yschimke · Answer

the function instead of typical val would lead to multiple calls to it each setting up the additional accounting work for state in and while subscribed

John O&apos;Reilly · Answer

yeah I guess the typical use of StateFlow would be a potentially self updating property

yschimke · Answer

I don t see why you can t just hide suspendFunctionReturningFlowB inside the body of a flow

yschimke · Answer

it doesn t have a param from someFunction It doesn t use results from flowA Seems perfect for that

John O&apos;Reilly · Answer

hmm perhaps `suspendFunctionReturningFlowB` returns a flow based internally though on call to suspend function and that returned flow is then combined with flowA

hfhbd · Answer

but `suspendFunctionReturningFlowB` should not be suspend at all No `Flow` returning function should be marked as `suspend`

yschimke · Answer

```val someVal = flowA combine flow emitAll suspendFunctionReturningFlowB valA valB gt lt some logic gt stateIn viewModelScope SharingStarted WhileSubscribed 5000 null ```

John O&apos;Reilly · Answer

No `Flow` returning function should be marked as `suspend ` Probably again can be done differently but that function is returning one of 2 flows based on result of call to a suspend function

John O&apos;Reilly · Answer

but I have seen that guidance as well but didn t see very clear explanation of reason for it

John O&apos;Reilly · Answer

< yschimke> yeah looks like that would work to

yschimke · Answer

Not sure about the rule but it s hard to reason about when these are mixed IMHO In the Flow world things should be cheap and usually not have side effects until you subscribe It s hard when APIs mix them Seen a few ListenableFuture apis that do blocking work then return Futures immediateValue x It s not that but I think the API types colors should make it clear exactly how to use it Would be interested to here the correct answer though

John O&apos;Reilly · Answer

Yeah agreed that it s much simpler if they re not mixed like that

hfhbd · Answer

You should wrap the suspend call in `flow if suspending emitAll flow1 else emitAll flow2 ` then slightly smiling face

uli · Answer

Maybe you can implement suspendFunctionReturningFlow wit h flatMapLatest