Hi folks! Some question about state holders architecture. I have some use-case when I want to split-...

# compose

[Morgan]

Hi folks!
Some question about state holders architecture.
I have some use-case when I want to split-up my screen with different features that are @Composable . Each feature is independent from one to the other in terms of business logic.
Is it a good practice or common to have state holder classes that handle the logic of these features?
What I mean is that I would have this kind of state holder:

@Stable
class MyFeatureState @AssistedInject constructor(
    @Assisted private val id: String,
    @Assisted private val coroutineScope: CoroutineScope,
    private val myFeatureUseCase1: UseCase1,
    private val myFeatureUseCase2, UseCase2,
)

I would host this inside the ViewModel of the screen so that I can pass it into the @Composable that needs it in my screen.

It simplify so much my code but I wonder if it's kind of a hack or a real practice.
One of the drawbacks is that I cannot have a preview of my @Composable as in my screen I call my feature composable that takes this state as a parameter.

What's your opinion on this?
Thanks! 🙏