Thread
#compose
    d

    dimsuz

    1 year ago
    Still trying to get the understanding of basics right. If I change a remembered mutable state outside of the composition, will it trigger recompose? I have a
    ComposeView
    in an ordinary view hierarchy. See the snippet in the thread.
    class MyActivity {
      private var state by mutableStateOf("hello")
      fun onCreate() {
        setContent {
          val s = remember { state }
          SomeComposable(s.value)
        } 
      }
    
      fun onResume() {
        state = "world"
      }
    }
    will
    SomeComposable
    get "world" eventually? I tried this and it doesn't, but maybe I do something wrong?
    I guess it makes sense that it doesn't,
    remember
    would recalculate it's lambda only if I did
    s.setValue("hello")
    , the way I did this above bypasses any 'remember-wrapping. But maybe there's some way to mutate the state outside of composable context? Asking because I'm trying to adapt a pre-compose classes to some intermediate scheme. For now I settled on having a
    MutableStateFlow
    to which I subscribe inside
    setContent
    and to which I post inside
    onResume
    Adam Powell

    Adam Powell

    1 year ago
    I would expect the code above to not compile 🙂
    d

    dimsuz

    1 year ago
    Oh, it's a rough scheme from my head. Sort of pseudocode 🙂
    Adam Powell

    Adam Powell

    1 year ago
    when the activity class declares
    var state by mutableStateOf("hello")
    the type of
    state
    is
    String
    , not
    State<String>
    which means any time
    state
    appears in your code it's evaluating the current value of
    state
    so doing
    val s = remember { state }
    means that
    s
    will remember the initial value of
    state
    and not see any changes; it's a copy of the string reference that was evaluated at initial composition
    Skip remembering another reference to something that already exists in your scope and just go straight to the source:
    class MyActivity {
      private var state by mutableStateOf("hello")
      fun onCreate() {
        setContent {
          SomeComposable(state)
        } 
      }
      fun onResume() {
        state = "world"
      }
    }
    d

    dimsuz

    1 year ago
    Oh, right, this was exactly the case! I missed that type of state would be
    String
    .
    Skip remembering another reference to something that already exists in your scope and just go straight to the source:
    Wait! Would this work?! I need to read Zach's article on
    remember
    and
    state
    once again 😃
    Omg, it does work. Thanks, Adam! Can I think of
    mutableStateOf
    as having a magic little
    remember
    inside it? I guess I should also read the article on snapshots. I'm in a phase when I understand the concepts separately, but they still didn't click together. Until they do I usually ask some really stupid quesitons 🙂
    Adam Powell

    Adam Powell

    1 year ago
    Can I think of 
    mutableStateOf
     as having a magic little 
    remember
     inside it?
    No, the two are completely orthogonal. This is why you see
    remember { mutableStateOf(...) }
    often.
    The thing that has a magic little
    remember
    inside it is
    MyActivity
    - you've declared
    state
    as a property of the activity class itself, so it persists there instead of as part of the composition
    remember {}
    is a little like declaring a private instance property of a
    @Composable fun
    d

    dimsuz

    1 year ago
    Great! This makes it clearer. So the "magic" property of
    mutableStateOf()
    is that wherever I keep it (in Activity or in composition or etc), if I reference it inside a composition, and call its setter from wherever else, then it will cause recomposition?
    Adam Powell

    Adam Powell

    1 year ago
    Yep
    d

    dimsuz

    1 year ago
    Looks like this was that "click" moment. You must've repeated this like 100 times already 😄 Appreciate this!