Still trying to get the understanding of basics right. If I change a remembered mutable state outsid...

# compose

[dimsuz]

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.

[dimsuz]

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?

[dimsuz]

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]

I would expect the code above to not compile 🙂

[dimsuz]

Oh, it's a rough scheme from my head. Sort of pseudocode 🙂

[Adam Powell]

when the activity class declares var state by mutableStateOf("hello") the type of state is String, not State<String>

[Adam Powell]

which means any time state appears in your code it's evaluating the current value of state

[Adam Powell]

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

[Adam Powell]

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"
  }
}

[dimsuz]

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 :)

[dimsuz]

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]

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.

[Adam Powell]

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

[Adam Powell]

remember {} is a little like declaring a private instance property of a @Composable fun

[dimsuz]

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]

Yep

[dimsuz]

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