compose-state-authoring

Compose state authoring

Not every remember { … } belongs here. This skill covers local UI state (remember { mutableStateOf(…) }, mutableStateListOf / mutableStateMapOf) and @ReadOnlyComposable. Other remembered APIs live in focused skills:

• rememberCoroutineScope / rememberUpdatedState → compose-side-effects
• rememberLazyListState / rememberScrollState used for frame-rate reads → compose-state-deferred-reads
• Focus navigation, focus state, FocusRequester ownership, behavior → compose-focus-navigation

Core principle

A @Composable is a function the runtime re-runs whenever its inputs change. Writing local state correctly comes down to two questions:

1. Mutable local state — does my var survive recomposition and trigger it? If not, it silently resets on every recompose and writes are invisible.
2. What kind of composable is this? — do I mutate composition (place layout nodes, allocate slots, remember) or only read it? If only read, @ReadOnlyComposable lets the runtime skip work.

Get either wrong and the symptoms are subtle: state that vanishes or optimizations that don't apply.

When to use this skill

You're writing or reviewing Compose code and you see any of these:

• var x = … inside a @Composable fun or any composable lambda (Column { var x = … })
• A @Composable fun (or @Composable get() property accessor) whose body never lays anything out
• @ReadOnlyComposable on a function that calls Text, Box, Column, remember, …
• A composable whose visible state mysteriously resets on rotation, theme change, or recomposition

1. var in a composable must be State-backed

Recomposition re-executes the composable from the top. A local var is re-initialized on every pass — last recompose's value is gone, and writing to it doesn't tell the runtime to recompose.