Marcello Galhardo

    Marcello Galhardo

    10 months ago
    Hi! Does anyone know if there are downsides of using a
    MutableState
    and
    State
    inside a
    ViewModel
    ? For example, why would someone choose a
    MutableStateFlow
    in a
    ViewModel
    and do a
    collectAsState
    instead of simple using a
    MutableState
    at first place? 🤔
    b

    Brian G

    10 months ago
    State
    is fine to use, unless you are writing multiplatform code.
    State
    requires the Compose dependency, while
    Flow
    does not.
    E.g. if you want to reuse your ViewModel on iOS
    Marcello Galhardo

    Marcello Galhardo

    10 months ago
    I do plan to use KMM in this project but I’m not planning to share ViewModels. Interesting to know. 🤔
    Thank you @Brian G.
    e

    eygraber

    10 months ago
    I believe
    State
    is common code, so it could be used in a multiplatform project. One reason to use
    MutableStateFlow
    /
    collectAsState
    would be to keep your state entirely immutable (i.e. if state changes a whole new object is emitted vs updating your existing state). This is helpful in architectures like MVI.
    b

    Brian G

    10 months ago
    State
    is in
    androidx.compose.runtime
    , I don't think that's published for iOS (yet)
    Marcello Galhardo

    Marcello Galhardo

    10 months ago
    @eygraber you can still put a whole object inside a state and have immutability, no? Or do you mean, with MurableStateFlow you can use operators like map and "break down" the immutable into small states for better recomposition? 🤔
    e

    eygraber

    10 months ago
    You could put the whole object into a state, but then you're directly mutating the reference to it when you update it. Which is technically the same as how
    Flow
    works, except it's more hidden because you're doing it through state emissions (also the distinction blurs depending on how you work with it, i.e.
    MutableStateFlow.value
    vs doing everything with a flow API).
    Marcello Galhardo

    Marcello Galhardo

    10 months ago
    I'm sorry but I think I'm missing something. If you don't use property delegate (by) with
    MutableState
    , you would still change it by using
    MutableState.value = newValue
    - which from my understanding is exactly what you described above with
    StateFlow
    . Reference: https://developer.android.com/reference/kotlin/androidx/compose/runtime/MutableState Honest question: what is more hidden? Isn't the state emissions exactly the same? 🤔
    e

    eygraber

    10 months ago
    It depends. If you're using a regular
    Flow
    for
    collectAsState
    then you're not setting
    value
    anywhere; you're just emitting your state. If you use
    MutableStateFlow
    then it is much closer to how
    MutableState
    works. I think using
    MutableState
    in this way "sort of" defeats its advantage over
    collectAsState
    . The way I'm using it to have a
    MutableState
    for each field so that I can limit the recomposition to the specific scope where that discrete read is. By having your whole state in a
    MutableState
    that you read in a top level composable, recomposition will affect that whole subtree.
    You can still get the skipping behavior if the params passed to another function haven't changed, but I've seen a few folks here caution against relying on that since there are some scenarios where it gets tricky.
    Marcello Galhardo

    Marcello Galhardo

    10 months ago
    I see, thank you @eygraber - it is clear now.