In my App, I have an AppState. AppState contains `...

# flow

[Colton Idle]

In my App, I have an AppState. AppState contains currentUser = Flow<User>

Would this be better represented as a StateFlow?

[Erick Sumargo]

You need to elaborate a bit more what's the use case. But for short answer as long it fits your use case, why not.

[Francesc]

depends on your requirements. As a StateFlow you get an implicit distinctUntilChanged and it emits the current value when a new collector starts collecting, is that what you want?

I'm a bit puzzled by the "AppState" part though, if you mean a class that represents your UI state that the UI consume, then you should not have `flow`s here.

[DALDEI]

@Francesc could you elaborate on why you shouldnt have a flow in a UI State consumed by UI.

[Francesc]

Well, the state is going to be consumed in the UI, how would you consume a flow in there? Every time the state is emitted you would have a new flow, you'd have a flow inside another flow or inside a mutableState

[Colton Idle]

I'm not necessarily consuming it in my UI. But even if I was... why wouldn't I be able to do that?

In this case I just want to represent that my app has a user signed in or not, or if the user changes (user logs out and a new user logs in)

[DALDEI]

@Francesc -- I do not understand how this relates to UI or no UI. I do see its not obvious how to handle a state flow with its value another flow -- I suspect flatten() would work but not sure.
Howeve @Colton Idle if what your looking for is a state with the current users, and a way of notifying when the user changes, its simpler. Thats is a MutableStateFlow<User> NOT MutableStateFlow<Object containing FLow<User>>

say you have a 'cold flow' , maybe from callbackFlow<>(), OR you make a plain MutableStateFlow<User>()
and have code somewhere that does a flow.value=user
now you have a state flow which you can get the current user
flow.value == Current User
And you can be notified by
flow.onEach { gotanewuser(it) }.launchIn( scope )