Back to Details

compose-state-and-effects

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Compose state and effects

Compose状态与副作用

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.
为每一段UI状态指定一个最低层级的责任所有者，然后通过生命周期与该所有者同步的副作用来执行命令式操作。组合负责渲染；状态与副作用确保渲染安全变更。

Procedure

操作流程

  1. Inventory mutable UI state, app state, event streams, app dependencies, and imperative work in the affected screen or component.
  2. Place each state value at its lowest necessary owner: local UI state, hoisted state, a plain UI state holder, or a screen state holder.
  3. Keep app wiring and business state at the screen boundary; expose plain UI state and explicit callbacks to previewable rendering.
  4. Choose an effect API whose lifecycle matches the work, and key it by the semantic input that should restart or dispose it.
  5. Load the focused reference for every material concern below. Do not use a reference merely because its topic is adjacent.
  6. Route frame-rate reads, cross-phase back-writing, and 
    @ReadOnlyComposable
    contracts to Compose performance.
  7. 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.
  1. 梳理受影响的屏幕或组件中的可变UI状态、应用状态、事件流、应用依赖项以及命令式操作。
  2. 将每个状态值放置在其所需的最低层级所有者中：本地UI状态、提升后的状态、普通UI状态持有者或屏幕状态持有者。
  3. 将应用连接逻辑和业务状态保留在屏幕边界处；向可预览的渲染层暴露普通UI状态和明确的回调。
  4. 选择生命周期与操作匹配的副作用API，并根据应触发重启或销毁操作的语义输入为其设置key。
  5. 为每个重要主题加载对应的聚焦参考文档。不要仅因主题相关就使用无关参考。
  6. 将帧率读取、跨阶段回写以及
    @ReadOnlyComposable
    契约相关问题转至Compose性能。
  7. 当每个状态值都有唯一所有者、每个副作用都有合理的生命周期和key，且UI无需依赖应用即可进行预览和测试时，操作完成。

Topic router

主题路由

SignalRead
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 boundariesState 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 behaviorCompose focus navigation
Tests or previews for the resulting UI contractCompose UI testing patterns
信号参考文档
基础本地
var
、
remember { mutableStateOf(...) }
、状态列表/映射或重置状态		本地状态
兄弟组件共享的状态、UI状态持有者、ViewModel/组件连接逻辑或可预览的屏幕边界状态提升
LaunchedEffect
、
DisposableEffect
、
SideEffect
、
snapshotFlow
、
rememberCoroutineScope
、
rememberUpdatedState
、
produceState
、命令式
requestFocus
、回调、事件Flow收集、Snackbar、导航或分析		副作用
焦点所有权与键盘/电视/D-pad行为Compose焦点导航
最终UI契约的测试或预览Compose UI测试模式

RED/GREEN agent scenarios

RED/GREEN代理场景

  1. 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.
  2. 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.
  3. Counterexample: a one-off expandable badge has one private Boolean. GREEN keeps it local and does not introduce a state holder or an effect.
  1. RED场景：将组件、收集的
    StateFlow
    、导航事件和屏幕布局放在同一个可组合项中。GREEN场景：将连接逻辑和副作用保留在屏幕边界处，为纯渲染层提供不可变状态和回调。
  2. 新案例：查询驱动仓库建议，同时列表状态和焦点请求器协调UI行为。GREEN场景：将查询和建议放在屏幕状态持有者中，但将Compose运行时对象保留在普通UI状态中。
  3. 反例：一次性可展开徽章有一个私有布尔值。GREEN场景：将其保留在本地，不引入状态持有者或副作用。