Hello devs, which one do you think it's better to be used and why? 1. private val stateData = Mutab...

# coroutines

[FunkyMuse]

Hello devs,
which one do you think it's better to be used and why?

1.
private val stateData = MutableStateFlow<State>(State.Idle)
val state: StateFlow<State>
get() = stateData

Or

2.
private val stateData = MutableStateFlow<State>(State.Idle)
val state: StateFlow<State> = stateData

[Lukas Sztefek]

It’s just about you convention and personal taste. I prefer:

private val stateData = MutableStateFlow(State.Idle)
val state: StateFlow<State> = stateData.asStateFlow()

The only reason – I don’t like syntax of getters and setters in kotlin.

[Javier]

asStateFlow doesn't let you cast to MutableStateFlow I think, so it is even better

[FunkyMuse]

That's a sweet solution too, i was wondering whether the getter has a performance impact rather than a plain val

[Lukas Sztefek]

I doubt it.

[Javier]

it should crash, but I didn't try it personally

[FunkyMuse]

It won't crash, I've tried both solutions i wrote above, I'm just wondering if the getter is slower due to it not holding the data once the mutable one is created but only when it's called and whether this imposes a space complexity since the val of immutable state flow is immediately created after the mutable state flow

[Javier]

I am not talking about get or assignment

[Javier]

I am taking about using asStateFlow or not

[Javier]

and trying to recast it to MutableStateFlow

[FunkyMuse]

You're not casting it to MutableStateFlow
You're exposing it as immutable StateFlow

[Javier]

yeah, I know

[Javier]

but if someone is mad, can try to cast it as MutableStateFlow

[Javier]

sample:

// ViewModel

private val _state = MutableStateOf(...)
val _state: StateFlow<> = _state


// Fragment

(viewModel.state as MutableStateFlow).value = ...

[FunkyMuse]

Oh well that's a mistake right there hah, I don't think this should be a matter of discussion?
Don't get me wrong, I'm trying not to stir this discussion aside

[Javier]

Someone said me that using asStateFlow you can't do that because it should crash. But I have never tried that casting personally, with our without asStateFlow

[Javier]

It should because it can be an additional argument to use asStateFlow instead of the other one

[Ruckus]

@FunkyMuse As an unrelated note, it's considered bad form to @ someone for a generic question like this that can be answered by anyone. There's no reason to expect Roman to personally answer your questions. You should probably refrain from doing it in the future, unless you really do need to specifically address that person.