Is there any way to loadKoinModule in compose function?

[Stonerub]

I don't want to declare all my app modules in main module, how can i inject specific screen module into compose function or navgraph?

Example:
NavHost(navController = navController, startDestination = "auth") {
composable("auth") {
Here i want to inject my module, in fragment i did it like loadKoinModule(AuthModule)
AuthCompose(
viewModel = getViewModel(),
onPasswordRestore = { navController.navigate("password restore") }
)
}
composable("password restore") {
Here i want to inject my module, in fragment i did it like loadKoinModule(PasswordRestoreModule)
PasswordResetCompose(viewModel = koinViewModel())
}
}

[Alox1d]

Yes. In the checked Koin 4.2.2 Compose API, use rememberKoinModules before resolving the screen's ViewModel:

import org.koin.compose.module.rememberKoinModules
import org.koin.compose.viewmodel.koinViewModel
import org.koin.core.annotation.KoinExperimentalAPI

@OptIn(KoinExperimentalAPI::class)
@Composable
fun AuthDestination() {
    rememberKoinModules { listOf(AuthModule) }

    AuthCompose(
        viewModel = koinViewModel(),
        onPasswordRestore = { /* navigate */ }
    )
}

Use the same pattern at your password-reset destination with its module. Keep the module definitions stable, for example as top-level vals.

There are two lifetime decisions to keep separate:

• By default, unloadModules is false. The remembered loader loads the definitions once for that composition entry, and leaving the destination does not remove them.
• rememberKoinModules(unloadModules = true) { listOf(AuthModule) } opts into removal when the loader is forgotten or abandoned. That unloads definitions from the Koin container; it does not make them private to this screen, and it does not clear an AndroidX ViewModelStore or replace references already held elsewhere.

The loader implementation makes those load/unload operations explicit. If multiple destinations use the same definitions, leave them loaded or manage their ownership at a shared parent. If the goal is a fresh dependency instance for each screen, use a Koin scope for that lifetime instead of relying on unloading a shared module.

This is source-checked against 4.2.2; it is an experimental API there. I have not run your navigation graph, and older releases may have a different signature.