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

Fudge

07/28/2020, 7:45 PM
Maybe I’m misunderstanding the first parameter of
state
but it seems like it makes it so writes to the variable somehow get ignored, so I would change the value but after the recomposition the value is the same as it was before. I can’t really give a complete example since its in a middle of a lot of things and this only happens in exactly the second instance of this state variable. But the magical nature of remember {} and such make it impossible to debug. At this point it seems it would be easier to roll out my own implementation of state.
t

Timo Drick

07/28/2020, 8:44 PM
Maybe you should start with the Compose tutorial to get familiar with state. And yes it is difficult to debug. Sometimes it is better to use stateFor instead of state but it depends on your use case.
z

Zach Klippenstein (he/him) [MOD]

07/28/2020, 9:05 PM
Can you share a code snippet of how you’re using
state
?
f

Fudge

07/28/2020, 9:11 PM
I actually meant stateFor in this case
l

Leland Richardson [G]

07/28/2020, 9:16 PM
the parameter you’re talking about is the
MutationPolicy
. The general idea here is that wherever the
value
property of the state object is set, it will trigger a recomposition to all of the scopes where that property was read
The question is then: well, what if I set the property to the same value that it currently is?
we have decided that in this case, a recomposition should not trigger
but then the question is: how do we know if it is the same value or not?
there are two common answers to this: 1. the values are the same if they are referentially equal to one another (same reference) 2. the values are the same if a.equals(b) returns true
the former we refer to as
referentialEqualityPolicy()
and the latter we refer to as
structuralEqualityPolicy()
the policy can account for some other interesting things, such as object merging, which is useful in multithreaded contexts where you have a single object that was mutated on different threads at the same time
to throw a wrench in all of this….. 1. The default policy just got changed from referential -> structural https://android-review.googlesource.com/c/platform/frameworks/support/+/1374642 2. We are likely going to deprecate
state
and
stateFor
and instead push people towards writing
remember { mutableStateOf(…) }
explicitly https://android-review.googlesource.com/c/platform/frameworks/support/+/1375120
👆 2
f

Fudge

07/29/2020, 5:17 AM
Sorry, I meant the first parameter of stateFor which is the first parameter of rememeber. The one is called v1.
I feel like I’m just running into some bug that is going to be hard to reproduce
Actually...
yes I have further verified that is the case
l

Leland Richardson [G]

07/29/2020, 6:33 AM
Can you clarify with a full example and what you are observing happening and what you would expect to happen?
f

Fudge

07/29/2020, 6:33 AM
It is very hard, I have been trying for a long time
l

Leland Richardson [G]

07/29/2020, 6:34 AM
Capturing that object will prevent some optimizations and cause a slight difference in code generated
But it's not clear to me what you're seeing that feels wrong
f

Fudge

07/29/2020, 8:31 AM
Is there a way to force compose to release all the state in the
remember{}
variables? As if I've switched back and forth to a different component
t

Timo Drick

07/29/2020, 10:15 AM
In my tests when the Composable is disposed also remembered variables in there are lost.
you can use onActive / onDispose and put a log output in there to see the lifecycle of a Composable
z

Zach Klippenstein (he/him) [MOD]

07/29/2020, 2:17 PM
You can wrap your composable in the
key
function, which will effectively "reset" all the remembers inside it when any of its parameters change.
f

Fudge

07/29/2020, 7:35 PM
@Zach Klippenstein (he/him) [MOD] I did some changing around, and it seems like
key
works well. I can't tell if it would have solved my original problem though since things have terraformed sinced then, but maybe it would have 😅
2 Views