IssueTracker

Triage notes: Mirrors some other discussion, we should consider it.

Thank you for your request.

You’ve described what you want (access to the internal keys), but not a concrete use case. We need more context on why you need access to the keys. I'm particularly interested in understanding how you would use keys to remove a subset without introducing state management to track them.

Could you please:

1. Describe your current use case.
2. Hypothetically, if you have access to the internal keys, explain how you would use it to fix your described use case.

This information will help us understand the problem before considering how to fix it.

Thanks!

Thanks for the response!

My use case is a navigation framework with a back stack. What I have access to inside the composition is the current state of the back stack. The UI composition receives a statesToKeep: ImmutableSet<String> created by something like: backStack.map { it.key }.toPersistentSet().

I'm not keeping a detailed ledger of what's been removed from the stack and thus needs to be removed from UI state. This would add a lot of complexity to the API boundary between the layers and both sides of the implementation.

I'm currently wiring this up to SaveableStateHolder like so:

@Composable
fun updateSaveableStateHolder(
  statesToKeep: ImmutableSet<String>,
): SaveableStateHolder {
  val stateHolder = rememberSaveableStateHolder()

  // Intentionally not State so that we don't trigger recomposition.
  val stateKeys = remember { mutableSetOf<String>() }

  // Effect probably isn't necessary. Just being safe.
  SideEffect {
    stateKeys.filter { it !in statesToKeep }.forEach(stateHolder::removeState)

    stateKeys.clear()
    stateKeys.addAll(statesToKeep)
  }

  return stateHolder
}

This isn't really that bad. I'm fine shipping this and I'm glad that enough hooks already exist to make this work! But this additional state, whether as shown here or in a hypothetical BackStackWithLedger implementation, is extra work that is ultimately duplicating the internal state of SaveableStateHolder.

If SaveableStateHolder exposed something like val keys: Set<String>, then the above would be simplified to:

val stateHolder = rememberSaveableStateHolder()
SideEffect {
  stateHolder.keys.filter { it !in statesToKeep }.forEach(stateHolder::removeState)
}

Or if a retainAll was added:

val stateHolder = rememberSaveableStateHolder()
SideEffect {
  stateHolder.retainAll(statesToKeep)
}

Or maybe something like @Composable fun updateSaveableStateHolder(statesToKeep: ImmutableSet<Any>) is added instead.

Hopefully that helps? Let me know if I can provide any additional context.