https://kotlinlang.org
Join Slack
Maybe I’m misunderstanding the first parameter of `state` but it seems like it makes it so writes to...
# compose
f
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
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
Can you share a code snippet of how you’re using 
state
?
f
I actually meant stateFor in this case
l
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
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
Can you clarify with a full example and what you are observing happening and what you would expect to happen?
f
It is very hard, I have been trying for a long time
l
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
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
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
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
@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
Open in Slack
PreviousNext
Powered by

kotlinlang

A modern programming language that makes developers happier.

Powered by