Enable circuit-retained without composition local manual setup

[takahirom]

Thank you for developing this fantastic library. I’d like to use circuit-retained with Jetpack Navigation (or JetBrains Compose Multiplatform Navigation) without needing to set up a composition local for rememberRetained{}. Is this possible, or could you provide guidance on how to achieve this?

[stagg]

I think this would be possible. Would need to pull something together to setup a multi-platform continuity instance as a default. Wouldn't necessarily want to do that setup at each retained use though 🤔

Think at a minimum we should add a RetainedCompositionLocals. Like the CircuitCompositionLocals we have in foundation that sets up the continuity registry for circuit. Would make it easier to use retained on it's own.

Curious whats the limitation around setting up a composition local, or adding a RetainedCompositionLocals, for this at the root level?

[takahirom]

I think managing the backstack might be challenging if only one composition local is provided. It might be beneficial if we could use ViewModels and Lifecycles from Compose Multiplatform instead of relying on the current composition local to achieve smooth integration, assuming they do not already exist. However, this approach may be very complex.

[stagg]

Ahh so specifically an integration with Jetpack/Compose Navigation where the view model store is setup per route. We're doing something similar in NavigableCircuitContent for the LocalRetainedStateRegistry.

Could be doable, let folks provide a default instead of the NoOpRetainedStateRegistry 🤔 Involves some sort of a factory which would default to using a multi-platform continuity.
This would be assuming a lot about the lifecycle, which I think ties this down to being a very Jetpack Navigation specific change.

[ZacSweers]

This now works entirely via local RetainedStateRegistry and not a local CanRetainChecker. I'm not entirely sure how this could be implemented without a local and without requiring a registry. Where would it store anything?

[takahirom]

I think you can use JetBrains Compose Multiplatform Navigation's ViewModel instead of RetainedStateRegistry. The title "without composition local manual setup" might not be appropriate because my intention is to use circuit-retained with Jetpack Navigation. However, I'm uncertain whether this approach aligns with Circuit's architectural principles.

[ZacSweers]

Can you elaborate more on how that would look? Circuit-retained already uses a backing viewmodel in android

[takahirom]

Well, as you know, this is my library, and it just uses androidx.lifecycle.viewmodel.compose.viewModel.
https://github.com/takahirom/Rin/blob/main/rin/src/commonMain/kotlin/io/github/takahirom/rin/Rin.kt

[ZacSweers]

Yes but I don't see androidx navigation used in that file? It appears to have its own backing viewmodel and a new one is instantiated for each rememberRetained?

[takahirom]

I think we don't need to add a dependency on the navigation library. The navigation library provides a composition local, which we can use.

https://github.com/JetBrains/compose-multiplatform-core/blob/3d261f98fa347b61bdd21af7b8cb5967488eb2ca/navigation/navigation-compose/src/jbMain/kotlin/androidx/navigation/compose/NavBackStackEntryProvider.jb.kt#L38

[ZacSweers]

The title is requesting rememberRetained support without use of a composition local but that seems to require a composition local? Or rather, it seems like the request is to just use a different composition local (LocalViewModelStoreOwner) so that the pattern I mentioned here can be used? I'm struggling to follow how this is simpler 😅, it seems to be much more overhead.

[takahirom]

To be clear, I think we needed to be done with different CompositionLocal implementations.

What I wanted was an easy setup for most Compose users.
Perhaps "Enable circuit-retained without manual CompositionLocal setup for Compose Navigation users" would be a more appropriate title for this. For Compose Navigation users, this would eliminate the need to set up the CompositionLocal manually because it would be automatically handled by the navigation library.

That said, I also believe it might be challenging to implement this in circuit-retained. However, I thought that with this support, I could use circuit-retained in many projects.

[ZacSweers]

Could you elaborate on why you feel it's difficult to set up a local RetainedStateRegistry? Seems to me like you could just create one that delegates to an underlying LocalViewModelStoreOwner for its implementation. I do think that creating a whole new ViewModel instance for each rememberRetained call is wasteful though.

[takahirom]

It's preferable to have the ability to manually provide the RetainedStateRegistry to the ViewModel, rather than not having this option at all. I'm uncertain whether we can implement rememberRetained{} using RetainedStateRegistry and LocalViewModelStoreOwner. If a sample implementation were available, it would be greatly appreciated. I was trying to implement it, but I forgot the details. Sorry about that.

Regarding the creation of a new ViewModel instance for each rememberRetained call, I don't believe it's necessary if we have a data structure like mutableMapOf<String, ArrayDeque<RinViewModelEntity<Any?>>>() within a ViewModel that maps the currentCompositeKeyHash to values. However, I'm not entirely sure about the Circuit implementation.

[ZacSweers]

It's preferable to have the ability to manually provide the RetainedStateRegistry to the ViewModel, rather than not having this option at all.

There is an overload of continuityRetainedStateRegistry() that accepts a custom ViewModelProvider.Factory, which should allow customization of the backing viewmodel. Ref. Does that satisfy this need?

I don't believe it's necessary if we have a data structure like mutableMapOf<String, ArrayDeque<RinViewModelEntity<Any?>>>() within a ViewModel that maps the currentCompositeKeyHash to values. However, I'm not entirely sure about the Circuit implementation.

This is functionally what the circuit implementation does :). The viewmodel and the impl it delegates to.

[ZacSweers]

@takahirom given that, do you think I can close this?

[takahirom]

Since the original issue title references "Sample or Integration Implementation using circuit-retained with Jetpack Navigation (or JetBrains Compose Multiplatform Navigation)", I'd be interested in seeing a sample implementation or test case demonstrating rememberRetained with Navigation components. However, I'm currently uncertain whether this integration is feasible.

If you prefer to close this issue, that's acceptable - this request primarily reflects my personal interest rather than an urgent technical requirement. We can always create a new issue if specific implementation challenges emerge later. Please feel free to proceed with closing this.

[8cAyqpVKio]

SavedState (called Bundle in Android) now supports kotlinx.serialization in the alpha version, so making it easier to use rememberSaveable.

val state = rememberSaveable(
    saver = Saver(
        save = { encodeToSavedState(it) },
        restore = { decodeFromSavedState(it) }
    )
) { UiState(emptyList(), emptyList()) }

@Serializable
data class UiState(
    val cats: List<Cat>,
    val dogs: List<Dog>
)

I think rememberRetained will no longer be necessary in the future.

[ZacSweers]

I think that claim reveals a lack of understanding in what circuit-retained is for :). Marshaling and unmarshaling every time isn't free, nor is it possible or practical to make everything that goes into circuit-retained today serializable. For example - coroutine scopes.

I am going to close this for now as it's no longer an issue/FR and really just a question. Please feel free to post in the Q&A section of the discussions panel of the repo if you want to pursue this. My conclusion from the above conversation is that circuit-retained supports everything you need, that fork seems to just interop to LocalViewModelStoreOwner and allocate a ViewModel instance per every rememberRetained rather than use a single instance with an inner map. How that relates to androidx.navigation is really up to the developer, I am unfamiliar with it nor is it something we use, so I'm not sure we're well-equipped to advise. If you ask in the discussions section though, maybe someone else from the community can help. I do think there would be a lot of value in learning how circuit-retained works under the hood, the blog post I linked above is helpful for that too.