compose-state-hoisting

Determine correct ownership levels for Jetpack Compose UI state and logic.

Updated Aug 27, 2026
One-click install
npx skills add https://github.com/soygabimoreno/Los-ANDROIDES --skill compose-state-hoisting
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: compose-state-hoisting
Source: https://github.com/soygabimoreno/Los-ANDROIDES/tree/main/.agents/skills/compose-state-hoisting
Command: npx skills add https://github.com/soygabimoreno/Los-ANDROIDES --skill compose-state-hoisting

SYSTEM DOCUMENTATION & REQUIREMENTS

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.

Frequently Asked Questions about compose-state-hoisting

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I decide where Jetpack Compose UI state should live?

Jetpack Compose UI state should live at the lowest common composable owner that reads and writes it, moving to a plain state holder or ViewModel only when coordinated operations require it.

When should I extract a plain state holder in Compose?

Extract a plain state holder in Compose when multiple coordinated UI concerns and named operations like clear or jumpToTop make the composable hard to test and preview.

Should scroll and drawer animation suspend calls run in viewModelScope?

Scroll and drawer animation suspend calls should run in composition-owned coroutines using rememberCoroutineScope or LaunchedEffect, keeping UI mechanics out of viewModelScope.

When should I use rememberSaveable instead of remember for Compose state?

Use rememberSaveable with a custom Saver for minimal serializable values that must survive recreation, avoiding runtime objects like LazyListState or FocusRequester.

How to avoid over-hoisting state in Jetpack Compose?

Avoid over-hoisting state in Jetpack Compose by applying a decision guide to move each state to the lowest common owner, preventing incorrect layering and mixed business logic.