Context:
I’m currently handling state in my Jetpack Compose screens using a ViewModel that exposes a StateFlow.
Each screen (for example, FooScreen) observes the StateFlow and renders a when(state) that can show loading, error, or success states using AnimatedContent.
When the state is Success, I render a FooContent composable that builds the complete UI (sometimes wrapped in a Scaffold). Inside FooContent, I might also use a LazyColumn with several composable items, each one using an animateFloat to show progress updates.
Here’s my concrete case:
I have a screen that displays the live state of a service, updated frequently from the StateFlow. The recompositions happen at the screen level — the when(state) runs, then the Content renders, and then each item animates its progress.
This design works nicely for Preview (since I can build the Content without a ViewModel), but I’m wondering if it’s the best architecture.
If there are many states, I end up passing several parameters down the composable tree or creating wrapper data classes and callbacks.
Question:
Is this approach correct for managing frequently updating UI state in Jetpack Compose, or should I structure the state handling differently (e.g., move the when(state) deeper, hoist less state, or use a different pattern for partial recompositions)?