Hello Everyone, I wander if passing a flow or sta...

# coroutines

[Eslam Hussein]

Hello Everyone, I wander if passing a flow or stateflow as parameter in a method or class is good practice ?

class A(private val anyState:StateFlow<Int>){
   fun doSomething(state:StateFlow<String>){
   ......
   }
}

[Jakub Gwóźdź]

I wouldn’t pass a flow to be a member of a class, it looks like a recipe for having debatable fun.

But passing to a method for collection or modification? I think it’s ok, but I’d refactor it to extension function for flow to be the recipient, e.g.:

fun StateFlow<String>.doSomethingUsing(foo: Foo) { ... }

(after all, most of Flow API is exactly that - extension functions that do something on this flow and returns some result)

[Eslam Hussein]

that what I'm expecting thanks 🙂

[Erfannj En]

In my opinion, when it is necessary to encapsulate the logic of combining flows, why not?

[Erfannj En]

https://github.com/ErfanSn/AR-Touch/blob/master/producer/src/main/java/ir/erfansn/artouch/producer/DefaultTouchEventProducer.kt

[Casey Brooks]

I’d say it’s probably fine to pass in a StateFlow, since it’s designed to have multiple collectors. Multiple parts of your app might need to observe the same State property, and passing around the StateFlow is a perfectly acceptable use-case.

But passing a regular Flow could be problematic, since it will restart the entire flow for each Collector, but intuitively one might think the Flow is run only once and its values handled by multiple Collectors. Either pass in a SharedFlow to explicitly indicate a single Flow with multiple collectors, or pass in an object which can be used to create a new Flow, to make it explicit that each Collector is restarting the entire pipeline. For example:

public interface FlowCreator {
    fun newFlow(): Flow<String>
}

class A {
    suspend fun doSomething(flowCreator: FlowCreator) {
        flowCreator.newFlow().collect { }
    }
}

[Casey Brooks]

The difference of using the Flow/StateFlow as the Receiver vs passing it into a class is mostly semantics.

As a Receiver to a top-level function, it’s more commonly used for generic functionality which can be plugged into another pipeline. It’s an intermediate step of the Flow, or else it is a terminal operator but still needs to be run in some other coroutine which controls the lifecycle (for example, a ViewModel’s viewModelScope), but the operator itself it doesn’t really care exactly where it’s used.

Passing it into a function/class implies that the Flow is being collected in there. The lifecycle of the Flow, then, is related to that particular class/function. For example, passing a Flow into a ViewModel implies that the Flow will be collected in that ViewModel’s viewModelScope.