Hey everyone. What’s the best way to filter nulls for StateFlow? I have this: ```private val _myFlo...

# coroutines

[Kurt Renzo Acosta]

Hey everyone. What’s the best way to filter nulls for StateFlow? I have this:

private val _myFlow = MutableStateFlow<String?>(null)
val myFlow: Flow<String> get() = _myFlow.filterNotNull()

But I want to expose the flow as a StateFlow to the consumer. I can use asStateFlow() but I can’t use filterNotNull() anymore as it converts it back to a Flow

[Manuel Wrage]

How should that work? The current value must be always present if you could do this what would be the initial value for the non null flow?

[Kurt Renzo Acosta]

Yeah the initial value would come asynchronously after a network call which is why it’s null. Would you suggest having it as an empty string instead?

[Manuel Wrage]

Yes this sounds like a good solution.

[Kurt Renzo Acosta]

But what if I have a pojo instead where I can’t just put out an empty string or a -1 for an int?

[Manuel Wrage]

Either create a dummy default value like you would do with string or just don't use an StateFlow at all. Is there a specific reason why you want this to be a StateFlow?

[Kurt Renzo Acosta]

correct me if i’m wrong but by my understanding, every consumption of the flow would create an instance of that Flow as compared to using StateFlow or SharedFlow where values are just replayed

[Manuel Wrage]

What about using a SharedFlow then?

[Kurt Renzo Acosta]

StateFlow is a SharedFlow that only holds one value

[Manuel Wrage]

Yes but if u use a SharedFlow you wouldn't need to provide an initial value but the flow would still be shared.

[Manuel Wrage]

Why you want the Flow to be shared?

[Kurt Renzo Acosta]

Ahhh you are right. Thanks for pointing me there. I’m gonna fiddle around with it

[Kurt Renzo Acosta]

I have multiple consumptions in my views.

viewModel.flow
    .onEach { ... }
    .launchIn(...)

viewModel.flow
    .combine(viewModel.flow2) { ... }
    .onEach { ... }
    .launchIn(...)

Again, if my understanding is correct, consuming both of those that way would run two instances of that Flow as compared with using StateFlow / SharedFlow which would just replay and share values so I saw it as a way to optimize things.

[Manuel Wrage]

Glad that i could help. Ok sounds like a reasonable reason.