--- title: "UiState is Too Big and Hard to Read — Now What?" url: https://daily.dev/posts/uistate-is-too-big-and-hard-to-read-now-what--vutjdzhsk source_url: https://proandroiddev.com/uistate-is-too-big-and-hard-to-read-now-what-05d414069bef type: article source: "ProAndroidDev" published: 2026-08-15T21:52:32.135Z updated: 2026-08-15T21:52:55.673Z tags: ["general-programming", "android", "kotlin", "jetpack-compose"] reading_time: 5 upvotes: 3 comments: 1 language: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # UiState is Too Big and Hard to Read — Now What? **[ProAndroidDev](https://daily.dev/sources/pand)** · 5 min read · 3 upvotes · 1 comments ## Summary A practical rundown of seven techniques to tame bloated UiState classes in Android apps using Jetpack Compose and MVVM. Suggestions include modeling mutually exclusive states with sealed interfaces, breaking flat state into sub-states, keeping UI-local state inside Composables, deriving computable values instead of storing them, splitting oversized ViewModels, avoiding huge lists in UiState (using Paging instead), and splitting a single StateFlow into independent flows per screen section. The core takeaway is that a large UiState isn't inherently bad — the real issue is mixing unrelated kinds of state together. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### How can I reduce a bloated UiState class in Jetpack Compose without breaking the single source of truth pattern? Split the state by responsibility rather than trying to shrink it artificially. Techniques include modeling mutually exclusive states with a sealed interface (Loading, Error, Success), grouping related fields into sub-states like HeaderState and FilterState, moving UI-only state such as expansion or animation flags into the Composable with rememberSaveable, deriving computed values like filtered lists instead of storing them, and splitting a single StateFlow into independent StateFlows per screen section when parts of the UI have genuinely independent state. _daily.dev surfaces Android architecture patterns like this for developers refining their state management approach._ ### Should I store a large list of items directly inside a ViewModel's UiState in Android? No, large datasets should not be embedded directly inside a UiState data class. Instead, expose them through a streaming or paging mechanism such as Paging with cachedIn(viewModelScope), keeping UiState limited to lightweight fields like search queries and filters rather than the full dataset. _Developers weighing Paging versus flat state lists can track patterns like this via daily.dev._ ## Community discussion Top comments from developers on daily.dev. **@mark\_kazakov** · 0 upvotes > Sealed classes and "sub states" can trivialize a large state management mess, can't recommend these approaches enough. ## Similar posts on daily.dev - [AppState in Jetpack Compose: The Missing Piece for Building Large-Scale Android Apps](https://daily.dev/posts/appstate-in-jetpack-compose-the-missing-piece-for-building-large-scale-android-apps-gsrhvyqeq) · Medium · 1 upvotes · 1 comments - [Android Architecture Is Quietly Moving Beyond ViewModel as a State Holder](https://daily.dev/posts/android-architecture-is-quietly-moving-beyond-viewmodel-as-a-state-holder-0e2pkua20) · ProAndroidDev · 11 upvotes · 0 comments --- Tags: [#general-programming](https://daily.dev/tags/general-programming), [#android](https://daily.dev/tags/android), [#kotlin](https://daily.dev/tags/kotlin), [#jetpack-compose](https://daily.dev/tags/jetpack-compose) [View this post on daily.dev](https://daily.dev/posts/uistate-is-too-big-and-hard-to-read-now-what--vutjdzhsk)