Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

viewmodel not destroy in recomposition state #477

Open
javad0470 opened this issue Aug 25, 2024 · 2 comments
Open

viewmodel not destroy in recomposition state #477

javad0470 opened this issue Aug 25, 2024 · 2 comments

Comments

@javad0470
Copy link

Hello,

I hope this message finds you well.

I'm currently using Voyager version 1.1.0-beta02 along with Koin for dependency injection. Following the sample provided, I’m defining ViewModels within my composable screens as shown below:
val vm = koinScreenModel()

However, I've encountered an issue where, during each recomposition of the composable screen, everything gets destroyed except for the ViewModel. While this behavior might be useful for temporarily sharing a ViewModel content between two composable screens, it causes significant challenges in other scenarios. Unfortunately, this issue persists across previous versions as well.

I would greatly appreciate it if you could address this issue or provide guidance on how to resolve it in my project.

Thank you so much for your help.

@cjrvdev
Copy link

cjrvdev commented Sep 3, 2024

As far as I know (Im rather new in kotlin/compose), the idea behind viewmodel is to survive recomposition. That should be the intented behavior

@Kiolk
Copy link

Kiolk commented Nov 2, 2024

I found that, if you not specify unique key for screen

override val key: ScreenKey = uniqueScreenKey

koinScreenModel() every time return the same view model, unique parameter of parametersOf doesn't guaranty that.

I think, need to update documentation to clarify that sample

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants