Maybe I m misunderstanding the first parameter of `state` bu

Question

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

Timo Drick · Answer

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

Zach Klippenstein (he/him) [MOD] · Answer

Can you share a code snippet of how you re using `state`

Fudge · Answer

I actually meant stateFor in this case

Leland Richardson [G] · Answer

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

Leland Richardson [G] · Answer

The question is then well what if I set the property to the same value that it currently is

Leland Richardson [G] · Answer

we have decided that in this case a recomposition should not trigger

Leland Richardson [G] · Answer

but then the question is how do we know if it is the same value or not

Leland Richardson [G] · Answer

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

Leland Richardson [G] · Answer

the former we refer to as `referentialEqualityPolicy ` and the latter we refer to as `structuralEqualityPolicy `

Leland Richardson [G] · Answer

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

Leland Richardson [G] · Answer

to throw a wrench in all of this 1 The default policy just got changed from referential gt structural 2 We are likely going to deprecate `state` and `stateFor` and instead push people towards writing `remember mutableStateOf ` explicitly

Fudge · Answer

Sorry I meant the first parameter of stateFor which is the first parameter of rememeber The one is called v1

Fudge · Answer

I feel like I m just running into some bug that is going to be hard to reproduce

Fudge · Answer

Actually

Fudge · Answer

yes I have further verified that is the case

Leland Richardson [G] · Answer

Can you clarify with a full example and what you are observing happening and what you would expect to happen

Fudge · Answer

It is very hard I have been trying for a long time

Leland Richardson [G] · Answer

Capturing that object will prevent some optimizations and cause a slight difference in code generated

Leland Richardson [G] · Answer

But it s not clear to me what you re seeing that feels wrong

Fudge · Answer

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

Timo Drick · Answer

In my tests when the Composable is disposed also remembered variables in there are lost

Timo Drick · Answer

you can use onActive onDispose and put a log output in there to see the lifecycle of a Composable

Zach Klippenstein (he/him) [MOD] · Answer

You can wrap your composable in the `key` function which will effectively reset all the remembers inside it when any of its parameters change

Fudge · Answer

< 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 sweat smile