https://kotlinlang.org logo
#compose
Title
# compose
d

dimsuz

05/31/2021, 8:03 PM
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.
Copy code
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
a

Adam Powell

05/31/2021, 8:12 PM
I would expect the code above to not compile 🙂
d

dimsuz

05/31/2021, 8:13 PM
Oh, it's a rough scheme from my head. Sort of pseudocode 🙂
a

Adam Powell

05/31/2021, 8:13 PM
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:
Copy code
class MyActivity {
  private var state by mutableStateOf("hello")
  fun onCreate() {
    setContent {
      SomeComposable(state)
    } 
  }
  fun onResume() {
    state = "world"
  }
}
d

dimsuz

05/31/2021, 8:17 PM
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 🙂
a

Adam Powell

05/31/2021, 8:23 PM
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

05/31/2021, 8:27 PM
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?
a

Adam Powell

05/31/2021, 8:31 PM
Yep
d

dimsuz

05/31/2021, 8:35 PM
Looks like this was that "click" moment. You must've repeated this like 100 times already 😄 Appreciate this!
3 Views