What is the best approach to create several compose screens with their own scopes bound to one general scope?

[Mortd3kay]

Lets consider I have this:

@Composable
private fun SomeModuleGraph() {
    val navController = rememberNavController()
    ScopedContext(::SomeKoinComponent) { //contains some dependencies required for both screens
        RootRouteWithNavHostInside(
            navController = navController,
            builder = {
                composable("screen1") {
                    LinkedContext(::Screen1Component) { //contains some dependencies for screen1 only
                        Screen1Route()
                    }
                }
                composable("screen2") {
                    LinkedContext(::Screen2Component) { //contains some dependencies for screen2 only
                        Screen2Route()
                    }
                }
            }
        )
    }
}

My custom contexts:

@OptIn(KoinExperimentalAPI::class)
@Composable
fun ScopedContext(
    initializer: () -> KoinScopeComponent,
    content: @Composable Scope.() -> Unit
) {
    val component = remember(initializer)
    val scope = rememberKoinScope(scope = component.scope)

    CompositionLocalProvider(
        LocalKoinApplication provides scope.getKoin(),
        LocalKoinScope provides scope,
    ) {
        content(scope)
    }
}

@Composable
fun Scope.LinkedContext(
    initializer: () -> KoinScopeComponent,
    content: @Composable Scope.() -> Unit
) {
    val component = remember(initializer)
    val scope = rememberKoinScope(scope = component.scope)
    scope.linkTo(this)

    CompositionLocalProvider(
        LocalKoinApplication provides scope.getKoin(),
        LocalKoinScope provides scope,
    ) {
        content(scope)
    }
}

But this solution works bad on reconfiguration because KoinScopeComponent recreates. So it is needed to use ScopeViewModel instead of KoinScopeComponent but what if I don't want to create new ViewModel. Also are there any solutions to make it without creating root route with navhost?

[faraz152]

The reconfiguration problem happens because KoinScopeComponent is not lifecycle-aware — it gets recreated on every recomposition after a config change. The idiomatic fix is to let a ViewModel own the scope, since ViewModels survive configuration changes.

You said you don't want extra ViewModels, but ScopeViewModel is the lightest possible ViewModel — it holds no state beyond the scope itself:

// One ViewModel per scope boundary — owns the scope lifecycle
class ModuleScopeViewModel : ViewModel(), KoinScopeComponent {
    override val scope: Scope = createScope<ModuleScopeViewModel>()

    override fun onCleared() = scope.close()
}

Your graph, rewritten to survive reconfigurations:

@Composable
fun SomeModuleGraph() {
    val navController = rememberNavController()

    // ViewModel survives config changes — scope stays alive
    val moduleVm: ModuleScopeViewModel = koinViewModel()

    // Expose the stable scope to children
    KoinScope(scope = moduleVm.scope) {
        NavHost(navController, startDestination = "screen1") {
            composable("screen1") {
                // Screen-level dependencies resolved from the parent scope
                val dep = moduleVm.scope.get<Screen1Dep>()
                Screen1Route(dep)
            }
            composable("screen2") {
                val dep = moduleVm.scope.get<Screen2Dep>()
                Screen2Route(dep)
            }
        }
    }
}

If you truly want no ViewModel at all, use rememberSaveable to persist a scope ID across reconfigurations and re-open the same Koin scope by ID:

@Composable
fun SomeModuleGraph() {
    val scopeId = rememberSaveable { uuid4().toString() }

    val scope = remember(scopeId) {
        getKoin().getOrCreateScope(scopeId, named<SomeModule>())
    }

    DisposableEffect(scope) {
        onDispose { scope.close() }
    }

    KoinScope(scope = scope) {
        // NavHost here
    }
}

rememberSaveable keeps scopeId constant across reconfigurations, so getOrCreateScope returns the same scope every time rather than recreating it.

The ScopeViewModel approach is strongly preferred — it handles the onCleared cleanup automatically and integrates with the nav back-stack lifecycle.