compose-state-hoisting

What problem does it solve?

It prevents Compose UIs from becoming harder to maintain by ensuring UI state lives at the right ownership level instead of being hoisted too far or mixed with business logic.

Core Features & Use Cases

• State ownership decision guide: Choose local remember state, hoisted composable parameters, a plain state holder, or a screen-level ViewModel based on who reads/writes the state and what logic it drives.
• Plain state holder extraction: Extract a @Stable state holder when multiple coordinated UI concerns and named operations (e.g., clear, jumpToTop, openFilters) make the composable hard to test and preview.
• Composition-scoped suspend operations: Keep scroll/drawer animation suspend calls in composition-owned coroutines (e.g., rememberCoroutineScope / LaunchedEffect) rather than in viewModelScope.
• Saving state correctly: Use rememberSaveable/custom Saver for minimal serializable values that must survive recreation (e.g., query string), while avoiding runtime objects like LazyListState or FocusRequester.

Quick Start

Apply the decision guide in the Compose UI you are building and move each state to the lowest common composable owner, using a plain state holder only when the UI mechanics need coordinated named operations.