A modern programming language that makes developers happier.

kotlinlang

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

1.
private val stateData = MutableStateFlow&lt;State&gt;(State.Idle)
    val state: StateFlow&lt;State&gt;
        get() = stateData

Or

2.
private val stateData = MutableStateFlow&lt;State&gt;(State.Idle)
    val state: StateFlow&lt;State&gt; = stateData

It’s just about you convention and personal taste. I prefer:
```private val stateData = MutableStateFlow(State.Idle)
val state: StateFlow&lt;State&gt; = stateData.asStateFlow()```
The only reason – I don’t like syntax of getters and setters in kotlin.

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

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

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

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

I am taking about using asStateFlow or not

and trying to recast it to MutableStateFlow

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

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

sample:

```// ViewModel

private val _state = MutableStateOf(...)
val _state: StateFlow&lt;&gt; = _state


// Fragment

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


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

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`

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

<@UPV6JUB9B> 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.