Maybe a dumb question but I guess I never tried. I...

# compose

[Colton Idle]

Maybe a dumb question but I guess I never tried. If I have a composable that uses a ViewModel but it's not an android view model (just a generic class is probably a better description). Does that class end up being generated constantly (on every composition?)

Like

@Composable
fun MyMainScreenInAComposeMultiplatformApp(someGenericClass: Foo = Foo()){
  Text(someGenericClass.text)
}

[Arkadii Ivanov]

You can warp it with remember {}, but still it will be gone if the Composable goes into the back stack, whereas real ViewModel stays.

[Landry Norris]

Note that it goes away if the composable it's in gets recomposed. I wonder how long it would survive in a case where the top composable doesn't directly hold anything that changes, such as

@Composable
fun MainScreen() {
    val vm = FooViewModel()
    FooScreen(vm)
}

Not that I'd recommend this, but it shouldn't need to recompose if I understand correctly.

[Colton Idle]

So in a world where (for example) im building a compose for desktop app. I'd just have to do

@Composable
fun MyMainScreenInAComposeMultiplatformApp(){
  val vm = remember {Foo()}
  Text(vm.text)
}

?

[Landry Norris]

That ought to work for a desktop app. I would create it outside of a composable and pass it in, though, unless this were a quick and small project.

[Colton Idle]

interesting. its a small project, but it will have about like 10 screens and so im trying to figure out how to best have this concept of an "android viewModel" (mostly because thats how i associate building an app in compose 😅

[Stylianos Gakis]

If you want it to feel like an Android app, just use something like PreCompose and then you'll feel like you're building an Android app, it will feel right at home 😅

[Michael Paus]

@Colton Idle In practice I also pass in the current coroutine scope into Foo and use a DisposableEffect to do something like vm.dispose() at the end.

[Colton Idle]

@Michael Paus Oooh. Interesting. I guess... yeah that's all I need right? thanks. I like the coroutine scope + disposable effect.
@Stylianos Gakis yeah. i think I will go precompose. I dont want to learn a new framework right now. but i thought it would be good to try to at least know what happens in this case. thanks for teaching everyone

[Javier]

I think the easier approach could be to keep the screen stateless and create the ViewModel in the parent one, which can be based on how are you building your app, for example, if you are using navigation-compose, you can decide how your ViewModel must live based on in which part of the graph you are creating it

[Javier]

and, it wouldn't pass the ViewModel, just pass the state/functions to the screen

[Colton Idle]

not in response to javier ^ but was just thinking about what Stylianos and Michael said some more
i guess the only way to get "android arch component view model"-esque functionality would be to tie the lifecycle of my generic class VM to whatever navigation graph I use because the Android VM outlives the composable. so id need to tie it to my backstack/nav stack of choice.

[Colton Idle]

@Javier yeah. everything I'm doing basically does that. So I typically have

@Composable
ScreenAOuter(vm: MyViewModel)
{
  ScreenAInner(vm.foo, vm.bar)
}

and then screen A is stateless, no vms passed into it. etc.

[Colton Idle]

i always try to keep that one additional layer so that I keep my screens Previewable.