Hi, is the general consensus that sharing viewmode...

# orbit-mvi

[Rak]

Hi, is the general consensus that sharing viewmodels across screens is bad? Its better to have unique viewmodels with their own state/side effect class?

[Rak]

This isnt specific to orbit-mvi I guess. I did find the quantity of states difficult to manage as well as the fragments having unnecessary `when`s branches

[Benoît]

You're going to make your code more modular by having 1 VM per screen. However as you said it's going to complicate things because you'll have to pass data around.

If you're building an isolated journey with a lot of screens you're unlikely to re-use, then it's probably okay to use 1 VM.

It's always a trade-off between re-usability and simplicity.

To me, both approaches are correct. Although with Compose I tend to make smaller/simpler VMs because it's easier to pass data around compared to Fragments

[Benoît]

Personally, I use both

[Rak]

perhaps there is some good practice guidance about how to manage it? For example, multiple screens could have their own sub classes for state?

[Rak]

So the container declares OnboardingState but it has subclasses StepOne, StepTwo, etc

[Rak]

then the view can declare its only interested in a certain set of them

[Rak]

probably use nested sealed classes

[Benoît]

If you decide to go for 1 VM per screen then you can have 2 types of states.
1. When you need to share data that between multiple screens, then you just pass a state object from one VM to the next, through Fragment argument, or just pass it into your Composables
2. Each VM has its own internal state as well, and onNextClicked() or something, it would tell the UI to go to the next screen giving it the state describe in 1.