Maybe I’m misunderstanding the first parameter of ...

# compose

[Fudge]

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]

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]]

Can you share a code snippet of how you’re using state?

[Fudge]

I actually meant stateFor in this case

[Leland Richardson [G]]

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]]

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

[Leland Richardson [G]]

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

[Leland Richardson [G]]

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

[Leland Richardson [G]]

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]]

the former we refer to as referentialEqualityPolicy() and the latter we refer to as structuralEqualityPolicy()

[Leland Richardson [G]]

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]]

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

[Fudge]

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

[Fudge]

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

[Fudge]

Actually...

[Fudge]

yes I have further verified that is the case

[Leland Richardson [G]]

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

[Fudge]

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

[Leland Richardson [G]]

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

[Leland Richardson [G]]

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

[Fudge]

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]

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

[Timo Drick]

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

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

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]

@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 😅