Compose state and effects
Core principle
Give every piece of UI state one lowest responsible owner, then run imperative work through the effect whose lifecycle follows that owner. Composition renders; state and effects make rendering change safely.
Procedure
- Inventory mutable UI state, app state, event streams, app dependencies, and imperative work in the affected screen or component.
- Place each state value at its lowest necessary owner: local UI state, hoisted state, a plain UI state holder, or a screen state holder.
- Keep app wiring and business state at the screen boundary; expose plain UI state and explicit callbacks to previewable rendering.
- Choose an effect API whose lifecycle matches the work, and key it by the semantic input that should restart or dispose it.
- Load the focused reference for every material concern below. Do not use a reference merely because its topic is adjacent.
- Route frame-rate reads, cross-phase back-writing, and
@ReadOnlyComposablecontracts to Compose performance. - Finish when every state value has one owner, every effect has a justified lifecycle and key, and the UI can be previewed and tested without app dependencies.
Topic router
| Signal | Read |
|---|---|
Bare local var, remember { mutableStateOf(...) }, state lists/maps, or reset state |
Local state |
| State shared by siblings, UI state holders, ViewModel/component wiring, or previewable screen boundaries | State hoisting |
LaunchedEffect, DisposableEffect, SideEffect, snapshotFlow, rememberCoroutineScope, rememberUpdatedState, produceState, imperative requestFocus, callbacks, event Flow collection, snackbar, navigation, or analytics |
Side effects |
| Focus ownership and keyboard/TV/D-pad behavior | Compose focus navigation |
| Tests or previews for the resulting UI contract | Compose UI testing patterns |
RED/GREEN agent scenarios
- RED keeps a component, collected
StateFlow, navigation event, and screen layout in one composable. GREEN leaves wiring and effects at the screen boundary and gives plain rendering immutable state plus callbacks. - Novel case: a query drives repository suggestions while a list state and focus requester coordinate UI behavior. GREEN puts query and suggestions in the screen state holder, but keeps Compose runtime objects in plain UI state.
- Counterexample: a one-off expandable badge has one private Boolean. GREEN keeps it local and does not introduce a state holder or an effect.