A modern programming language that makes developers happier.

kotlinlang

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`

I would expect the code above to not compile :slightly_smiling_face:

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

when the activity class declares `var state by mutableStateOf("hello")` the type of `state` is `String`, not `State&lt;String&gt;`

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

Oh, right, this was exactly the case! I missed that type of state would be `String`.

&gt;  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 :slightly_smiling_face:

&gt; 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`

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?

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