Compose state hoisting

Core principle

Hoist state only as far as the logic needs it. Keep simple UI element state local, move shared UI element state to the lowest common composable owner, extract a plain state holder when UI-only behavior becomes a concept, and use a screen state holder when business logic or app data is involved. At the screen boundary, keep state-holder wiring separate from plain state-driven UI rendering.

Review procedure

1. List the state, operations, app dependencies, event streams, and imperative effects involved.
2. Assign each item to the lowest owner that needs to read or change it using the decision guide below.
3. Extract a plain state holder only when coordinated UI-only behavior has become a concept.
4. When a screen mixes app wiring with layout, keep a small state-holder composable and move rendering to a plain state-driven composable.
5. Pass immutable UI state and explicit event callbacks across that boundary; keep UI mechanics in composition unless business logic needs their values.
6. Load focused effect, testing, focus, or deferred-read skills when those concerns need deeper treatment.
7. Finish when the UI can be previewed and tested without app dependencies, business work remains in the screen state holder, and no state has been hoisted farther than its logic requires.

Decision guide