Assigned
Status Update
No update yet.
Comments
an...@google.com
al...@google.com
Triage notes: We should consider this, but it needs more thought. Not possible to avoid collisions in general given the current design.
er...@gmail.com
I found a strange problem with using nested LazyLayout that I thought related to this discussion (rememberSaveable).
I attached two videos to demonstrate this issue.
In the state_loss video, you can sometimes see the state in rememberSaveable losses (changing the numbers of row two) but in state_preserve video if you wrap item content with moveableContentOf there's no state losing.
@Composable
fun InnerStateLossWhenScrolling() {
LazyColumn {
items(30) {
LazyRow {
items(20) {
val randomN = rememberSaveable { Random.nextInt() }
Text(
text = randomN.toString(),
modifier = Modifier.padding(horizontal = 8.dp),
fontSize = 36.sp
)
}
}
}
}
}
@Composable
fun InnerStateSavedEvenScrolling() {
LazyColumn {
items(30) {
LazyRow {
items(20) {
movableContentOf {
val randomN = rememberSaveable { Random.nextInt() }
Text(
text = randomN.toString(),
modifier = Modifier.padding(horizontal = 8.dp),
fontSize = 36.sp
)
}()
}
}
}
}
}
Description
Currently,
rememberSaveableoptionally takes akey.If
nullor the empty string is passed as thekey(withnullbeing the default), thecurrentCompositeKeyHashis used as the backing key for saving into saved instance state. This makesrememberSaveablefunction very similarly toremember: state is positionally memoized, and the equivalent ofkeysforrememberare represented asinputsforrememberSaveable. Two different calls torememberSaveablefrom two different locations in the source code won't share state.However, if a non-empty string is passed as a
keytorememberSaveable, thecurrentCompositeKeyHashis not used at all, and the key being used to save into instance state is directly specified by the non-emptykeypassed torememberSaveable.This has some strange effects, that run counter to the normal usage of Compose and
remember:rememberSaveableis now partially positionally memoized, but not entirely. If you have two differentrememberSaveables called from two different locations in the source code in composition at the same time, they won't share state, even if they use the same manually specifiedkey. But, state can be shared between them if separated in time (before and after state instance saving happens)rememberSaveables sharing state with the same key, this behavior is now extremely tied to when saved instance state is saved, and when therememberSaveables enter and leave composition.LocalSaveableStateRegistry). Unrelated sections of code could interact with each other unpredictably if the key is not globally unique. Having to deal with this "globalness" is a bit strange.With these strange effects, it doesn't seem like manually specifying a
keygains much in terms of functionality, and the functionality it does potentially gain in sharing state across composition feels like the wrong approach in Compose.Therefore, it might make sense to deprecate the overloads of
rememberSaveablethat take akey, and instead just use thecurrentCompositeKeyHashin all cases.